Dans une étude énergétique, la ressaisie est souvent réduite à une image simple : recopier une information d’un logiciel vers un autre. C’est la partie la plus visible du problème, mais rarement la seule. À chaque changement d’outil, le professionnel doit aussi retrouver le bon projet, vérifier que les champs correspondent, reconstruire le contexte d’une donnée, contrôler ce qui a été transformé à l’export et parfois arbitrer entre deux versions devenues différentes.
Le coût réel d’une rupture ne se mesure donc pas uniquement au nombre de frappes clavier. Il comprend le temps de rapprochement, les contrôles supplémentaires et le risque d’erreur créé par le fait qu’une même information existe à plusieurs endroits. Plus le dossier avance — qualification, préparation, visite, métrés, calcul, scénarios, restitution — plus ces petites ruptures peuvent s’additionner.
Pour comprendre où agir, il est utile de suivre une étude de bout en bout. La question n’est pas de chercher « un outil qui fait tout », mais d’identifier quelles données doivent réellement continuer à circuler sans être reconstruites à chaque étape.
La première perte apparaît souvent avant même la visite
Un dossier peut commencer dans un CRM, un formulaire, un tableur, un portail d’entreprise ou simplement dans un échange d’e-mails. Le professionnel récupère ensuite l’adresse, un DPE, des plans, quelques informations sur le logement et le motif de la demande. Si ces éléments doivent être ressaisis dans l’outil d’étude, la première rupture a déjà eu lieu avant que le travail technique ne commence.
Cette duplication paraît souvent anodine parce qu’elle concerne des informations simples. Pourtant, elle crée immédiatement plusieurs versions du même projet : l’adresse dans le CRM, le logement dans le logiciel d’étude, des pièces jointes dans une messagerie et parfois un dossier partagé contenant les plans. Lorsqu’une information évolue, rien ne garantit que toutes les copies évoluent avec elle.
Les données accessibles à partir de l’adresse ou d’un diagnostic existant peuvent justement réduire cette phase de reconstruction. Nous avons détaillé ce qu’il est possible de récupérer à partir d’une adresse et comment un DPE existant peut préparer une étude. Leur intérêt ne tient pas seulement au préremplissage : il vient aussi du fait qu’une information acquise une première fois peut servir aux étapes suivantes.
Le terrain crée beaucoup de données difficiles à retranscrire
La visite concentre un grand nombre d’informations hétérogènes : mesures, caractéristiques d’enveloppe, équipements, observations, photographies, documents transmis par l’occupant et parfois corrections de la géométrie. Lorsque ces éléments sont collectés dans des supports séparés, le retour au bureau devient un exercice de reconstruction.
Une cote notée sur papier doit être rapprochée du bon mur. Une photo de plaque signalétique doit être associée au bon équipement. Une observation saisie dans une application de notes doit être replacée dans le contexte du plan. Si le professionnel doit ensuite ressaisir ces informations dans un moteur de calcul, la perte de temps n’est pas seulement la saisie : c’est le travail nécessaire pour retrouver le sens de chaque donnée.
C’est pour cette raison qu’une visite d’audit bien préparée gagne à partir d’un dossier déjà structuré. La donnée terrain peut alors corriger ou enrichir un élément existant au lieu d’être collectée dans un univers parallèle qu’il faudra fusionner plus tard.
Les métrés montrent bien la différence entre exporter et transmettre
Les métrés sont un bon exemple de rupture silencieuse. Un plan peut être réalisé dans un outil, les surfaces extraites dans un second, puis les parois recréées dans un logiciel réglementaire. Même lorsqu’un export existe, il ne transporte pas toujours toute la logique qui a servi à produire la géométrie : conditions limites, locaux chauffés ou non chauffés, singularités, regroupements de parois ou exclusions.
Le professionnel doit alors contrôler l’export et parfois corriger manuellement ce qui n’a pas été compris de la même façon par l’outil suivant. Cette étape est normale lorsqu’on passe entre deux modèles de données différents ; elle devient coûteuse lorsque l’information est systématiquement réduite à un fichier intermédiaire puis reconstruite.
L’enjeu n’est donc pas de supprimer tout contrôle. Il est de distinguer le contrôle métier utile de la ressaisie pure. Nous avons montré dans l’article consacré aux métrés à vérifier sur place qu’une géométrie fiable dépend autant de la topologie et des conditions limites que de la précision d’une cote. Une bonne transmission doit préserver suffisamment de structure pour que le contrôle porte sur le fond, pas sur la reconstruction du dossier.
Le calcul, les scénarios et le rapport recréent souvent les mêmes informations
Une fois l’état initial établi, le dossier continue à évoluer. Les hypothèses de travaux sont définies, des scénarios sont comparés, des coûts ou aides sont associés, puis les résultats doivent être restitués. Lorsque chaque étape utilise son propre outil, le même intitulé de travaux, la même surface ou le même résultat peut être recopié plusieurs fois.
| Passage | Perte fréquente |
|---|---|
| Visite → étude | Notes, photos et mesures à rattacher au bon élément |
| Géométrie → moteur de calcul | Parois, surfaces et conditions limites à reconstruire |
| Calcul → scénarios | Hypothèses de travaux dupliquées ou reformulées |
| Scénarios → rapport | Résultats, coûts et commentaires recopiés dans un document |
| Étude → CRM / suivi | Statut et informations utiles retranscrits manuellement |
Le risque n’est pas seulement chronophage. À mesure que les copies se multiplient, une correction peut ne pas être répercutée partout. Une surface modifiée après la visite peut rester inchangée dans un tableur de chiffrage ; un scénario ajusté dans le moteur de calcul peut ne pas correspondre exactement à celui décrit dans le rapport.
La continuité de donnée devient alors un sujet de fiabilité autant que de productivité. Une information ne devrait pas être considérée comme « terminée » parce qu’elle a quitté un outil : elle continue à participer au projet et peut encore évoluer.
Le vrai coût est souvent dans les contrôles rendus nécessaires par les ruptures
Une équipe expérimentée compense beaucoup de défauts d’interopérabilité par des habitudes. Elle sait quel export contrôler, quel champ ne jamais reprendre sans vérification, où chercher la dernière version d’un plan et comment reconnaître une incohérence avant qu’elle n’atteigne le rapport. Cette compétence masque parfois le coût du système, parce que les erreurs sont évitées au prix d’un travail invisible.
Pour évaluer ce coût, il est plus utile d’observer une étude complète que de chronométrer une seule saisie. Combien de fois la même information est-elle recherchée ? Combien de contrôles sont nécessaires uniquement parce qu’elle a changé de format ? Combien de fois un professionnel doit-il revenir à une photo, un PDF ou un tableur pour retrouver le contexte d’une valeur déjà saisie ailleurs ?
Cette analyse fait souvent apparaître que les gains les plus intéressants ne viennent pas de la suppression de quelques champs. Ils viennent de la réduction du nombre de transitions où le professionnel doit reconstituer ce qu’il savait déjà.
Chercher la continuité plutôt que le logiciel unique
La solution n’est pas nécessairement de concentrer toutes les fonctions dans un seul logiciel. Un outil réglementaire certifié, un CRM, un logiciel de devis ou une solution de gestion peuvent chacun rester légitimes dans leur rôle. Le vrai critère est la capacité du dossier à traverser ces outils sans perdre sa structure ni imposer une reconstruction systématique.
Cela suppose de regarder les exports disponibles, les API, les formats standards et surtout le modèle de données manipulé. Un export IFC, par exemple, peut être utile pour transmettre une géométrie structurée ; une API peut synchroniser un statut ou un prospect ; un export vers un logiciel DPE/audit peut éviter de recréer certaines données déjà collectées. Mais la technologie d’échange n’a de valeur que si l’information transmise reste exploitable par l’étape suivante.
C’est cette logique que renOdit cherche à appliquer : partir des données existantes, préparer le bâtiment, enrichir le même dossier en visite, construire les scénarios puis produire ou transmettre les livrables nécessaires. L’objectif n’est pas de supprimer les outils métier spécialisés, mais de faire en sorte que la fin d’une étape ne redevienne pas le début d’une saisie.
Pour un auditeur ou un BET, la première question à poser à son organisation n’est donc pas « combien de logiciels utilisons-nous ? ». Elle est plus concrète : à quels endroits de notre processus devons-nous reconstruire une information que nous possédions déjà ? C’est généralement là que se trouvent les gains de productivité les plus accessibles.
