Un projet a deux ossatures superposées, et les mélanger brouille toute discussion. L'une est contractuelle : qui répond de quoi devant qui, ce sont les parties, liées par des désignations. L'autre est organisationnelle : qui travaille avec qui, ce sont les équipes. L'ISO 19650 nomme les deux précisément. Voici comment elles s'emboîtent.
Quand on parle de « l’équipe » d’un projet ISO 19650, on mélange sans le savoir deux choses différentes : une chaîne de responsabilités contractuelles et une organisation de travail. Ce ne sont pas les mêmes, et les confondre produit des raisonnements faux.
La première ossature est contractuelle : elle dit qui a commandé quoi à qui, et donc qui répond devant qui. Ses éléments sont les parties, reliées par des désignations, c’est-à-dire des engagements de fourniture d’information. La seconde est organisationnelle : elle dit qui travaille ensemble pour produire l’information. Ses éléments sont les équipes. Une même personne appartient aux deux à la fois, mais à des places qui ne coïncident pas forcément.
Le guide sur la vue d’ensemble de l’ISO 19650 a présenté les parties. Celui-ci assemble le tableau complet, en y ajoutant les équipes, souvent oubliées, et surtout en montrant comment les deux ossatures se superposent, ce qui est la seule façon de ne plus s’y perdre.
Deux phrases fréquentes trahissent le mélange : « l’équipe de livraison signera », alors qu’une équipe ne signe rien, une partie oui ; et « il faut un contrat avec l’équipe de tâche », alors qu’une équipe de tâche n’est pas une entité contractuelle. Chaque fois qu’on prête à une équipe un acte contractuel, ou à une partie un rôle purement opérationnel, on a superposé les deux ossatures de travers.
Cette ossature est détaillée dans la vue d’ensemble ; on la résume ici pour poser l’autre par-dessus. Trois positions, reliées par un même type de lien.
Trois parties, du haut vers le bas de la commande : la partie désignante, qui commande et reçoit ; la partie désignée principale, qui pilote et répond devant elle ; la partie désignée, qui exécute une tâche sans piloter les autres. Ce qui les relie n’est pas un organigramme, c’est la désignation : l’engagement par lequel une partie confie à une autre la fourniture d’une information, avec ses exigences et ses échéances. La responsabilité circule le long de ces désignations, et nulle part ailleurs.
On parle des parties, jamais du fil qui les relie. C’est pourtant lui qui compte : sans EIR joint à une désignation, il n’y a pas d’exigence opposable ; sans désignation vers un sous-traitant, l’exigence du client ne l’atteint jamais. La partie dit qui, la désignation dit ce à quoi il s’est engagé. Une structure de parties sans désignations claires est une liste de noms sans obligations. L’instrument qui rend ces obligations réellement opposables dans la désignation est le protocole d’information.
C’est la partie que la plupart des présentations omettent, et c’est elle qui donne son sens à l’ensemble. Trois niveaux d’équipe s’emboîtent, du plus large au plus opérationnel.
L’équipe de tâche est le maillon vivant : c’est là que l’information se fabrique et se vérifie avant de sortir. Mais comme elle n’a pas d’existence contractuelle, on oublie de lui attribuer explicitement ce qu’elle doit produire. Un projet qui nomme ses parties mais jamais ses équipes de tâche sait qui a signé, sans savoir qui fait réellement quoi. Les deux manquent d’être reliés.
Tout se joue dans la façon dont les deux ossatures se recouvrent. Une fois ce recouvrement compris, les termes cessent de se brouiller.
Une équipe de livraison est la face organisationnelle d’une désignation principale : les mêmes acteurs, vus une fois comme des parties liées par un contrat, une autre fois comme un groupe qui travaille ensemble. À l’intérieur, chaque partie désignée met au travail une ou plusieurs équipes de tâche. La partie est l’entité qui a signé ; l’équipe de tâche est le groupe de personnes qui produit. L’une porte la responsabilité, l’autre fait le travail.
Devant le mot « équipe » ou « partie », demandez-vous : est-ce que je parle de qui a signé, ou de qui travaille ensemble ?. Si c’est de responsabilité et de contrat, employez le langage des parties. Si c’est de production et de coordination, celui des équipes. La plupart des malentendus viennent d’avoir répondu à une question de l’un avec le vocabulaire de l’autre.
Distinguer les deux ossatures n’est pas un raffinement de vocabulaire : c’est ce qui permet d’attribuer chaque chose à la bonne place, et d’éviter des impasses très concrètes.
Trois conséquences pratiques. D’abord, c’est la partie désignée principale, et elle seule, qui répond de la cohérence d’une équipe de livraison devant le client, et qui consolide les plans de livraison de ses équipes dans un MIDP. Attendre cela d’une équipe de tâche, qui n’a ni le mandat ni la vue d’ensemble, ne mène nulle part. Ensuite, ces positions sont relatives : une entreprise générale est partie désignée principale face au maître d’ouvrage et partie désignante face à ses sous-traitants, ce que détaille la cascade des exigences. Enfin, une fonction de gestion de l’information doit être attribuée dans cette structure, à un niveau précis, faute de quoi personne ne tient réellement l’information : c’est l’objet de qui fait quoi.
Prenez un livrable et posez deux questions : quelle partie en répond contractuellement, et quelle équipe de tâche le produit réellement ? Si les deux réponses existent et sont reliées, l’organisation tient. Si l’une manque, ou si les deux se confondent en un vague « c’est l’équipe BIM », vous avez trouvé où le projet dérapera : une responsabilité sans producteur identifié, ou un producteur sans responsable désigné.
Deux ossatures superposées, un seul point à retenir : ne jamais répondre à une question de l’une avec le vocabulaire de l’autre.
Trois idées à emporter. Un projet a deux structures : contractuelle, les parties reliées par des désignations, qui dit qui répond de quoi ; et organisationnelle, les équipes, qui dit qui travaille avec qui. Les équipes s’emboîtent en trois niveaux : l’équipe de projet, client compris, l’équipe de livraison, pilotée par une partie désignée principale, et l’équipe de tâche, l’unité opérationnelle qui produit, sans existence contractuelle. Enfin, la superposition est le vrai sujet : une équipe de livraison est la face organisationnelle d’une désignation principale, et chaque livrable a une partie qui en répond et une équipe de tâche qui le produit, à ne jamais confondre.
Cette structure prolonge la vue d’ensemble de l’ISO 19650 et sa cascade d’exigences. Les fonctions à couvrir à l’intérieur, indépendamment des intitulés, sont dans qui fait quoi. Les plans que produisent les équipes, le TIDP par équipe de tâche et le MIDP par équipe de livraison, sont détaillés dans TIDP et MIDP. Et ce que chaque partie s’engage à recevoir se formalise dans l’EIR.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
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.
Le même intitulé recouvre trois métiers différents selon l'entreprise, et deux offres d'emploi identiques décrivent des postes opposés. La seule façon de s'y retrouver : raisonner en fonctions à couvrir, pas en cartes de visite.
L'EIR dit ce dont on a besoin, la convention dit comment on travaille. Entre les deux et la réalité, il manque un chaînon que presque tout le monde saute : le calendrier des livraisons d'information. Sans lui, « on livrera du BIM » n'a ni dates, ni auteurs, ni ordre. Le TIDP et le MIDP sont ce calendrier, et ils ne sont rien d'autre que de la planification appliquée à l'information.