La partie 2 organise un projet, avec un début et une réception. La partie 3 organise l'exploitation, qui ne finit qu'à la démolition. Ce n'est pas une extension de la même logique : un processus sans échéance ne se pilote pas par des jalons, il se pilote par des événements.
C’est l’écart fondamental entre les deux parties, et il change tout le reste. La partie 2 accompagne une opération qui se termine. La partie 3 accompagne un ouvrage qui vivra des décennies, sans date de fin.
Un projet a un début, des jalons et une réception. On peut donc le planifier de bout en bout : le calendrier d’information de la partie 2 décrit qui livre quoi et quand, jusqu’à la remise. L’exploitation n’a pas cette forme. On ne sait ni quand une pompe tombera en panne, ni quand un locataire partira, ni quand une réglementation changera. Planifier de bout en bout un processus sans fin est impossible.
La partie 3 en tire la seule conséquence logique : puisqu’on ne peut pas tout prévoir dans le temps, on organise l’information autour de ce qui déclenche un besoin. Le cycle ne tourne pas une fois, il se rejoue à chaque fois qu’il se passe quelque chose.
La partie 2 se pilote par des jalons : des dates connues d’avance. La partie 3 se pilote par des événements : des occurrences qu’on ne date pas mais qu’on peut anticiper. Tout le reste de la norme découle de ce déplacement, et c’est lui qu’il faut avoir en tête pour ne pas lire la partie 3 comme une simple suite de la partie 2.
C’est le mécanisme propre à la partie 3, et celui qu’on ne trouve nulle part ailleurs dans la série. Il remplace le calendrier là où le calendrier ne peut pas exister.
Un événement déclencheur est une occurrence, pendant la vie de l’ouvrage, qui crée un besoin de produire ou de mettre à jour de l’information. Il en existe deux natures, et les confondre conduit à ne préparer que la moitié.
Une inspection réglementaire, une maintenance périodique, la fin d’un bail, un renouvellement d’équipement. On ne connaît pas toujours la date exacte, mais on sait qu’ils arriveront. Ils se préparent.
Une panne, un dégât des eaux, un impact de foudre, un incident de sécurité. On ne peut pas les planifier, mais on peut décider à l’avance quelle information il faudra pouvoir mobiliser quand ils surviendront.
Non pas un planning, mais une liste d’événements et, pour chacun, l’information qu’il faudra produire ou retrouver. Quand la panne survient, ce n’est pas le moment de se demander quelles données sont utiles : la réponse doit avoir été écrite avant. C’est là toute la différence entre subir un événement et le traiter.
La frontière entre les deux parties se joue à la réception, dans un geste que presque tout le monde traite comme un simple transfert de fichiers. C’en est un tout autre.
À la fin du projet, on dispose du modèle d’information du projet : tout ce qui a été constitué pendant la conception et les travaux. L’exploitation, elle, a besoin du modèle d’information du patrimoine : ce qui sert à faire fonctionner l’ouvrage dans la durée. Le second n’est pas une copie du premier, c’est un tri suivi d’une reprise.
Livrer le modèle de projet en le renommant modèle de patrimoine. On obtient alors un modèle lourd, plein d’information inutile à l’exploitant et dépourvu de celle qu’il cherche. Le tri doit être décidé en amont, dans les exigences, et il suppose de savoir ce dont l’exploitation aura besoin. C’est précisément l’objet des AIR, et c’est pourquoi ce document s’écrit avant la conception, pas à la livraison.
La partie 3 renverse une intuition tenace : ce n’est pas le projet qui décide de ce que l’exploitation recevra, c’est l’exploitation qui décide de ce que le projet devra livrer.
La chaîne part du besoin de l’organisation qui possède l’ouvrage. De sa stratégie de gestion de patrimoine découlent ses besoins d’information de patrimoine, qui disent ce qu’elle veut pouvoir faire de l’information sur la durée. Ces besoins se traduisent ensuite en exigences, qui s’imposent au projet.
Un exploitant qui n’a pas écrit ses besoins ne reçoit pas « ce qui est disponible » : il reçoit ce que le projet a jugé bon de livrer, c’est-à-dire ce qui l’arrangeait, lui. La partie 3 ne commence donc pas à la réception. Elle commence au moment où le futur exploitant exprime ce dont il aura besoin, et ce moment se situe au tout début du projet, dans la logique décrite par OIR, AIR, PIR, EIR.
La partie 3 est claire sur le processus. Ce qu’elle ne peut pas régler, c’est que l’exploitation d’un ouvrage n’est presque jamais tenue par ceux qui l’ont construit.
Pendant le projet, une équipe est constituée, missionnée et payée pour gérer l’information. En exploitation, cette équipe est partie. La gestion de l’information échoit à un gestionnaire de patrimoine, à un service de maintenance ou à un exploitant, qui ont rarement été formés à la série et qui héritent d’un modèle qu’ils n’ont pas commandé.
C’est la raison la plus fréquente de l’échec, et elle n’est pas technique. Un modèle de patrimoine impeccable livré à une organisation qui n’a ni les outils, ni les compétences, ni la volonté de le tenir à jour cesse d’être synchronisé en quelques mois. Il redevient alors ce qu’un dossier papier a toujours été : un état figé qui vieillit.
Qui le tiendra à jour, avec quel outil, et sur quel budget ? Si la réponse n’existe pas, exiger un modèle de patrimoine sophistiqué revient à commander un livrable dont on sait déjà qu’il mourra. Mieux vaut un modèle modeste réellement maintenu qu’un modèle riche abandonné à la première mise à jour.
La partie 3 n’est pas la partie 2 prolongée. C’est un autre régime, celui d’un processus qui ne s’arrête jamais.
Trois idées à emporter. Un projet se pilote par jalons, une exploitation par événements : puisqu’on ne peut pas dater l’avenir d’un bâtiment, on prépare l’information autour de ce qui déclenchera un besoin, prévisible ou non. Le passage du modèle de projet au modèle de patrimoine est un tri, pas une copie : livrer l’un en renommant l’autre vide la partie 3 de son sens. Enfin, la difficulté est humaine avant d’être normative : l’exploitation est tenue par d’autres que le projet, et un modèle que personne n’est chargé de maintenir cesse d’être un jumeau du réel pour redevenir une archive.
La partie 2, dont celle-ci prend la suite, est décrite dans ISO 19650-2 pas à pas. Le moment de bascule d’un régime à l’autre est traité dans le handover. Le livrable qui alimente le modèle de patrimoine est le DOE numérique, et l’expression des besoins qui commande toute la chaîne, OIR, AIR, PIR, EIR. Enfin, le stade le plus avancé de l’exploitation numérique, souvent confondu avec elle, est le jumeau numérique.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
On lit la partie 2 comme un inventaire de documents à produire. C'est une séquence, et chaque document n'est que le résidu d'une étape. La première ne mobilise personne d'autre que le maître d'ouvrage, ce qui explique pourquoi c'est celle qu'on saute, et pourquoi tout le reste devient invérifiable.
Quatre cents PDF sur un disque dur, contractuellement irréprochables et pratiquement morts. Le problème n'est pas le format : c'est qu'un dossier produit à la fin est une reconstitution, faite par quelqu'un qui n'était pas là quand l'information existait.
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.