Sortir des données de la maquette vers Excel est facile. Les réécrire dans la maquette après les avoir modifiées, voilà où presque tout se casse. Un aller-retour n'est pas une synchronisation : ce sont deux trajets à sens unique collés bout à bout, sans fusion, sans arbitre. Il ne marche que si l'on maîtrise trois choses, et les ignorer ne laisse pas la maquette en l'état : cela la corrompt.
Le mot « aller-retour » laisse croire à un échange continu où les deux côtés resteraient d’accord. Ce n’est jamais ce qui se passe, et cette illusion est la source de la plupart des dégâts.
Ce qui existe réellement, ce sont deux trajets à sens unique : un export de la maquette vers Excel, puis un import d’Excel vers la maquette. Entre les deux, personne ne compare, personne n’arbitre les conflits, personne ne fusionne. Le second trajet écrase ce qu’il trouve avec ce qu’Excel contient. Si le tableur a vieilli, ou si la maquette a bougé entre-temps, la réécriture ne rapproche pas les deux versions : elle impose l’une à l’autre, en silence.
Ce guide suppose acquise la question de la sortie, traitée dans sortir la donnée de Revit vers Power BI, et l’outil qui exécute ces transferts, présenté dans Dynamo. Il porte sur ce que ces deux-là ne traitent pas : le retour, et les conditions pour qu’il enrichisse la maquette au lieu de l’abîmer.
Ne pensez pas « synchroniser la maquette et Excel », pensez « écrire dans la maquette des valeurs dont je réponds ». Un aller-retour n’a aucune intelligence : il fait exactement ce qu’on lui dit, sur les lignes qu’on lui donne, sans se demander si c’est raisonnable. Toute la maîtrise consiste à ne lui confier que ce qu’on contrôle, et à savoir, à chaque instant, quelle version fait foi.
Excel reste irremplaçable pour une chose : éditer en masse des données qu’un humain doit relire et corriger. Encore faut-il distinguer ce qui se prête à ce traitement de ce qui n’y a pas sa place.
Un aller-retour Excel sert à éditer de la donnée qu’un humain curate, pas à télépiloter la maquette. Dès que la tentation est de recréer par tableur ce qui relève de la modélisation, on est sorti du bon usage : le résultat sera fragile et se paiera à la réécriture. La bonne question n’est pas « puis-je le faire passer par Excel », mais « cette donnée gagne-t-elle vraiment à être relue à plat, et suis-je celui qui en répond ? ».
Un aller-retour réussit ou échoue selon trois paramètres, et il suffit qu’un seul manque pour que le retour dégrade la maquette au lieu de l’enrichir.
Chaque ligne du tableur doit porter un identifiant qui désigne sans ambiguïté l’objet à réécrire, stable entre l’aller et le retour. Sans elle, on relit peut-être la donnée, mais on ne sait plus à quel objet la rendre : le retour est impossible, ou pire, il vise le mauvais.
Pour chaque champ, un seul côté fait foi à un instant donné. Si la maquette et le tableur sont édités en parallèle sur la même colonne, le dernier trajet écrase l’autre sans le savoir. Décider qui détient la vérité, et quand, n’est pas un détail d’organisation : c’est la condition du retour.
Excel reformate ce qu’il touche : il transforme un code en nombre, mange les zéros de tête, réinterprète les dates, arrondit. Une valeur partie intacte peut revenir déformée, et le retour écrit alors une donnée fausse par-dessus une donnée juste.
Ces conditions ne se remplacent pas. Une clé parfaite ne sert à rien si le tableur a vieilli et écrase des valeurs plus récentes. Une direction claire ne protège pas si Excel a corrompu les codes au passage. Et une fidélité parfaite est inutile si l’on ne sait plus quel objet chaque ligne désigne. Un aller-retour n’est fiable que lorsque les trois tiennent ensemble, à chaque cycle.
Le trajet aller pardonne beaucoup : au pire, on relit un export imparfait. Le trajet retour, lui, modifie la maquette, et ses erreurs sont durables. Quatre pièges reviennent, tous silencieux.
Aucun ne provoque d’erreur bruyante : la maquette accepte la réécriture et paraît intacte. C’est ce qui les rend dangereux, exactement comme le faux vert d’un contrôle. Le seul rempart est de contrôler le résultat dans la maquette après le retour, sur quelques objets pris au hasard, et non de se fier au fait que l’import s’est « bien passé ».
Fait dans le bon ordre, l’aller-retour devient sûr et répétable. Chaque étape ferme l’un des pièges précédents.
Lister les colonnes qu’on va éditer, et acter que votre équipe en est la source de vérité le temps du cycle. Ce qui appartient à un autre système ne part pas dans le tableur.
Chaque ligne emporte l’identifiant stable de son objet, et les colonnes sensibles sont forcées en texte pour survivre à Excel. On n’exporte que ce qu’on va éditer.
On corrige les seules colonnes prévues. On ne réordonne pas, on ne supprime pas de lignes, on ne remplit pas les vides par distraction : une cellule laissée vide effacera la valeur au retour.
Le retour cible les champs inscriptibles décidés au départ, en visant l’occurrence ou le type à bon escient. Il ne réinjecte pas le tableau entier, seulement ce qui a changé.
On rouvre quelques objets modifiés et l’on vérifie que la bonne valeur est au bon endroit, non déformée, et qu’aucun champ voisin n’a été effacé. Cinq minutes, sur le modèle réellement écrit.
Avant tout retour, conservez un état de la maquette auquel revenir. Un aller-retour n’ayant ni fusion ni annulation fine, la seule vraie protection contre une réécriture massive erronée est de pouvoir restaurer l’état antérieur. C’est la même prudence que pour tout traitement automatique qui modifie en lot : on ne lance pas sans filet un geste qu’on ne pourra pas défaire objet par objet.
Un aller-retour Excel n’est pas une commodité anodine : c’est une écriture en masse dans la maquette, aussi puissante que risquée.
Trois idées à emporter. Ce n’est pas une synchronisation, mais deux trajets sans fusion : le retour écrase, il n’arbitre pas, et un tableur vieilli impose ses valeurs sans prévenir. Trois conditions le rendent fiable : une clé d’appariement stable pour savoir quel objet réécrire, une direction d’autorité claire pour savoir qui fait foi et quand, et la fidélité des valeurs face à un Excel qui déforme codes, dates et unités. Enfin, le danger est tout entier au retour : paramètres de type propagés à tort, champs non inscriptibles, écrasement des vides et déformations silencieuses ne se voient qu’en contrôlant le résultat dans la maquette, filet de sauvegarde en main.
L’outil qui exécute proprement ces transferts et écrit les clés en masse est Dynamo. Le trajet unidirectionnel vers un tableau de bord, sans réécriture, est traité dans sortir la donnée de Revit vers Power BI. Et pour que les objets soient joignables et proprement typés avant tout aller-retour, tout commence par modéliser proprement.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
L'interface visuelle supprime la syntaxe, pas le raisonnement. Ce qui arrête les débutants n'est jamais l'interface : c'est la gestion des listes. Et ce qui coûte cher ensuite n'est pas d'écrire le script, c'est de le maintenir vivant quand Revit change de version.
Une fois qu'on sait quelle colonne reliera la maquette au reste, reste à faire sortir la donnée de Revit. Là, plusieurs tuyaux existent, et ils ne se valent pas : l'un livre un instantané figé qu'il faut refaire à la main, l'autre un flux qui se réalimente seul. Ils se départagent sur deux questions seulement, et les poser avant de brancher évite de reconstruire un tableau de bord tous les lundis.
Une maquette peut être irréprochable à l'écran et inutilisable en aval. Elle peut être visuellement grossière et parfaitement exploitable. La propreté d'un modèle ne se juge pas en le regardant : elle se juge à ce que les autres peuvent en faire.