Quatre sigles qui ressemblent à de la bureaucratie normative, et qui répondent pourtant à une question très concrète : d'où vient cette exigence, et qui a le droit de la changer ? Comprendre la chaîne, c'est cesser de réinventer ses besoins à chaque projet.
C’est la page de la norme que tout le monde survole. Quatre acronymes emboîtés, une pyramide dans un support de formation, et l’impression tenace qu’il s’agit de vocabulaire pour consultants.
Cette impression a une part de vérité : présentée comme une hiérarchie à mémoriser, la chaîne ne sert effectivement à rien. Elle devient utile dès qu’on comprend à quelle question elle répond. Cette question n’a rien d’abstrait : d’où vient cette exigence, et qui a le droit de la modifier ?
Sans réponse, chaque projet repart de zéro. Le rédacteur du cahier des charges recopie celui du chantier précédent, sans savoir lesquelles de ses exigences relevaient d’une politique d’entreprise et lesquelles étaient des bricolages de circonstance. L’organisation ne capitalise jamais, et se retrouve à négocier les mêmes points à chaque marché.
Une traçabilité des exigences. Chaque demande faite aux équipes doit pouvoir se justifier par un besoin de niveau supérieur. Celles qui n’y arrivent pas sont soit des oublis à documenter, soit des habitudes à supprimer. C’est un outil de tri, pas une pyramide décorative.
Deux concernent l’organisation et lui survivent. Deux concernent un projet et disparaissent avec lui. C’est la distinction la plus utile des quatre.
Beaucoup de documents francophones traduisent EIR par « exigences du maître d’ouvrage ». C’était le sens de l’ancien référentiel britannique, où le E signifiait Employer’s. L’ISO 19650 l’a redéfini en Exchange Information Requirements : exigences d’échange. Le glissement n’est pas cosmétique, il signifie qu’un EIR existe à chaque interface contractuelle, et pas seulement entre le client et la maîtrise d’œuvre.
Confondre les deux familles est l’erreur qui coûte le plus cher, parce qu’elle empêche toute capitalisation d’un projet sur l’autre.
Demandez à un maître d’ouvrage de vous montrer ses AIR, indépendamment de tout projet. S’ils existent, chaque nouveau marché consiste à en dériver un EIR, ce qui prend quelques jours. S’ils n’existent pas, chaque marché repart d’une page blanche et le résultat dépend de qui tient le stylo cette fois-ci.
Présentée en pyramide, la chaîne semble descendre du stratégique vers l’opérationnel et s’arrêter là. Elle se referme en réalité sur elle-même, et c’est tout son intérêt.
Deux modèles complètent le tableau. Le PIM est le modèle d’information constitué pendant la phase de réalisation : il porte tout ce que les équipes produisent. À la livraison, seule la part utile à l’exploitation est reprise dans l’AIM, le modèle d’information du patrimoine, qui vit ensuite pendant des décennies.
C’est ce transfert qui referme la boucle : l’AIM alimente les décisions de gestion, donc sert les objectifs qui figuraient dans les OIR. Une chaîne d’exigences qui ne débouche sur aucun AIM entretenu n’a produit que des livrables. Elle n’a rien changé au fonctionnement de l’organisation.
Sur vos derniers projets livrés, qui met à jour l’AIM aujourd’hui ? Si la réponse est « personne », les exigences d’information ont servi à produire un dossier, pas à gérer un patrimoine. Le problème n’est alors pas dans l’EIR mais bien plus haut, dans des AIR jamais écrits.
Prenons un gestionnaire de patrimoine, et suivons une exigence depuis le comité de direction jusqu’à la case que remplira un projeteur.
La direction fixe un cap : réduire de 15 % le coût de maintenance du parc sur cinq ans. Aucun bâtiment, aucun logiciel, aucune maquette n’est mentionné.
Le gestionnaire traduit : pour anticiper les remplacements, il faut connaître pour chaque équipement sa date de mise en service, sa durée de vie prévisionnelle et son coût de remplacement. Écrit une fois, valable pour tout le parc.
Pour l’opération en cours, la maîtrise d’ouvrage reprend ces besoins et y ajoute ce dont elle a besoin pour décider en cours de projet : arbitrages de coûts aux jalons.
L’exigence prend sa forme opposable : ces trois propriétés, sur les équipements techniques, dans un jeu de propriétés nommé, renseignées à la réception, avec un critère d’acceptation vérifiable.
Les équipes répondent en décrivant leur organisation : qui renseigne, à quel moment, avec quel contrôle avant partage.
À la livraison, ces propriétés passent du modèle de projet au modèle de patrimoine. Le gestionnaire peut enfin calculer son budget de remplacement, ce qui était l’objectif de départ.
Chaque maillon se justifie par le précédent. Une exigence de l’EIR qu’on ne peut pas rattacher à un AIR, lui-même rattaché à un OIR, est une exigence orpheline : soit un besoin réel jamais formalisé plus haut, soit une habitude que personne n’a osé questionner.
Elles se ressemblent toutes : elles consistent à sauter un maillon, puis à s’étonner que la chaîne ne tienne pas.
Les besoins de patrimoine, les AIR, ne prennent tout leur sens qu’en exploitation, régie par l’ISO 19650-3 : c’est là que se vérifie si le projet a livré ce qu’il fallait.
La mise en pratique du dernier maillon est traitée dans rédiger un EIR, et la réponse des équipes dans la convention BIM. Pour le cadre général dont cette généalogie fait partie, revenez à l’ISO 19650.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
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.
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.
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.