Dans beaucoup d’équipes métier (projeteurs, méthodes, BIM management, etc.), le contenu existe déjà.

Les familles Revit sont quelque part. Les blocs AutoCAD aussi. Les gabarits, les nomenclatures, les objets issus d’anciens projets et les bibliothèques métiers se sont constitués au fil du temps.

Souvent, tout cela finit dans un SharePoint, sur un serveur partagé, dans une GED ou sur un disque local.

À première vue, le sujet semble donc réglé.

Les fichiers sont stockés. Les équipes peuvent y accéder. Les dossiers sont organisés par projet, agence, discipline ou type d’objet.

Mais dans la pratique, ce n’est pas si simple.

Une famille validée peut être présente sur le serveur, sans être retrouvée par le projeteur. Une autre version peut exister dans un ancien projet. Une variante peut rester sur le poste d’un utilisateur. Un objet téléchargé sur Internet peut être corrigé localement, sans jamais revenir dans la bibliothèque commune.

SharePoint ne sert qu’à stocker du contenu.

C’est précisément pour cela qu’il devient souvent le réflexe naturel lorsqu’une équipe BIM cherche à centraliser ses contenus.

Un dossier pour les familles Revit, un autre pour les blocs DWG. Par agence. Par projet. Un dossier « validé », un dossier archives, parfois un dossier « ancienne version ».

En solo, ce fonctionnement peut tenir. Mais dès que plusieurs personnes doivent travailler sur les mêmes contenus, il ne fonctionne plus.

À l’échelle d’un groupe, d’une BU ou de plusieurs agences, il finit souvent par montrer ses limites.

Non pas parce qu’on utilise mal SharePoint.

Mais parce qu’une bibliothèque BIM ne fonctionne pas comme une simple bibliothèque documentaire.

Un objet BIM n’est jamais un simple fichier à ranger. C’est un fichier technique qui embarque des données, des formats différents, et qui encapsule un savoir-faire métier — au point de mériter une solution dédiée pour l’exploiter pleinement.

C’est un contenu métier, avec une géométrie, des types, des paramètres, des valeurs, une version logiciel, une codification, parfois une classification, parfois des données projet, parfois des règles d’usage.

Dans SharePoint, on retrouve principalement un contenu par son nom, son emplacement ou son dossier.

Encore faut-il savoir comment il a été nommé.

Par exemple, un projeteur cherche une bouche d’extraction, un diffuseur mural, un raccord CVC, une vanne, une bouche rectangulaire ou un bloc DWG métier.

S’il ne connaît pas le nom exact, il doit parcourir l’arborescence, ouvrir plusieurs dossiers, comparer plusieurs fichiers, vérifier la date, parfois ouvrir la famille ou le DWG pour comprendre ce qu’il contient.

Et si la recherche prend trop de temps, le réflexe terrain est connu : reprendre une famille d’un ancien projet, télécharger un objet en ligne, ou recréer une variante.

C’est comme cela qu’une bibliothèque commune se fragmente. Pas d’un coup. Mais par petites décisions quotidiennes, prises sous contrainte de production.

Une bibliothèque BIM exploitable doit permettre de répondre à des questions que SharePoint ne sait pas traiter nativement.

Quel est le type de cet objet ? À quelle discipline appartient-il ? Quel fabricant est associé ? Quel niveau de détail ? Quels paramètres sont présents ? Quelles valeurs sont renseignées ? Dans quelle version Revit l’objet est-il utilisable ? Est-il publié ou encore en cours de préparation ? Qui peut le modifier ? Qui peut le publier ?

Ces questions ne relèvent pas du stockage. Elles relèvent de la gouvernance de contenu BIM. C’est précisément le rôle d’Onfly.

La migration depuis SharePoint ou depuis un serveur partagé ne doit pas forcément repartir de zéro.

L’arborescence existante peut servir de point de départ.

Dans Onfly, les contenus peuvent être importés depuis un dossier local, un serveur ou un dossier SharePoint synchronisé. On peut reprendre les noms des dossiers sous forme de tags. Une structure du type CVC / Diffuseurs / Fabricant / Projet type peut donc devenir une première couche d’organisation exploitable.

Mais l’intérêt n’est pas de copier SharePoint dans Onfly : il est surtout d’aller plus loin.

Une fois importés, on peut ranger les objets dans des collections, leur associer des tags, les relier à des classifications, les enrichir de propriétés et les rechercher par leurs valeurs.

Dans beaucoup d’équipes, la bibliothèque commence par les familles RFA.

C’est logique : elles sont visibles, réutilisées, souvent critiques dans les maquettes.

Mais le contenu BIM ne s’arrête pas là.

Une bibliothèque peut aussi contenir des familles système, des types de murs, des canalisations, des feuilles, des nomenclatures, des matériaux, des styles de lignes, des motifs, des vues de dessin ou des éléments issus de gabarits et de projets existants.

Côté infra ou ingénierie, le sujet s’élargit encore : blocs DWG, objets AutoCAD, contenus Civil 3D, Covadis, Mensura, chartes graphiques, calques, objets métiers et données à transmettre à d’autres services.

C’est une différence importante. Si la bibliothèque reste pensée comme un dossier de fichiers Revit, elle ne couvre qu’une partie de la réalité de production.

Onfly permet de traiter cette bibliothèque comme un environnement de contenus métier, accessible depuis les outils utilisés par les équipes.

Dans SharePoint, beaucoup d’informations finissent dans le nom du fichier. Un préfixe pour le lot. Un acronyme pour le type. Un fabricant. Une version. Un usage projet.

Cette logique peut fonctionner un temps, mais elle atteint vite ses limites. Plus le nom porte d’informations, plus il devient long, fragile et difficile à maintenir.

Dans Onfly, une partie de ces informations sort du nom de fichier pour devenir de la donnée structurée : tags, collections, classifications, propriétés ou valeurs.

Un fabricant, une codification interne ou un niveau de détail deviennent alors des critères de recherche à part entière. On peut ainsi chercher un objet par ses propriétés et leurs valeurs, par un critère, ou plusieurs combinés.

Une bibliothèque BIM doit aussi répondre à une question simple : qui a le droit de faire quoi ?

Dans SharePoint, tout dépend souvent des droits d’accès au dossier. Mais dans une bibliothèque BIM, le sujet est plus fin.

Consulter et télécharger un objet sans pouvoir le modifier : c’est le rôle de l’utilisateur. Proposer ou ajouter du contenu revient au créateur. Le valideur, lui, publie l’objet pour le rendre visible aux utilisateurs finaux. Quant à l’administrateur, il organise la bibliothèque : accès, tags, collections, classifications, règles de structuration.

La logique publié / non publié devient importante. On peut préparer, enrichir ou corriger un objet non publié sans le mettre à disposition de toute l’équipe. Une fois publié, il devient disponible pour les membres.

Ce n’est pas seulement une question de sécurité : c’est avant tout une manière d’éviter que la bibliothèque commune redevienne un espace où chacun dépose, modifie ou récupère des contenus sans cadre.

Le problème d’une bibliothèque BIM n’est pas seulement son organisation. C’est aussi son usage.

Si l’utilisateur doit quitter Revit, AutoCAD, Civil 3D, Mensura ou Covadis pour fouiller dans SharePoint, télécharger un fichier, vérifier s’il est à jour, puis l’insérer manuellement, la bibliothèque reste à distance de la production.

Avec Onfly, l’accès se fait directement depuis les outils métier via les plugins. L’utilisateur peut rechercher un objet, filtrer les résultats, consulter les données disponibles, vérifier l’aperçu ou la vignette, puis insérer le contenu dans son environnement de travail.

Passer de SharePoint à Onfly ne signifie pas repartir de zéro. La bonne méthode consiste à avancer progressivement.

Le but n’est pas de refaire toute la bibliothèque en une fois. Le but est de transformer un stockage documentaire existant en bibliothèque BIM réellement exploitable.

SharePoint peut très bien stocker vos familles Revit, vos blocs DWG ou vos fichiers de référence. Mais stocker un contenu ne suffit pas à en faire une bibliothèque BIM.

Une bibliothèque BIM doit permettre de retrouver le bon objet, de comprendre ses données, de savoir s’il est validé, de maîtriser qui peut le modifier, et de le rendre accessible dans les outils métier.

C’est là que SharePoint atteint ses limites. Et c’est là qu’Onfly prend le relais.

Non pas pour déplacer des fichiers d’un endroit à un autre. Mais pour transformer des contenus dispersés en objets structurés, recherchables, gouvernés et utilisables par les équipes.