Flux de travail documentaire dans l’environnement commun de données : comment le fichier devient le moteur du processus d’information ISO 19650

Dans le monde AEC traditionnel, la gestion des approbations d’un document de projet suit généralement ce parcours : quelqu’un prépare le fichier, l’attache à un e-mail, l’envoie à celui qui doit le vérifier, attend une réponse, le transmet à d’autres pour commentaires, recueille les retours, charge une version révisée sur un drive partagé, envoie un autre e-mail, attend l’approbation formelle.
C’est un processus fragile, non tracé, facilement oublié, dépendant de la mémoire individuelle et totalement inadapté à un projet complexe avec des dizaines de disciplines et des centaines de contenants d’informations en parallèle.

Dans un CDE conforme aux principes ISO 19650, les flux de travail documentaires servent à surmonter cette logique : ce sont des flux opérationnels structurés qui guident le contenant d’information à travers des activités de vérification, révision, approbation, compilation de données et éventuelle publication. Ils peuvent être activés par le chargement d’un fichier, par une nouvelle révision, par un changement d’état ou par une action de l’utilisateur, et sont composés d’étapes séquentielles, de responsables, de formulaires associés, de conditions d’avancement et de notifications.

Le point central est que le fichier n’est plus seulement un objet à archiver, mais devient le déclencheur d’un processus gouverné, traçable et répétable.

Si les états du contenant indiquent où se trouve l’information dans le cycle de vie — WIP, Shared, Published, Archived — le workflow documentaire décrit comment le contenant avance d’un état à l’autre, qui doit intervenir, quels contrôles doivent être effectués et quelles preuves doivent rester dans l’audit trail.

Dans cet article, nous entrons dans le détail de ce qu’est un workflow documentaire dans un CDE, comment il se configure, quels modèles sont efficaces, et comment les plateformes CDE les plus matures transforment le fichier en moteur actif du processus.

Le paradigme : du fichier comme objet au fichier comme événement

Le saut conceptuel que les workflows documentaires introduisent est radical. Dans le modèle traditionnel, le fichier est un objet : il existe, est lu, est modifié, est archivé. Dans le modèle CDE ISO 19650, le fichier est un événement : son chargement sous-tend un processus, son changement d’état produit des notifications, sa révision active de nouvelles étapes.

Ce paradigme a des implications opérationnelles profondes.

Le fichier active un workflow

Une plateforme CDE évoluée transforme chaque document en un élément actif du processus. Le fichier chargé active un workflow — un flux opérationnel structuré qui guide vérifications, contrôles, approbations et compilations.

Les utilisateurs peuvent choisir parmi des workflows prédéfinis, configurés en fonction des processus de l’organisation, et les lancer par une action simple. Une fois lancé, le workflow est directement lié au contenant d’information et accompagne toutes les phases opérationnelles, avec une visualisation claire de l’état d’avancement.

Chaque étape a un sujet impliqué

Pour chaque étape du workflow, les sujets impliqués sont identifiés, recevant une notification et pouvant accéder immédiatement au fichier, aux instructions opérationnelles et aux activités qui les concernent. Aucune ambiguïté sur « qui fait quoi » : l’activité est assignée de manière explicite et tracée.

Le processus est répétable et standardisé

Contrairement à la gestion par e-mail, un workflow défini dans le CDE est répétable. La même procédure de vérification structurelle, par exemple, peut être appliquée à tous les contenants d’informations structurelles de tous les projets de l’organisation, garantissant la cohérence du processus.

Anatomie d’un workflow documentaire CDE

Un workflow documentaire dans un CDE conforme à l’ISO 19650 est composé d’éléments structurels récurrents. Les comprendre est le premier pas pour concevoir des workflows efficaces.

Le déclencheur : ce qui active le workflow

Le déclencheur est l’événement qui lance le processus. Il peut être : 

• chargement d’un nouveau conteneur d’information – le déclencheur le plus commun. Le fichier est déposé dans un dossier du CDE et cela active le workflow associé à ce type de contenu ;
• chargement d’une nouvelle révision – une variante spécifique : le fichier existe déjà, mais le chargement d’une nouvelle version active un nouveau cycle de vérification ;
• changement manuel d’état – l’équipe de tâche déclare le conteneur « prêt pour Shared » et cela lance le processus de vérification interdisciplinaire ;
• échéance temporelle – certains workflows sont programmés sur une base temporelle, par exemple une vérification périodique mensuelle de certains contenus ;
• action d’un utilisateur – demande explicite d’approbation, de révision, de clôture de phase.

Les étapes : les phases du processus

Chaque workflow est composé d’étapes séquentielles (ou parallèles, dans des workflows plus sophistiqués). Chaque étape a : 

• un responsable – un utilisateur ou un rôle qui doit agir ;
• une action prévue – vérification, révision, approbation, remplissage de formulaire ;
• une condition d’avancement – ce qui doit se passer pour passer à l’étape suivante ;
• un temps maximum (optionnel) – SLA au-delà duquel une escalade se déclenche ;
• formulaires associés (optionnel) – checklists, fiches de vérification, données structurées à collecter.

Les transitions : comment passer d’une étape à l’autre

Les transitions ne sont pas automatiques : elles résultent d’actions explicites de la part des responsables. Dans un workflow CRA typique : 

• approuve : le conteneur avance à l’étape suivante ;
• demande de modifications : le conteneur revient à l’équipe de tâche avec des commentaires ;
• refuse : le workflow se termine avec un résultat négatif ;
• délègue : la responsabilité de l’étape est transférée à un autre utilisateur.

Chaque transition laisse une trace permanente dans l’audit trail : qui, quand, avec quel résultat, avec quels commentaires.

Les destinataires : qui reçoit les notifications

Le workflow doit identifier clairement qui notifier à chaque transition. Un CDE évolué gère cela automatiquement, en envoyant des notifications par email. Les notifications doivent être contextuelles : pas seulement « il y a quelque chose à faire », mais « tu dois approuver le modèle structurel du bloc B rev. P03, avant le 30 du mois ».

La sortie : que se passe-t-il lorsque le workflow se termine

À la fin, le workflow produit plusieurs sorties : 

• changement d’état du conteneur (de WIP à Shared, de Shared à Published, etc.) ;
• enregistrement dans l’audit trail du parcours complété ;
• génération du conteneur historisé des états ;
• notifications de complétion à tous les parties prenantes pertinentes.

Schéma d’un workflow documentaire CDE

Le processus CRA : Vérifier, Réviser, Approuver

Le cœur opérationnel de presque chaque workflow documentaire CDE est le processus CRA (Vérifier, Réviser, Approuver). Il se décline en trois phases consécutives, chacune avec des responsabilités et des objectifs distincts.

Vérifier — la vérification technique

La Vérification est la première phase. C’est une vérification technique réalisée par l’équipe de production ou par un de ses référents (typiquement le Coordinateur BIM ou le groupe désigné). L’objectif est de s’assurer que le conteneur d’information répond aux exigences techniques de base avant d’être exposé à d’autres parties.

Que vérifie-t-on lors de la Vérification :

• conformité aux conventions de nommage du Cahier des Charges Informatiques ;
• complétude des métadonnées obligatoires ;
• présence de tous les éléments prévus par le LOIN pour la phase ;
• éventuelles validations automatiques (ex. vérification IDS sur les modèles IFC)

La vérification est effectuée par le responsable technique de l’équipe de production. Si le résultat est positif, le conteneur passe à la Révision ; si le résultat est négatif, le conteneur retourne en traitement à l’équipe de production avec des indications de correction.

Réviser — la révision interdisciplinaire

La Révision est la phase de révision interdisciplinaire et de coordination. Le conteneur — maintenant en état Partagé — est exposé aux autres équipes de projet et à la partie principale désignée pour vérification de cohérence avec les autres conteneurs du projet.

Que vérifie-t-on lors de la Révision :

• cohérence interdisciplinaire (détection de conflits si modèle) ;
• alignement avec d’autres conteneurs connexes (ex. cohérence entre architectural et structurel) ;
• correspondance aux exigences du Cahier des Charges Informatiques
• collecte de commentaires, problèmes (typiquement via BCF) et demandes de modification.

La révision est effectuée par d’autres équipes de projet, la Partie Désignée Principale, éventuellement la partie proposant.

Si le résultat est positif, le conteneur passe à l’Approbation ; si le résultat est négatif, le conteneur retourne à l’équipe de projet (retravail) avec les problèmes ouverts.

Approuver — l’approbation formelle

L’Approbation est la phase finale et contractuelle. Le conteneur est formellement approuvé par la Partie Désignée (ou par la Partie Désignée Principale si cela est prévu par le Cahier des Charges Informatiques) et peut passer à l’état Publié.

Que vérifie-t-on lors de l’Approbation :

• complétude du processus CRA précédent ;
• résolution de tous les problèmes ouverts ;
• conformité contractuelle au Cahier des Charges Informatiques ;
• aptitude à l’objectif déclaré.

L’approbation finale est effectuée par la Partie Désignée ou la Partie Désignée Principale selon CI.

Si le résultat est positif, le conteneur devient Publié ; si le résultat est négatif, le conteneur retourne à la Révision ou à la Vérification selon la gravité des lacunes.

Processus CRA dans le workflow documentaire CDE

Variations du processus CRA

Le CRA classique en trois phases n’est pas le seul schéma possible. En fonction de la nature du conteneur et des règles du Cahier des Charges Informatiques, il peut exister : 

• CRA simplifié : Check + Approve, sans Revue interdisciplinaire (typique pour les documents internes non soumis à coordination) ;
• CRA étendu : Check + Revue technique + Revue qualitative + Approve (pour des conteneurs critiques comme des modèles structurels ou d’installations) ;
• CRA avec audit externe : CRA + vérification par un tiers (pour des conteneurs soumis à validation réglementaire externe).

Workflows prédéfinis : la bibliothèque de processus de l’organisation

Une des caractéristiques les plus puissantes d’un CDE mature est la possibilité de définir une bibliothèque de workflows prédéfinis, c’est-à-dire des modèles de processus préconfigurés selon les procédures standard de l’organisation.

Pourquoi les workflows prédéfinis sont-ils nécessaires ?

Sans workflows prédéfinis, chaque projet redéfinirait de zéro les procédures de vérification et d’approbation, avec trois conséquences négatives : 

• incohérence entre les projets : chaque commande aurait son propre processus ;
• perte de temps : chaque fois, on réinvente la roue ;
• risque de non-conformité : sans standardisation, il est facile de sauter des étapes critiques.

Les workflows prédéfinis répondent à ces besoins en offrant des modèles réutilisables, configurés selon les procédures de l’organisation et activables par une action simple.

Exemples de workflows prédéfinis typiques

Une bibliothèque de workflows prédéfinis dans une organisation AEC mature peut inclure : 

• workflow de vérification d’un modèle IFC disciplinaire (architectural, structurel, MEP) ;
• workflow d’approbation d’un dessin technique (plan, section, détail constructif) ;
• workflow de révision d’un document contractuel (cahier des charges, rapport technique, chronogramme) ;
• workflow de contrôle d’un élément constructif (structurel, d’installation, anti-incendie) ;
• workflow de passation au Facility Management ;
• workflow de gestion des variantes en cours d’œuvre ;
• workflow de validation des données de durabilité (EPD, LCA, rapport CSRD).

Configurabilité vs standardisation

Le CDE doit équilibrer deux besoins opposés : 

• standardisation : les workflows doivent être cohérents au sein de l’organisation ;
• configurabilité : les workflows doivent pouvoir être adaptés aux spécificités de chaque projet.

Workflows basés sur les rôles : standardiser sans rigidité

Le véritable saut de qualité d’un CDE mature est la gestion des workflows basés sur les rôles – non sur les personnes.

Le problème des workflows basés sur les utilisateurs

Un workflow configuré sur des utilisateurs spécifiques a un problème structurel : il est rigide et fragile. Si Mario est le vérificateur structurel et part en vacances, le workflow se bloque. Si Luisa change de rôle, le workflow doit être reconfiguré. Si le projet change de main, tout doit être repensé.

Les workflows basés sur les rôles

La solution consiste à associer chaque étape à une fonction logique plutôt qu’à une personne. Les rôles typiques : 

• BIM Manager : supervision globale de la gestion de l’information ;
• BIM Coordinator : coordination disciplinaire ;
• CDE Manager : gestion opérationnelle de l’environnement ;
• Information Manager : gouvernance informative globale ;
• Vérificateur structurel, MEP, architectural : responsables de discipline ;
• Appointing Party Representative : représentant du donneur d’ordre.

Au moment du lancement du workflow, la plateforme demande de associer chaque rôle à la personne correcte au sein de l’équipe du projet. Le modèle reste donc standardisé, l’application est flexible et adaptable.

Avantages opérationnels

• résilience : si la personne assignée est absente, il est possible de changer l’association rôle-personne sans toucher au workflow ;
• scalabilité : le même modèle peut être appliqué à des dizaines de projets avec des équipes différentes ;
• simplicité de gestion : la configuration opérationnelle se réduit à une cartographie rôles-personnes.

Modules associés aux workflows : la collecte de données structurée

Un workflow documentaire CDE évolué ne se limite pas à gérer des approbations : il collecte données structurées tout au long du processus. Le mécanisme est constitué des modules (checklists numériques, fiches de vérification, contrôles de qualité) associés aux étapes du workflow.

Que sont les modules ?

Un module est un ensemble structuré de champs – textuels, numériques, booléens, à choix multiples, avec pièces jointes – qui recueille des informations spécifiques sur un conteneur d’information à un moment donné de son cycle de vie.

Exemples concrets : 

• module de vérification structurelle : rempli par le vérificateur lors de l’étape de Check, avec des champs sur les normes de référence, les coefficients de sécurité, la conformité aux charges de projet ;
• module de test incendie : rempli à la fin de la phase de construction, avec des champs sur les REI, les compartiments, les voies d’évacuation ;
• module de remise FM : rempli lors de la dernière phase du projet, avec des données techniques pour la gestion opérationnelle (manuels, maintenance, fournisseurs, garanties).

Visibilité conditionnelle par phase

La caractéristique distinctive est la visibilité conditionnelle : les modules peuvent être visibles ou modifiables uniquement à certaines phases du workflow, afin de garantir que chaque utilisateur opère exclusivement sur les informations de sa compétence.

Le module de vérification structurelle est : 

• invisible pendant la phase WIP ;
• modifiable uniquement par le vérificateur structurel pendant la phase de Check ;
• visible en lecture seule pour les Task Team pendant la phase de Review ;
• gelé et consultable après approbation.

Cela permet de gérer vérifications, compilations et validations de manière guidée, contrôlée et progressive, étape par étape.

Modules comme condition d’avancement

Dans des workflows plus sophistiqués, la compilation d’un module devient une condition d’avancement ; sans la compilation du module de vérification, le workflow ne peut pas progresser. Cela transforme les modules de simples formulaires en véritables portes de processus, garantissant que les données critiques soient collectées avant l’avancement.

Du module unique à la base de données de projet

Les données collectées dans les modules ne restent pas isolées dans le conteneur unique. Un CDE évolué les agrège au niveau du projet, les rendant consultables sous forme tabulaire, filtrables, ordonnables et interrogeables. C’est le passage de la gestion documentaire à la gestion intelligente des informations.

Gestion des révisions : workflows et nouvelles versions

Un sujet souvent sous-estimé est comment un CDE évolué gère la relation entre workflows et révisions du conteneur d’information. Que se passe-t-il lorsqu’une nouvelle version d’un fichier est chargée alors qu’un workflow est en cours sur la version précédente ? 

Le principe : le workflow s’interrompt, l’historique reste

Lorsque une révision mise à jour d’un conteneur d’information est chargée, le workflow en cours sur la version précédente s’interrompt dans l’état où il se trouve et reste consultable comme référence historique. Un nouveau processus peut alors commencer sur la nouvelle version, cohérent avec le contenu mis à jour du fichier.

Ce comportement a une valeur normative et opérationnelle importante : 

• la traçabilité du processus interrompu n’est pas perdue ;
• il n’y a pas de confusion entre les workflows de l’ancienne et de la nouvelle version ;
• l’audit trail maintient une preuve complète de ce qui s’est passé à chaque révision.

Exemple concret

Le BIM Coordinator charge la version 02 d’un modèle structurel. Le workflow de vérification s’active, qui progresse jusqu’à l’étape de Review. En Review, des incohérences avec le modèle architectural sont relevées et le Task Team décide de revoir le modèle.

Il charge la version 03. À ce stade : 

• le workflow sur la version 02 reste « interrompu en Review », avec tous les commentaires et les problèmes ouverts consultables comme historique ;
• sur la version 03, un nouveau workflow de vérification commence depuis le début ;
• l’audit trail enregistre à la fois le parcours partiel de la version 02 et le nouveau parcours de la version 03 ;
• aucune donnée n’est perdue, aucun processus n’est mélangé.

Implications pour le choix de la plateforme

Toutes les plateformes ne gèrent pas correctement ce scénario. Certaines écrasent le workflow, d’autres le maintiennent mais sans le lier à la nouvelle version, d’autres encore le suppriment silencieusement. Un CDE conforme à la norme ISO 19650 doit garantir le comportement correct : interruption tracée, pas de suppression, consultabilité permanente de l’historique.

Modèles de workflow récurrents dans le secteur AEC

Au fil des ans, certains modèles de workflow récurrents se sont consolidés, représentant des meilleures pratiques reconnues. Voici les plus répandus.

Modèle 1 — Workflow CRA classique en trois étapes

Le workflow standard ISO 19650-2 : 

• Vérifier (Équipe de production) → vérification technique interne;
• Réviser (autres Équipes + Partie Appelée) → révision interdisciplinaire;
• Approuver (Partie Appelante) → approbation formelle.

Ce workflow est utilisé pour les conteneurs d’informations destinés au passage de l’état Shared à l’état Published, avec valeur contractuelle.

Modèle 2 — Workflow de validation automatique IDS

Il est spécifique aux modèles IFC : 

• téléchargement du modèle IFC
• validation automatique IDS (déclenchement automatique)
• vérification manuelle si validation positive
• notification de correction si validation négative

Il est approprié d’utiliser ce workflow pour tous les conteneurs de type modèle IFC dans des projets qui adoptent des normes IDS (recommandé pour des projets BIM complexes).

Modèle 3 — Workflow de signature numérique avec horodatage

Il est destiné aux documents contractuels : 

• vérification du document;
• révision de la Partie Appelée;
• signature numérique par la Partie Appelante;
• ajout de l’horodatage;
• publication avec code de conformité contractuel;

Ce workflow doit être utilisé pour les conteneurs d’informations ayant une valeur contractuelle juridiquement pertinente.

Modèle 4 — Workflow de boucle de rework structuré

Il est pour la gestion des itérations : 

• workflow principal (ex. CRA)
• si refusé → ouverture automatique d’un sous-workflow de correction avec : 
  • assignation à l’Équipe de production;
  • liste des problèmes à résoudre;
  • SLA de réponse;
  • vérification que tous les problèmes ont été résolus avant le retour au workflow principal.

Ce workflow est destiné aux projets complexes avec une forte probabilité d’itérations (ex. nouvelles constructions complexes, infrastructures).

Modèle 5 — Workflow d’approbation parallèle

Lorsque plusieurs parties doivent approuver simultanément sans dépendance séquentielle : 

• téléchargement du conteneur;
• envoi parallèle à vérificateur A + vérificateur B + vérificateur C;
• collecte des approbations avec gestion des conflits;
• approbation finale uniquement si tous ont approuvé.

Ce workflow est adapté aux conteneurs nécessitant une validation multidisciplinaire (ex. un document de coordination, une variante complexe).

Modèle 6 — Workflow de transfert au Facility Management

À la fin du projet : 

• vérification de complétude des conteneurs Published;
• validation des données techniques pour le FM;
• remplissage des formulaires de transfert (manuels, garanties, maintenance);
• archivage définitif.

Ce workflow est pour la phase finale du projet, le passage de la construction à la gestion opérationnelle.

Outil gratuit pour concevoir vos workflows

Pour appliquer concrètement ce qui est décrit, nous avons préparé deux outils gratuits que vous pouvez utiliser immédiatement : 

Essayez le constructeur de workflow interactif : composez votre workflow personnalisé : ajoutez des étapes, assignez des rôles, associez des formulaires, configurez des transitions. Voyez en temps réel le flux généré et téléchargez la configuration au format lisible.

Comment un CDE évolué implémente les workflows documentaires

Toutes les plateformes CDE ne gèrent pas les workflows de la même manière. Les implémentations les plus matures se distinguent par certaines caractéristiques opérationnelles qui font la différence dans l’utilisation quotidienne.

Configuration visuelle des workflows

Une plateforme évoluée permet de configurer les workflows visuellement avec un éditeur glisser-déposer, des diagrammes de flux modifiables, un aperçu du processus — au lieu de nécessiter l’écriture de règles complexes ou de fichiers de configuration. Cela rend la configuration accessible aux BIM Managers et aux CDE Managers, sans nécessiter de compétences en développement logiciel.

Bibliothèque de workflows réutilisables

Une plateforme mature offre une bibliothèque de workflows préconfigurés et permet à l’organisation d’en créer de nouveaux, de les enregistrer comme modèles et de les réutiliser sur plusieurs projets.

Intégration avec des formulaires structurés

Le workflow doit pouvoir activer des formulaires aux étapes appropriées, avec une logique conditionnelle (visibles, remplissables, obligatoires). La plateforme doit gérer le remplissage des formulaires comme partie intégrante du processus, et non comme une fonction séparée.

Piste de vérification complète et non modifiable

Chaque workflow génère une piste de vérification complète : qui a agi, quand, avec quel résultat, avec quels commentaires. Ce journal doit être immuable — même l’administrateur ne doit pas pouvoir le modifier — et exportable pour des audits externes, des litiges, des vérifications de tiers.

Intégration avec l’écosystème d’applications

Dans des écosystèmes matures, le workflow n’est pas un silo : il s’intègre avec les applications spécialisées de la plateforme. Un workflow de vérification d’un modèle IFC peut activer la détection de conflits, le suivi des problèmes BCF, la comparaison entre révisions, la validation IDS. Cela transforme le workflow en un véritable orchestrateur de processus.

Le CDE comme écosystème : les workflows dans les plateformes réelles

Dans l’écosystème usBIM d’ACCA, la gestion des workflows documentaires est le cœur opérationnel de usBIM.platform, le CDE conforme à la norme ISO 19650. Chaque conteneur d’information chargé peut activer un workflow, avec une visualisation claire de l’état d’avancement, identification des parties prenantes pour chaque étape, notifications automatiques, formulaires associés avec visibilité conditionnelle par phase, gestion cohérente des révisions avec historisation des workflows interrompus.

Autour de la plateforme, les applications spécialisées s’intègrent comme actions exécutables au sein des étapes du workflow : 

• usBIM.clash pour la détection de conflits activée lors de l’étape de Revue ;
• usBIM.bcf pour la gestion des problèmes ouverts pendant la Revue avec la norme BCF ;
• usBIM.compare pour la comparaison automatique entre révisions lorsqu’un nouveau workflow démarre ;
• usBIM.dataquality pour la validation automatique IDS des modèles IFC conforme aux exigences du Cahier des Charges fondamental pour les workflows de type « Pattern 2 (validation automatique IDS) »
• usBIM.writer, usBIM.editor pour l’édition de documents dans les phases de WIP et de rework
• usBIM.facility pour les workflows de passation au Facility Management.

La philosophie est de rendre le workflow non seulement un processus d’approbation, mais un orchestrateur de toutes les activités techniques nécessaires à la production et à la validation du conteneur d’information. Un workflow de vérification structurelle n’est pas seulement « quelqu’un approuve » : c’est une séquence d’actions concrètes (conflit, validation IDS, suivi des problèmes, comparaison des révisions, vérification LOIN, remplissage du formulaire structurel) orchestrées par la plateforme.

Erreurs courantes dans l’implémentation des workflows documentaires

L’expérience montre que certaines erreurs se répètent avec une fréquence préoccupante. Les connaître aide à les éviter.

• répliquer les processus email dans le CDE : de nombreuses organisations, lors de leur première approche avec le CDE, configurent des workflows qui répliquent étape par étape les processus par email existants. Le résultat est un workflow inutilement complexe, rempli d’étapes redondantes, qui ne tire pas parti des capacités d’automatisation de la plateforme. La bonne stratégie est de repenser le processus en exploitant le paradigme CDE, et non de le transposer de manière critique ;
• workflows trop rigides : les workflows avec trop d’étapes, trop de conditions obligatoires, trop de passages formels tendent à générer frustration des utilisateurs et à inciter au contournement du système (par exemple, les utilisateurs s’envoient des fichiers par email pour « accélérer »). Un workflow efficace est le plus simple possible mais pas plus simple que nécessaire ;
• ne pas définir les délais : les workflows qui ne respectent pas les délais de réponse et les critères d’acceptation définis dans l’EIR et le pGI tendent à se bloquer parce que « il n’y a pas d’urgence » ;
• assignation à des utilisateurs uniques plutôt qu’à des rôles : comme déjà mentionné, assigner des étapes à des utilisateurs spécifiques plutôt qu’à des rôles produit des workflows fragiles. C’est l’une des erreurs les plus courantes lors des premières implémentations d’un CDE.
• formulaires trop longs ou non obligatoires : un formulaire de 50 champs est rempli de manière superficielle. Un formulaire optionnel n’est pas rempli du tout. La meilleure pratique est peu de champs, clairement obligatoires, avec validation automatique lorsque cela est possible.
• absence de formation des utilisateurs : le workflow le plus sophistiqué est inutile si les utilisateurs ne savent pas l’utiliser. L’implémentation de workflows CDE nécessite une formation structurée des équipes, pas seulement de la documentation. Le ROI de la formation est très élevé dans les 3-6 premiers mois d’adoption ;
• aucune révision périodique des workflows : les workflows doivent être révisés périodiquement en fonction des données d’utilisation : où ils se bloquent, combien de temps ils durent, quelles étapes génèrent le plus de rework. Sans cette itération, les workflows deviennent obsolètes et inefficaces.

Questions fréquentes (FAQ)

Qu’est-ce qu’un workflow documentaire dans un CDE ?

Un workflow documentaire dans un CDE conforme à la norme ISO 19650 est un flux opérationnel structuré activé par le chargement d’un conteneur d’information, qui guide les activités de vérification, de révision, d’approbation et de compilation de données. Il est composé d’étapes séquentielles avec des responsables, des formulaires, des conditions d’avancement et des notifications automatiques, et réalise opérationnellement le processus CRA (Check, Review, Approve) normé par la norme ISO 19650-2.

Qu’est-ce que le processus CRA (Check, Review, Approve) ?

Le CRA est le processus de vérification, de révision et d’approbation pour le passage des conteneurs d’information de WIP à Shared à Published : 

• check : vérification technique interne de l’équipe de tâche ;
• review : révision interdisciplinaire ;
• approve : approbation formelle de la partie désignée. Chaque phase a des responsables, des conditions d’avancement et peut produire du rework vers les phases précédentes.

Comment activer un workflow dans un CDE ?

Un workflow dans un CDE conforme peut être activé par : le chargement d’un nouveau conteneur d’information, le chargement d’une nouvelle révision, un changement manuel d’état, une échéance, une action explicite d’un utilisateur.

Quelle est la différence entre les workflows basés sur les utilisateurs et les workflows basés sur les rôles ?

Un workflow basé sur les utilisateurs assigne les étapes à des personnes spécifiques (par exemple, « Mario doit approuver »). Il est rigide : si Mario est absent, le workflow se bloque. Un workflow basé sur les rôles assigne les étapes à des fonctions logiques (par exemple, « le vérificateur structurel doit approuver »). Au moment du démarrage, la plateforme demande d’associer le rôle à la personne correcte. Il est plus résilient, évolutif et réutilisable entre les projets.

Qu’est-ce que les formulaires associés aux workflows ?

Les formulaires sont des ensembles structurés de champs (checklist, fiches de vérification, contrôles) associés aux étapes d’un workflow. Ils collectent des données structurées tout au long du processus. Dans un CDE évolué, ils ont une visibilité conditionnelle par phase : ils sont visibles ou remplissables uniquement dans les phases de compétence de chaque utilisateur. Les formulaires peuvent être obligatoires pour l’avancement du workflow, se transformant en portes de processus.

Que se passe-t-il avec le workflow lorsqu’une nouvelle version est chargée ?

Lorsqu’une nouvelle version d’un conteneur d’information 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 référence historique. Sur la nouvelle version, un nouveau workflow commence, cohérent avec le contenu mis à jour. La piste d’audit conserve les deux parcours, garantissant une traçabilité complète.

Peut-on avoir des workflows prédéfinis réutilisables ?

Oui. Une plateforme CDE évoluée offre une bibliothèque de workflows prédéfinis — modèles préconfigurés selon les procédures de l’organisation — activables par une action simple. Les modèles sont typiquement paramétriques : les rôles et certaines variables (temps maximum, formulaires optionnels) sont personnalisés au moment du démarrage, préservant la standardisation du processus et la flexibilité applicative.

Quels sont les modèles de workflow les plus courants dans le secteur AEC ?

Les modèles récurrents incluent : CRA classique à trois étapes (Check, Review, Approve), workflow de validation automatique IDS pour modèles IFC, workflow de signature numérique pour documents contractuels, workflow de rework loop pour la gestion des itérations, workflow d’approbation parallèle pour contenus multidisciplinaires, workflow de passation au Facility Management pour la phase finale du projet.

Comment les workflows s’intègrent-ils avec les applications spécialisées du CDE ?

Dans un écosystème mature, les étapes du workflow peuvent activer des applications spécialisées : détection de conflits, validation IDS, suivi des problèmes BCF, comparaison entre révisions, édition documentaire, signature numérique. Le workflow devient ainsi un orchestrateur de processus qui coordonne non seulement les approbations mais aussi les activités techniques. C’est le niveau le plus avancé d’intégration.

Qu’est-ce que la piste d’audit d’un workflow ?

La piste d’audit est l’enregistrement permanent et non modifiable de toutes les actions effectuées durant un workflow : qui a agi, quand, avec quel résultat, avec quels commentaires. C’est le fondement de la traçabilité requise par la norme ISO 19650 et est indispensable pour les audits de conformité, les litiges contractuels et les vérifications par des tiers. Un CDE conforme garantit que la piste d’audit est immuable et exportable.

Est-il possible de modifier un workflow déjà lancé ?

Cela dépend de la plateforme et de la phase. En général, un workflow en cours ne devrait pas être modifié structurellement car cela compromettrait la traçabilité. Certaines plateformes permettent de petites modifications (par exemple, remplacer la personne associée à un rôle) tout en maintenant la trace. Les modifications structurelles nécessitent typiquement la fermeture du workflow et le démarrage d’un nouveau.

Comment évaluer l’efficacité d’un workflow ?

L’efficacité d’un workflow est évaluée en analysant des métriques opérationnelles : temps moyen de complétion, nombre de reworks, pourcentage de SLA respectés, points de blocage récurrents, charge de travail par rôle. Un CDE mature fournit ces métriques via le tableau de bord du projet, permettant d’itérer sur les workflows en fonction de données objectives.

Glossaire essentiel

• Approve – phase finale du processus CRA : approbation formelle du conteneur par l’Appointing Party.
• Audit trail – enregistrement permanent et non modifiable des actions effectuées durant un workflow.
• BCF – BIM Collaboration Format. Standard openBIM pour la gestion des problèmes.
• Check – Première phase du processus CRA : vérification technique interne de l’équipe de production.
• CRA – Check, Review, Approve. Processus de vérification, révision et approbation normé par la norme ISO 19650-2.
• Gate de processus – Condition obligatoire (ex. remplissage de formulaire) qui doit être satisfaite pour l’avancement du workflow.
• Formulaire – Ensemble structuré de champs associé à une étape du workflow pour la collecte de données structurées.
• Review – Deuxième phase du processus CRA : révision interdisciplinaire du conteneur.
• Rework loop – Chemin de retour du conteneur à des phases précédentes après la détection de non-conformités.
• SLA – Service Level Agreement. Temps maximum défini pour l’achèvement d’une étape.
• Step – Phase élémentaire d’un workflow, avec responsable, action prévue et condition d’avancement.
• Template de workflow – Workflow préconfiguré, réutilisable et paramétrique, enregistré dans la bibliothèque de l’organisation.
• Transition – Passage d’une étape à la suivante dans un workflow, déterminé par une action explicite.
• Trigger – Événement qui active automatiquement un workflow (téléchargement de fichier, révision, échéance, etc.).
• Workflow prédéfini – Modèle de workflow préconfiguré selon les procédures de l’organisation.