Retour au blog BIM & IFC
Livraison & ISO 19650 · 2026-08-07 · 10 min
Critères de réception IFC : comment accepter ou rejeter une maquette sans se disputer
« Cette maquette est inutilisable » contre « la maquette est correcte » : un débat qui ne se termine jamais. Un tableau de critères de réception d'une page, validé avant la première livraison, transforme cela en un contrôle de cinq minutes avec un résultat documenté.
Critères de réception IFC : comment accepter ou rejeter une maquette sans se disputer — IFC Viewer Online article cover
Sur tout projet, il arrive un moment où un coordinateur ouvre une maquette livrée, passe vingt minutes à découvrir qu'elle est inutilisable, et rédige un e-mail qui commence par « malheureusement ». Ce qui se passe ensuite dépend presque entièrement d'une chose : quelqu'un a-t-il, à l'avance, écrit noir sur blanc à quoi ressemble une livraison acceptable.
Si oui, l'e-mail est court, factuel et ne prête à aucune contestation. Sinon, il devient le premier coup d'une négociation sur les standards qui s'appliquent, et le débat sera rouvert à chaque jalon pour le reste du projet.
La réception est une checklist, pas une opinion
Le changement de posture est minime, mais il change tout. Contrôler une livraison, ce n'est pas juger sa qualité — c'est appliquer des critères convenus à un fichier. Cela a trois conséquences qui méritent d'être dites explicitement :
- Le relecteur n'a besoin d'aucune autorité au-delà du tableau convenu. Il ne juge pas la compétence de l'auteur de la maquette ; il rapporte un résultat.
- L'auteur peut prévoir le résultat avant de diffuser. Tout ce qui est prévisible peut être évité — c'est bien tout l'intérêt.
- Le désaccord, quand il survient, porte sur les critères eux-mêmes — une conversation qui peut avoir lieu une seule fois, calmement, plutôt que chaque mois au milieu d'une livraison.
On ne peut pas rejeter une livraison pour non-conformité à un standard que l'émetteur n'a jamais accepté. On ne peut la rejeter que pour non-conformité à celui que vous avez tous les deux validé.
Le tableau des critères de réception
Voici l'outil concret. Dix lignes, une page, en annexe du BEP ou de l'EIR. La troisième colonne est vide à dessein — c'est le projet qui la renseigne avant la première livraison, et c'est cet acte de la remplir qui constitue le véritable accord.
| Critère | Rejeter si… | Position du projet |
|---|
| Intégrité structurelle | Tout constat de schéma ou spatial de sévérité erreur | Rejeter / accepter avec réserve |
| Health Score | Sous le seuil convenu | Seuil : __ /100 |
| Couverture des contrôles | Tout contrôle signalé comme non exécuté ou en échec | Rejeter / nouvelle exécution requise |
| Stabilité des identifiants | Renouvellement de GUID au-delà d'un pourcentage convenu entre révisions | Renouvellement max : __ % |
| Nommage | Le nom de fichier ne suit pas la convention convenue | Rejeter / renommer et consigner |
| Géoréférencement | Maquette non calée sur le point de référence partagé du projet | Rejeter |
| Unités | Unités de longueur non métriques | Rejeter |
| Classification | Éléments sans référence de classification | S'applique à partir du stade : __ |
| Jeux de propriétés | Psets requis manquants pour le niveau d'information nécessaire déclaré | Grille des Pset : __ |
| Espaces | Espaces sans nom, nom long ou surface de plancher | S'applique à partir du stade : __ |
Son but n'est pas d'être strict — c'est d'être décidé. Un tableau souple que tout le monde a approuvé vaut mieux qu'un tableau strict arrivé avec l'e-mail de rejet.Les trois premières lignes sont celles qui pèsent le plus lourd, et ce sont aussi celles qu'on omet le plus souvent. Les clauses qui les font entrer dans le BEP dès le départ sont couvertes dans les clauses de BEP qui empêchent vraiment les mauvaises livraisons IFC.
La ligne 3 mérite sa propre section : la couverture des contrôles
La plupart des tableaux de réception contrôlent les résultats d'une exécution de validation. Presque aucun ne vérifie si cette exécution a réellement eu lieu — une brèche assez large pour y faire passer n'importe quelle livraison.
Un contrôle qui n'a pas tourné ressemble exactement à un contrôle qui est passé : les deux produisent zéro constat. Un fichier volumineux dépasse le délai, un worker plante, un contrôle dépendant de la géométrie abandonne discrètement — et le rapport revient propre, avec un score parfait. La livraison est acceptée, contrôlée seulement de nom.
| État de couverture | Ce que cela signifie | Action de réception |
|---|
| Exécuté | Le contrôle s'est terminé. Zéro constat signifie zéro constat. | Faites confiance au résultat. |
| Non exécuté | Tenté mais sans résultat — généralement un dépassement de délai ou une exécution annulée. | Relancez avant d'accepter. Ne jamais lire cela comme un succès. |
| Échoué | Le contrôle a rencontré une erreur. | Signalez-le. Un score calculé malgré des contrôles en échec n'est pas comparable à une exécution propre. |
Contrôler une livraison en cinq minutes
- Ouvrez le conteneur et exécutez le jeu de règles du projet. Moins d'une minute pour la plupart des maquettes de métier.
- Vérifiez d'abord la couverture, les résultats ensuite. Si quelque chose n'a pas tourné, arrêtez-vous — vous n'avez pas encore de contrôle valable.
- Comparez le score au seuil, puis examinez les constats de sévérité erreur. Tout le reste est une remarque, pas un motif de blocage.
- Comparez à la révision précédente. Les nouveaux constats racontent l'histoire ; les constats résolus prouvent que le dernier contrôle a été suivi d'effet.
- Consignez le résultat dans le bordereau de transmission ou le commentaire du CDE — score, jeu de règles, couverture, et tout constat accepté d'un commun accord.
L'étape 1 est exactement la routine que l'émetteur aurait dû exécuter avant de diffuser ; comment contrôler une maquette IFC avant livraison la détaille côté émetteur. Quand les deux parties exécutent les mêmes contrôles, le contrôle de réception cesse d'être une inspection pour devenir une confirmation.
Comment rédiger le rejet
Le ton compte autant que le contenu, parce que la personne qui reçoit ce message est généralement en retard sur le planning et rarement fautive personnellement. Trois règles : nommez le critère, pas la maquette. Donnez la cause, pas seulement le symptôme. Dites ce qui est bloqué, et pour combien de temps.
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
Remarquez ce qui est absent : tout adjectif sur la maquette, et toute spéculation sur la cause. Un chiffre, deux identifiants de règle, une cause probable et une conséquence. C'est un message que personne n'a à se défendre — c'est pourquoi il est suivi d'effet plutôt qu'escaladé.
Quand accepter une maquette qui a échoué
Parfois, la bonne réponse est quand même oui — l'information manquante dépasse le niveau d'information nécessaire pour ce stade, ou un fournisseur n'a pas encore livré, ou l'alternative serait d'arrêter le projet. Accepter une livraison en échec est une décision légitime. L'accepter en silence ne l'est pas.
Un constat levé par dérogation a besoin de trois éléments : une raison, une personne qui l'a validé, et une date. C'est toute la différence entre un constat accepté et un constat ignoré, et c'est ce qui évite de redécouvrir le même problème comme une crise deux stades plus tard.
Ces dérogations doivent figurer dans le bordereau de transmission, aux côtés du rapport et de tout ce qui accompagne le conteneur — voir ce qu'il faut livrer avec une maquette IFC.
Critères de réception IFC : comment accepter ou rejeter une maquette sans se disputer