Exports et diffusion

Sortir la donnée de Softee, dans le format attendu par le destinataire

Le reporting énergétique finit toujours par sortir de l’outil : dans un tableur pour la direction, dans un fichier pour un tiers, dans un système d’information pour la consolidation. Voici les chemins de sortie qui existent réellement — et, aussi précisément, ceux qui n’existent pas.

Pour les responsables énergie et les équipes système qui doivent alimenter un reporting interne, un tiers ou un entrepôt de données, sans ressaisie.

Demander une démonstration

Comment sortir des données dans un tableur ?

Par un export tableur que vous paramétrez sur quatre axes, depuis l’espace de gestion. C’est l’export que vous déclenchez vous-même, et celui qui couvre la majorité des demandes ponctuelles.

Les sources

indicateurs, paramètres de site, types de capteurs.

L’intervalle

douze derniers mois, dernier jour, année, mois ou semaine en cours, ou dates libres.

L’agrégation

jour, mois, trimestre, semestre, année.

Le regroupement

catégories de sites, compteurs, types de capteurs, énergies, indicateurs.

Peut-on programmer un export récurrent ?

Oui : un export quotidien, hebdomadaire ou mensuel, produit en CSV, Excel ou JSON, et livré par l’un de quatre chemins — téléchargement, dépôt sur un FTP, e-mail avec objet et destinataires en To, Cc et Cci, ou publication sur une file de messages, file ou échange avec clé de routage.

Un export planifié se met en place avec vous : sa configuration est assurée par l’équipe Softee, et non depuis l’interface.

Un format attendu par un tiers. Un mode d’export produit un fichier au format fixe attendu par une plateforme ESG tierce, à partir d’une sélection de types de capteurs.

La capacité est réelle et vérifiable dans le code ; nous ne nommons pas la plateforme, faute d’un accord qui nous autoriserait à le faire. Le singulier est exact : il n’y a qu’un format de ce type.

Existe-t-il une API pour récupérer les données ?

Oui. Le produit expose une API REST dont la spécification OpenAPI est publiée par l’application, consultable sous ReDoc et Swagger UI. Ce n’est pas un argument théorique : le client de l’application est lui-même généré depuis cette spécification, donc la spécification est à jour par construction plutôt que par bonne volonté.

Deux précisions qui vous éviteront un malentendu : l’accès reste authentifié, et il n’existe pas de portail développeur public. Ce n’est pas une API ouverte — c’est l’API du produit, documentée.

Quels autres chemins de sortie existent ?

Trois, ciblés : l’export des données d’un capteur, l’export du contrôle de complétude des contrats, et la notification e-mail d’alerte aux destinataires définis, déclenchée par l’évaluation quotidienne.

Et la restitution à l’écran, qui n’est pas un export mais reste un chemin de diffusion : les tableaux de bord composables, consultables par les utilisateurs que votre administrateur a autorisés — trois espaces séparent la consultation, la gestion et l’administration, avec une matrice de droits par rôle.

Ce qui n’existe pas, et que nous ne suggérerons pas

  • Aucun export PDF de rapport, et aucun rapport mis en page envoyé automatiquement.
  • Aucun connecteur Power BI ou tableur en direct. Les données sortent en fichier, par file de messages ou par l’API — il n’y a pas de source de données à brancher.
  • Aucun webhook sortant en dehors de la file de messages des exports planifiés.
  • Aucune génération de rapport réglementaire. Le produit ne produit pas de document destiné à une administration, et il ne dépose rien sur OPERAT.
  • Aucun nom de plateforme tierce. L’export au format d’une plateforme ESG tierce existe ; nous le décrivons génériquement, faute d’accord pour la nommer.

Questions fréquentes sur les exports et le reporting

Un export tableur à la demande, et des exports planifiés en CSV, Excel ou JSON. Les exports planifiés se livrent par téléchargement, dépôt FTP, e-mail avec objet et destinataires en To, Cc et Cci, ou publication sur une file de messages. L’API REST du produit renvoie du JSON.
Oui : un export quotidien, hebdomadaire ou mensuel, en CSV, Excel ou JSON, livré par téléchargement, FTP, e-mail ou file de messages. L’export planifié est paramétré avec vous par l’équipe Softee, et non depuis l’interface.
Oui. Le produit expose une API REST dont la spécification OpenAPI est publiée par l’application, consultable sous ReDoc et Swagger UI ; le client de l’application est généré depuis cette spécification, ce qui la maintient à jour par construction. L’accès reste authentifié et il n’existe pas de portail développeur public : ce n’est pas une API ouverte, c’est l’API du produit, documentée.
Non. Il n’existe aucun export PDF de rapport, aucun rapport mis en page envoyé automatiquement, aucun connecteur Power BI ou tableur en direct, et aucune génération de rapport réglementaire. Les sorties disponibles sont le fichier tableur, CSV ou JSON, la file de messages, l’e-mail d’alerte et l’API REST.
Pas par un connecteur dédié : il n’en existe aucun, ni pour Power BI ni pour un tableur en direct. Les deux chemins réels sont l’API REST authentifiée, documentée par sa spécification OpenAPI, et l’export planifié déposé sur un FTP ou publié sur une file de messages, en CSV ou JSON. C’est suffisant pour alimenter un entrepôt de données, à condition de prévoir le travail d’intégration côté vous.
Non. Aucun code du produit livré n’échange avec un système de l’ADEME, et le produit ne génère pas de fichier au format d’import OPERAT. Les exports sortent en tableur, CSV ou JSON, selon un paramétrage que vous choisissez ; la saisie sur la plateforme reste la vôtre. Nous ne l’annonçons pas non plus comme une évolution à venir.

Dites-nous qui consomme vos données

Un tableau de bord de direction, un tiers avec son format imposé, un entrepôt de données interne. Nous vous disons par lequel de ces chemins ça passe — ou s’il n’y en a pas, ce qui est une réponse utile plus tôt que tard.

Demander une démonstration