« Plan_FINAL_v2_bon_celui-ci.pdf » n'est pas un mauvais nom, c'est une absence de nom. Un conteneur d'information bien nommé n'est pas plus lisible pour un humain : il est lisible par une machine, qui peut alors trier, filtrer et contrôler ce qu'aucun œil ne peut suivre sur des milliers de fichiers.
On voit le nom d’un fichier comme une étiquette, une commodité pour s’y retrouver à l’œil. C’est passer à côté de sa fonction réelle, et c’est pourquoi la plupart des conventions échouent : elles cherchent la lisibilité humaine là où il faut la lisibilité machine.
Un nom composé de champs séparés par un délimiteur n’est pas une phrase, c’est un enregistrement. Chaque champ est une colonne : le projet, l’émetteur, la zone, le type, la discipline, le numéro. Lu par un humain, c’est illisible et rébarbatif. Lu par une machine, c’est une base de données que l’on peut trier, filtrer et interroger sans jamais ouvrir un fichier.
Prenons comme exemple un environnement commun de données qui contient dix mille conteneurs. La question « montre-moi toutes les versions publiées des plans de structure du bâtiment B » n’a de réponse instantanée que si cette information est dans le nom, à une place fixe. Si elle est dans la tête de celui qui a nommé le fichier, ou noyée dans un intitulé libre, la même question devient une après-midi de recherche manuelle.
Un nom bien fait ne sert pas d’abord à celui qui le lit, il sert à ce que l’outil puisse agir sans lui : classer automatiquement, vérifier la conformité au dépôt, empêcher une mauvaise version de circuler. Le jour où votre plateforme contrôle les noms toute seule, vous comprenez que le nom n’était jamais une étiquette : c’était le point d’entrée de tout le reste.
Le nommage passe pour une lubie de documentaliste. Les chiffres sur le sujet racontent autre chose : c’est l’un des gaspillages les plus massifs et les moins visibles du secteur.
Le mécanisme est banal et se répète des millions de fois par jour. Quelqu’un travaille sur une version dépassée parce que son nom ne disait pas qu’elle l’était. Quelqu’un refait un document parce qu’il ne le retrouve pas. Quelqu’un prend une décision sur un plan qui a été révisé depuis, sans le savoir. Chacun de ces incidents est minuscule ; leur somme est colossale.
Les études sur la donnée de projet mal gérée chiffrent en dizaines de milliards par an le coût des reprises dues à une mauvaise information et à la mauvaise communication, et estiment qu’une part importante du temps des professionnels part à chercher des documents ou à réparer des erreurs de version. La convention de nommage n’élimine pas ce coût, mais elle attaque directement sa cause la plus fréquente. Ce n’est pas de la bureaucratie, c’est de l’économie.
La série ISO 19650 ne fournit pas un modèle de nom à recopier. Elle fournit un principe : découper l’information en champs convenus, à une place fixe, séparés par un caractère réservé à cela.
Quel projet, et qui a produit le conteneur. Les deux premières colonnes, celles qui situent la responsabilité.
Quelle zone ou quel niveau, et quelle nature de document : modèle, plan, note, tableau. C’est ce sur quoi on filtre le plus souvent.
Quel métier, et un numéro qui rend le nom unique. La discipline permet d’isoler tout ce qui relève d’un lot d’un coup.
Autour de ces champs de nom, deux codes complètent le tableau, et ce sont eux que l’on néglige le plus : le code d’état, qui dit ce qu’on a le droit de faire du conteneur, et le code de révision, qui dit à quelle version on a affaire.
La liste précise, l’ordre et le nombre de champs relèvent d’annexes nationales, pas du corps de la norme. Le modèle à dix champs souvent présenté comme « la » convention ISO 19650 est en réalité l’annexe britannique. Rien ne vous oblige à l’adopter tel quel : ce qui compte, c’est de fixer vos champs, dans votre convention, et de vous y tenir. Copier une annexe étrangère sans l’adapter est une autre façon de ne pas décider.
C’est le champ le plus riche de conséquences, et le plus mal compris. Un code de révision ne dit pas seulement « c’est la deuxième version », il dit dans quel régime cette version a été émise.
L’annexe la plus répandue distingue deux familles de révisions. Les révisions préliminaires, préfixées d’un P, désignent une information en cours d’élaboration, partagée pour coordination ou revue, mais qui n’engage pas encore. Les révisions contractuelles, préfixées d’un C, désignent une information validée, publiée pour un usage, et qui engage celui qui l’a émise.
Il inscrit dans le nom du fichier la frontière entre ce qui engage et ce qui n’engage pas. Construire sur un P, c’est construire sur une intention. Le préfixe rend cette erreur visible avant qu’elle soit commise, sans ouvrir le document ni interroger personne. C’est le lien direct avec les états du CDE : le code de révision est la trace, dans le nom, de l’état par lequel le conteneur est passé.
La plupart des conventions de nommage sont excellentes sur le papier et mortes en pratique. La différence ne tient pas à leur qualité, mais à une seule question : qui la fait respecter ?
N’ajoutez un champ que si vous saurez le remplir de façon fiable et si vous vous en servirez pour filtrer. Un champ que personne ne sait renseigner produit des valeurs fausses, et une valeur fausse est pire qu’un champ absent : elle inspire une confiance qu’elle ne mérite pas. La bonne convention est la plus courte qui réponde à vos questions réelles, pas la plus complète.
Le nommage n’est pas un sujet de documentaliste. C’est l’infrastructure invisible sans laquelle tout le reste du management de l’information reste manuel.
Trois idées à emporter. Un nom structuré est une donnée, pas une étiquette : ses champs sont des colonnes lisibles par une machine, et c’est cela qui permet de trier, filtrer et contrôler ce qu’aucun œil ne suit sur des milliers de fichiers. Le code de révision porte une frontière contractuelle : un P désigne une information qui n’engage pas, un C une information validée, et confondre les deux, c’est construire sur une intention. Enfin, une convention ne vaut que contrôlée automatiquement : sur le papier elle meurt, imposée par l’outil au dépôt elle tient, à condition d’être aussi courte que possible.
Le code de révision est la trace, dans le nom, du parcours décrit dans les états du CDE. La convention où tout ceci se fixe est la convention BIM, et le processus qui l’englobe est l’ISO 19650-2 pas à pas. Le nommage étant régi par des annexes nationales, voyez aussi les guides sur les cadres nationaux avant de figer vos champs.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Créer quatre répertoires et y ranger des fichiers ne fait pas un CDE. Un état ne dit pas où se trouve une information : il dit ce que vous avez le droit d'en faire, et qui répond si elle est fausse. Toute la valeur est dans les passages de l'un à l'autre.
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-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.