Le maître d'ouvrage doit exprimer ses besoins d'information avant même de savoir ce qu'il pourra en faire. D'où des cahiers des charges recopiés, qui exigent beaucoup et obtiennent peu. La méthode tient en une inversion : partir de la fin.
L’EIR est censé exprimer les besoins d’information du maître d’ouvrage. Mais celui-ci n’a jamais eu à formaliser ces besoins, et personne ne lui a montré comment.
Le résultat est prévisible. Le cahier des charges est recopié depuis un autre marché, ou rédigé par un assistant qui reprend une liste d’usages BIM sans les confronter à la réalité de l’exploitation. On y exige des maquettes tous niveaux, une base de données complète, un jumeau numérique. À la livraison, le client reçoit exactement ce qu’il a demandé, et ne s’en sert pas.
Le problème n’est pas le manque d’exigence : c’est l’exigence non reliée à un usage. Une information demandée sans destinataire identifié coûte cher à produire, encombre les livrables, et surtout décrédibilise l’ensemble du dispositif. Aux marchés suivants, les équipes traiteront tout l’EIR avec la même désinvolture, y compris les points qui comptaient vraiment.
Avant d’écrire la moindre exigence, posez cette question au futur exploitant, pas au service technique : « le jour de la livraison, qu’est-ce que vous voulez pouvoir faire, que vous ne pouvez pas faire aujourd’hui ? » Tout EIR utile est la traduction de cette réponse.
L’erreur de méthode est de partir des logiciels et des livrables. Il faut partir de l’usage visé et remonter, maillon par maillon, jusqu’à l’exigence écrite.
Chaque exigence de votre cahier des charges doit pouvoir être remontée jusqu’à un usage identifié. Si vous ne savez pas dire à quelle question une donnée sert à répondre, elle n’a rien à faire dans l’EIR. Cette règle simple élimine à elle seule la moitié des exigences habituelles, et rend l’autre moitié défendable.
L’ISO 19650 place l’EIR au sein d’un ensemble de besoins d’information : ceux de l’organisation (OIR), ceux du patrimoine (AIR) et ceux du projet (PIR). En pratique, sur un premier projet, ne vous laissez pas paralyser par cette généalogie : commencez par les usages d’exploitation, l’articulation viendra ensuite.
Un EIR complet couvre quatre registres. Les deux premiers sont ceux que les cahiers des charges oublient le plus, alors que ce sont eux qui portent la valeur.
L’intuition dit qu’un cahier des charges exigeant protège le client. En matière d’information, c’est souvent l’inverse.
Une exigence impossible à tenir n’est pas neutre : elle apprend aux équipes que ce document n’est pas sérieux. À partir de là, elles arbitrent seules ce qu’elles respectent. Un EIR modeste et intégralement appliqué protège infiniment mieux qu’un EIR ambitieux et partiellement ignoré.
Prenons un besoin tel qu’il est formulé au départ, et déroulons la chaîne jusqu’à la clause qu’on peut écrire et vérifier.
L’exploitant dit : « je veux un BIM exploitation ». Inutilisable en l’état : cela ne dit ni ce qu’il fera, ni comment on saura si c’est réussi.
On creuse : que voulez-vous pouvoir faire ? Réponse : « anticiper le budget de remplacement des menuiseries extérieures sur dix ans ».
Pour y répondre, il faut le nombre de menuiseries, leur type, leur date de mise en service et leur durée de vie prévisionnelle. Rien d’autre.
Ces données concernent les menuiseries extérieures uniquement. Ni les cloisons, ni les réseaux : le périmètre se restreint tout seul.
Chaque propriété reçoit un nom, un format de valeur et une phase de renseignement : le type dès la conception, la date de mise en service à la réception.
Le livrable est accepté si 100 % des menuiseries portent les quatre propriétés renseignées. Vérifiable automatiquement, donc opposable.
Aucune exigence sur les réseaux enterrés, faute d’usage identifié. C’est une décision, pas un oubli, et elle s’écrit noir sur blanc.
La dernière étape. Un EIR sérieux dit aussi ce qu’il ne demande pas, et pourquoi. Sans cela, chaque partie suppose que le silence lui donne raison, et le désaccord se découvre à la réception, quand il coûte le plus cher.
Elles ne relèvent pas du niveau technique du rédacteur, mais de la façon dont le document a été fabriqué.
Rédigé par la maîtrise d’œuvre ou un assistant, sans jamais interroger celui qui utilisera les données. L’usage réel reste inconnu.
Produit après le choix des équipes, il ne peut plus peser sur les offres ni sur les prix. Il devient un vœu, pas une exigence.
Un niveau de détail unique imposé partout, au lieu d’un niveau modulé par objet et par phase. Coûteux et rarement pertinent.
Des attentes formulées sans dire comment on les vérifie. À la réception, la discussion devient une affaire d’appréciation.
Aucune livraison intermédiaire pour tester le dispositif. L’écart se découvre à la fin, quand il n’est plus corrigeable.
L’EIR est le seul document où le client peut encore décider de ce qu’il obtiendra. Après, il subit.
Trois idées à emporter. Une exigence d’information ne vaut que si elle se remonte jusqu’à un usage et un bénéficiaire nommés : c’est le filtre qui élimine l’inutile. Trop demander revient à ne rien obtenir, parce qu’un document intenable apprend aux équipes à arbitrer seules. Enfin, une exigence sans critère d’acceptation n’est pas une exigence : c’est une préférence.
L’EIR appelle sa réponse : la convention BIM, où les équipes disent comment elles produiront ce que vous demandez. Pour le cadre normatif qui articule les deux, revenez à l’ISO 19650. La généalogie complète des besoins d’information (OIR, AIR, PIR) et les plans de livraison feront l’objet de guides dédiés dans cette section. Pour situer l’EIR dans la séquence complète de la phase projet, voyez ISO 19650-2 pas à pas. Et pour rendre ces exigences vérifiables automatiquement par une machine, l’IDS.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Quatre-vingts pages recopiées d'un autre projet, et sur le chantier personne ne sait quelle propriété remplir. Une convention utile n'est pas un document bien rédigé : c'est une série de décisions qu'on peut opposer à quelqu'un le jour d'un désaccord.
La norme dont tout le monde parle, expliquée sans jargon : qui demande quoi, qui livre quoi, et comment l'information est validée avant d'être partagée. Après ce guide, l'ISO 19650 ne vous impressionnera plus.
Une information saisie une fois doit servir jusqu'à l'exploitation, sans jamais être retapée. Ce principe explique à lui seul pourquoi les normes, les processus et les logiciels BIM sont faits comme ils le sont. Le comprendre, c'est arrêter de subir le BIM.