--- title: "Exposer et visualiser vos données" description: "Découvrez comment exposer vos requêtes via une API et construire une application de dashboard qui l'exploite, sans écrire de code" url: https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-expose-and-visualize lang: fr lastUpdated: 2026-10-23 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt. # Exposer et visualiser vos données ## Objectif Une **API** expose les données de votre Projet au monde extérieur, et une **application** les transforme en un dashboard que vos utilisateurs peuvent ouvrir. Dans cette dernière étape du guide Premiers pas, vous déployez les deux, l'une après l'autre : 1. **Déployer une API**, l'interface entre le monde extérieur et le reste de votre Projet, pour que les applications puissent exécuter vos requêtes en HTTP. 2. **Construire l'application qui la lit**, le site qu'ouvrent vos utilisateurs, avec un dashboard et deux graphiques tirés de vos propres données. Vous n'écrivez aucun code, ni pour l'une ni pour l'autre. La Data Platform fournit un template pour chacune : - **Query API** crée une _Front API_, un service qui expose les données de votre Projet en HTTP. Vos applications lui envoient leurs requêtes, y compris celles enregistrées dans votre [Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-analytics-manager.md), et elle peut conserver les résultats dans un cache. - **Mosaic** crée une _Front App_, l'application web que vos utilisateurs ouvrent, avec un menu, une mise en page et une bibliothèque de graphiques. Ses pages sont décrites dans des fichiers de configuration plutôt qu'écrites en code : vous les construisez dans le _Visual Editor_, un éditeur que l'application elle-même sert dans la console. Il ne vous reste qu'à nommer les éléments et à décrire ce que vous voulez voir. Pour une vue d'ensemble des API et des applications au-delà de ce guide, consultez [Application APIs](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-app-services-apis.md) et [Applications de la Data Platform](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-app-services-apps.md). ## Prérequis Réalisez d'abord les étapes précédentes du guide Premiers pas : vos [sources sont connectées](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-connect-sources.md), votre [schéma Lakehouse Manager est construit](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-organize-data.md), votre [workflow s'est exécuté](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-prepare-data.md) et vos [requêtes renvoient des données](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-create-queries.md). Le deuxième graphique de cette page réutilise la requête `rides_per_cat_temperature` que vous avez enregistrée lors de cette dernière étape. Prévoyez un peu d'attente en cours de route : cette page lance 3 builds et 3 déploiements, qui prennent chacun quelques minutes. ## Partie 1 : exposer vos données via une API ### Créer l'API Depuis votre Projet, ouvrez **Applications & APIs**. La liste affiche chaque application et chaque API déployées dans le Projet, avec leur type, leur URL et leur statut. Cliquez sur **+ ADD**. La boîte de dialogue _Choose application type_ propose trois types d'application : - **Front App** : une application front-end qui utilise les données exposées par vos API. - **Front API** : une API qui expose les données des services de votre Projet. - **Apache Superset** : une instance Apache Superset prête à l'emploi. Sélectionnez **Front API**, puis cliquez sur **NEXT**. ### Configurer sa première version Dans **Application name**, saisissez `rides`. La Data Platform en déduit le nom technique et l'URL : votre API est servie sur `/rides-api/`. Laissez **Source** sur _From Template_. Il n'y a pas de nom de version à choisir : la première version d'une application est toujours `v1`. Une version est un instantané déployable de votre API : vous pourrez ajouter une `v2` plus tard sans jamais arrêter la `v1`. Sous **Select a template**, choisissez **Query API (Node + Express)**. Ce template permet à vos applications d'exécuter des requêtes sur vos données en HTTP, y compris les requêtes enregistrées dans votre Analytics Manager. Cochez ensuite les 3 options : - **Enable cache** : déployer un cache en mémoire (Valkey) à côté de l'API, pour que les appels répétés n'interrogent pas de nouveau votre entrepôt de données. Les valeurs par défaut de **Engine & version** et **Allocated DPU (%)**, _Valkey 8.1.10-alpine_ et 20 %, suffisent pour ce guide. - **Auto Build** : lancer un build dès la création de la version. - **Auto Deploy** : déployer la version dès que le build réussit. Avec les deux dernières options, un seul clic télécharge, construit et déploie votre API. Cliquez sur **CREATE**. ### Laisser le build s'exécuter La Data Platform ouvre la vue d'ensemble de votre nouvelle API. À gauche, _Versions_ liste `v1` avec le build qu'Auto Build vient de lancer : aucune version n'est encore déployée. À droite, _Information_ affiche le nom technique, `rides-api`, et l'application IAM qui protège votre API. Le build prend quelques minutes. **Note :** La Data Platform utilise une **méthode de déploiement [blue-green](https://en.wikipedia.org/wiki/Blue-green_deployment)**, ce qui vous permet de déployer de nouvelles versions de votre API sans interruption de service. Lorsque le build réussit, Auto Deploy prend le relais. Lorsque vous revenez dans **Applications & APIs**, votre API apparaît avec le statut _Running_. ### Vérifier que votre API répond Ouvrez votre API : cliquez sur son URL dans la colonne _URL_ de la liste, ou sur **Open app** dans la carte _Deployed version_ de sa vue d'ensemble. Votre API répond avec une page d'accueil. Votre API est déployée et accessible. L'application que vous créez ensuite se connecte à cette URL : son formulaire la propose dans le champ **API URL**. ## Partie 2 : visualiser vos données dans une application ### Créer l'application De retour dans **Applications & APIs**, cliquez sur **+ ADD**, sélectionnez **Front App** et cliquez sur **NEXT**. Remplissez le formulaire : - **Application name** : `analytics`. La Data Platform en déduit l'URL : votre application est servie sur `/analytics-app/`. - **API URL** : sélectionnez l'URL de l'API `rides` que vous venez de déployer. C'est ce champ qui connecte votre application à votre API. - **Select a template** : **Mosaic**. - Cochez **Auto Build** et **Auto Deploy**, pour que la version soit construite et mise en ligne d'elle-même. Comme pour votre API, la première version s'appelle `v1`. Une Front App ne propose pas de cache : elle sert les pages qu'ouvrent vos utilisateurs, tandis que les données et leur cache restent du côté de l'API. Cliquez sur **CREATE**. La Data Platform ouvre la nouvelle application pendant le build de sa première version. Le build prend quelques minutes. Lorsque le build réussit, Auto Deploy prend le relais. Dans la vue d'ensemble, la carte _Deployed version_ affiche maintenant `v1` en cours d'exécution, avec les boutons qui agissent sur elle : **Open app**, **Edit** et **Visual Editor**. ### Ouvrir le Visual Editor Cliquez sur **Visual Editor** dans la carte _Deployed version_. La Data Platform ouvre l'onglet _Visual Editor_ de `v1`, avec votre application dans la console, connectée en tant qu'administrateur. La barre d'outils en haut n'apparaît que dans le Visual Editor : vos utilisateurs ne la voient jamais. À partir de maintenant, vous construisez tout (pages, graphiques, filtres, menus, formats de nombre) dans l'application elle-même. **Note :** Le bouton **Visual Editor**, comme l'onglet du même nom sur la page de la version, n'apparaît que sur une version en cours d'exécution. L'éditeur est servi par l'application elle-même : une version arrêtée n'a donc rien à ouvrir. ### Créer une page Dans une application, les dashboards sont des pages. Le template Mosaic en inclut une, servie sur `/home` : c'est la page actuellement affichée. Cliquez sur **Dashboards** dans la barre d'outils, puis sur l'onglet _+ New_, et renseignez : - **Name** : `Rides analytics` - **Route** : `/rides-analytics` Laissez la description vide, et laissez **Add a link to it in the "sidebar" menu** coché : vos utilisateurs doivent pouvoir atteindre cette page, et cette option ajoute le lien à la barre latérale pour vous. Cliquez sur **Create**, puis sur **Close**. Cela crée trois éléments à la fois : la page elle-même, son entrée dans la configuration de l'application et le lien dans la barre latérale. Créer la page depuis cette boîte de dialogue garantit la cohérence des trois. Cliquez sur **Rides analytics** dans la barre latérale pour ouvrir votre nouvelle page, encore vide. ### Construire votre premier graphique #### Créer un panel Cliquez sur **+ Add** dans la barre d'outils et sélectionnez **Containers** > **Panel**. Un panel est un conteneur pour les autres composants. Redimensionnez-le en faisant glisser son coin inférieur droit. #### Ajouter le graphique Dans le panel, cliquez sur son bouton **+** et sélectionnez **Charts** > **Semi donut**. Dans l'onglet _General_, nommez le graphique `Rides per temperature`. Ouvrez ensuite l'onglet _Data_, où vous décrivez les données à afficher plutôt que leur représentation graphique. Laissez **Data source** sur _Query builder_, qui construit la requête directement ici, puis : - sous _Measures_, cliquez sur **+ Add** et sélectionnez `rides` avec l'agrégation `sum`. - sous _Group by_, cliquez sur **+ Add** et sélectionnez `cat_temperature`. Cliquez sur **Apply**. Le graphique interroge vos données via l'API déployée dans la partie 1 et affiche une part par catégorie de température : le nombre total de trajets dans chacune. ### Ajouter un graphique à partir d'une requête enregistrée Un total montre comment les trajets se répartissent entre les catégories de température, pas l'effet de la température sur la fréquentation : certaines catégories couvrent simplement plus de jours que d'autres. La requête `rides_per_cat_temperature` que vous avez enregistrée dans l'Analytics Manager répond à cette seconde question, avec le nombre moyen de trajets par jour et par station dans chaque catégorie de température. Un graphique peut la réutiliser telle quelle. Cliquez de nouveau sur le bouton **+** du panel et sélectionnez **Charts** > **Bar** : il s'agit de moyennes, pas des parts d'un tout. Dans l'onglet _General_, nommez le graphique `Average daily rides per station`. Dans l'onglet _Data_, réglez **Data source** sur _Saved query (Analytics Manager)_, puis sélectionnez `rides_per_cat_temperature` dans **Saved query**. Il n'y a rien d'autre à renseigner : les champs, le regroupement et l'ordre d'une requête enregistrée sont définis dans l'Analytics Manager, et c'est là que vous les modifiez. Cliquez sur **Apply**. Le graphique se place sous le premier, là où le panel n'a plus de place pour lui. Placez-le plutôt à côté du semi donut : dans les options du graphique à droite, sous _Layout_, réglez **Column** sur `45` et **Row** sur `0`. Les barres affichent la moyenne de chaque catégorie de température, dans l'ordre de tri de la requête enregistrée. **Note :** L'Analytics Manager est l'endroit où votre équipe conserve les requêtes qu'elle partage. Un graphique construit sur l'une d'elles reste aligné sur elle : modifiez la requête dans l'Analytics Manager, et tous les graphiques qui l'utilisent suivent. ### Ajouter un filtre Un filtre permet à vos utilisateurs d'affiner les graphiques. Cliquez de nouveau sur le bouton **+** du panel et sélectionnez **Filters** > **Select**. Le filtre est ajouté immédiatement et ses options s'ouvrent à droite. Réglez **Field** sur `station_name`, la colonne sur laquelle porte le filtre. Les options de chaque graphique indiquent _All filters on the page_ sous _Filters_ : les deux graphiques réagissent donc à ce filtre sans autre réglage. Une requête enregistrée le reçoit sous forme de paramètre dynamique. Cliquez sur **Save** dans la barre d'outils. Le compteur à côté revient à _no changes_ : votre dashboard est enregistré dans les sources de la version. **Note :** L'enregistrement écrit votre dashboard dans les sources de la version. Il ne le rend pas encore accessible à vos utilisateurs : c'est le rôle du build et du déploiement à la fin de cette page. ### Faire un essai Cliquez sur le bouton **▶** à l'extrémité droite de la barre d'outils pour quitter le mode édition. La barre d'outils se réduit à un seul bouton **Edit**, et vous voyez votre application comme vos utilisateurs la voient. Sélectionnez une station dans le filtre : les deux graphiques se redessinent pour cette station uniquement. Votre dashboard est prêt. ### Déployer une nouvelle version Revenez à la vue d'ensemble de votre application. La carte _Deployed version_ indique que _the configuration has been modified since the last build_ : vos utilisateurs reçoivent toujours la version déployée plus tôt, qui ne contient pas le dashboard que vous venez de construire. La carte propose de reconstruire cette version sur place. Copiez-la plutôt, pour que `v1` reste telle quelle, une version vers laquelle vous pouvez revenir : ouvrez le menu **…** de la carte _Deployed version_ et sélectionnez **Copy**. Dans la boîte de dialogue _Copy Version_, nommez la copie `v2`, cochez **Auto Build** et **Auto Deploy**, puis cliquez sur **CREATE**. **Note :** Le même **déploiement [blue-green](https://en.wikipedia.org/wiki/Blue-green_deployment)** que pour votre API s'applique : `v1` continue de servir vos utilisateurs pendant que `v2` est construite et déployée. La bascule a lieu dès que la nouvelle version est prête, sans interruption. Le build prend quelques minutes. Pour le suivre, ou pour analyser un build en échec, ouvrez l'onglet _Builds_ de la version et cliquez sur l'icône des logs. La boîte de dialogue _Build Logs_ affiche l'état du build, son temps d'attente dans la file et chaque étape au fur et à mesure de son exécution, avec un lien vers le Control Center pour un filtrage avancé. ### Ouvrir votre application en ligne Une fois `v2` construite, la Data Platform bascule sur cette version et arrête `v1`. La bascule peut prendre un moment : tant qu'elle n'est pas terminée, vos utilisateurs reçoivent toujours la version précédente, si bien que personne ne subit d'interruption. Ouvrez votre application avec le bouton **Open app** de sa carte _Deployed version_. Contrairement au Visual Editor, que la console ouvre pour vous, votre application est un site autonome et protégé : elle vous demande donc de vous connecter. Connectez-vous avec **Data Platform**. **Note :** Vous configurez qui peut ouvrir votre application, et comment ces personnes se connectent, dans l'[Identity Access Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-iam.md). Votre application s'ouvre. **Rides analytics**, l'entrée de menu que vous avez ajoutée, figure dans la barre latérale et mène à vos deux graphiques, en direct et filtrables. Votre dashboard est en ligne et lit ses données via votre propre API. Rien ne se rafraîchit à intervalle régulier : chaque graphique interroge l'API à l'ouverture d'une page et à chaque changement de filtre. **Note :** Comme vous avez coché **Enable cache**, l'API répond depuis Valkey à toute requête qu'elle a déjà exécutée et, par défaut, en conserve les résultats jusqu'à ce que le cache soit vidé. Lorsque de nouvelles données arrivent dans vos tables, un graphique peut donc encore afficher les résultats précédents. Un badge _cached_ sur le graphique le signale : un clic sur ce badge exécute de nouveau la requête sans le cache, pour ce graphique et ce lecteur uniquement. Pour que les résultats en cache expirent, définissez la variable d'environnement `DATAQUERY_CACHE_TTL` de votre API sur une durée de vie en secondes. **Vous avez terminé le guide Premiers pas de la Data Platform.** Vous êtes maintenant prêt à explorer la Data Platform par vous-même et à démarrer de nouveaux projets. L'étape suivante approfondit les possibilités du Visual Editor. [Personnaliser davantage votre première application](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/tutorials-customize-first-app.md) ## Aller plus loin Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page [Professional Services](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et faire analyser votre projet par nos experts. Posez vos questions, faites-nous part de vos commentaires et interagissez directement avec l’équipe qui développe la Data Platform sur le [canal Discord](https://discord.gg/ovhcloud) dédié. Si vous avez besoin d'une assistance concernant vos services OVHcloud, créez une demande depuis notre [centre d'aide](https://help.ovhcloud.com/csm?id=csm_get_help). Rejoignez notre [communauté d'utilisateurs](https://community.ovhcloud.com/).