---
title: "Créer et construire vos modèles de données - Datasets externes"
description: "Ce tutoriel vous aidera à utiliser le Lakehouse Manager pour la deuxième étape et le data processing engine pour la troisième étape du démarrage"
url: https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/tutorials-external-datasets
lang: fr
lastUpdated: 2026-09-14
---
> 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.

# Créer et construire vos modèles de données - Datasets externes

## Objectif

Ce tutoriel vous aidera à utiliser le **Lakehouse Manager** pour la deuxième étape et le **data processing engine** pour la troisième étape du _tutoriel de démarrage_ avec les _Datasets externes_.

## Organiser vos données en tables

### Créer votre schéma principal

#### Ajouter des tables au modèle de données

:::warning
Vous devez vous assurer d'avoir créé un dataset externe avant de continuer. Les étapes pour créer un dataset externe se trouvent [ici](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-datasets.md).
:::

Une fois vos métadonnées extraites, il est temps de vous rendre sur le dashboard Tables. C'est ici que vous allez **construire une vue unifiée et interrogeable de toutes vos données**.

La page Tables vide devrait ressembler à ceci.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step1.png)
L'onglet _All tables_ est celui où vous avez accès à l'intégralité de vos données. L'onglet _New View_ vous permet de créer des vues portant sur une partie seulement de vos données afin de mieux collaborer au sein de grandes équipes. Puisqu'il s'agit ici d'un tutoriel simple, vous devriez travailler dans l'onglet _All tables_.

Concentrons-nous maintenant sur la création de vos tables principales et de leurs attributs.

Tout d'abord, survolez avec votre curseur l'icône bleue ➕ sur le côté gauche de l'écran. Cela affichera les options de création :

- Upload a file
- Create from Connectors source
- Create an empty tables

:::info
Pour les besoins de ce tutoriel, nous allons poursuivre avec **Create from a Connectors source.**
:::

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step2.png)
Une fois que vous cliquez sur _create from a connectors source_, une liste des sources de l'étape précédente s'affiche. Cliquez sur la source que vous voulez ajouter et poursuivez en cliquant sur _Next_. Ici, nous pouvons choisir l'un des datasets externes que vous avez créés. Il n'est pas nécessaire de modifier les autres paramètres par défaut.

:::info
Les options _Build the table, load the table once, and generate Load action for later_ peuvent être désactivées et chaque étape peut également être réalisée individuellement. Cela peut être exploré en détail dans le guide [Tables](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md)
:::

Appuyez sur **Create** et procédez de la même manière pour la seconde table.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step3.png)
![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step4.png)
:::info
Notez qu'à chaque changement effectué sur la page Tables, votre configuration visuelle est **automatiquement sauvegardée**.
:::

À ce stade, votre page Tables devrait ressembler à ceci.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step5.png)
Vous remarquerez peut-être que certains attributs de vos tables sont écrits **en gras**. La platform a automatiquement détecté qu'il s'agissait de **clés primaires**, c'est-à-dire l'attribut (ou l'ensemble d'attributs) utilisé pour identifier de manière unique chaque ligne de données dans la table.

:::info
Vous pouvez modifier manuellement les clés primaires de n'importe quelle table en survolant l'attribut avec votre curseur et en cliquant sur l'icône **étoile** ⭐.
:::

:::warning
Vous remarquerez peut-être qu'en utilisant les _Datasets externes_, certains attributs de vos tables sont écrits **en gras**. La Platform a automatiquement détecté qu'il s'agissait de **clés primaires**, c'est-à-dire l'attribut (ou l'ensemble d'attributs) utilisé pour identifier de manière unique chaque ligne de données dans la table. **Le Lakehouse Manager Engine** est davantage un moteur big data, et par défaut, le concept de clés primaires n'existe pas. Vous ne verrez donc aucun attribut **en gras**.
:::

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step6.png)
:::info
Notez que la Platform utilise les informations de métadonnées capturées lors de l'étape Analyzer pour créer automatiquement les tables et attribuer les noms et types d'attributs. Les fichiers sources fournis sont prêts à l'emploi ; toutefois, dans un Projet réel, vous devriez utiliser l'Analyzer pour vérifier les sources de données avant de les glisser-déposer dans la page Tables.
:::

#### Joindre des tables entre elles

Vous devez indiquer au Lakehouse Manager comment vos tables sont liées entre elles.

Vous allez joindre des tables qui sont liées entre elles selon une relation parent/enfant. Un **parent** est une table qui contient des informations détaillées sur un sujet particulier : par exemple, la météo à Chicago à une date donnée. Une table **enfant** référence plusieurs tables parentes. Une autre manière de voir les choses est qu'une table enfant hérite des valeurs de la table parente (tout comme les enfants dans la vraie vie, sauf qu'un enfant peut avoir plus de deux parents !)

La table _stations\_rides_ est une table enfant. Elle contient des informations de fréquentation par date et par station de train. Mais elle ne dispose pas d'informations détaillées sur les jours. Vos deux tables ont _date_ comme clé primaire. Ainsi, si vous liez la table parente _chicago\_calendar\_full_ à la table enfant _stations\_rides_, vous aurez automatiquement ajouté des informations météorologiques à votre fréquentation, pour chaque jour de l'année.

Tout d'abord, cliquez une fois sur la table parente _chicago\_calendar\_full_ pour la sélectionner, puis cliquez sur le cercle blanc en bas de la table :

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step7.png)
Faites simplement glisser la flèche vers la table enfant _stations\_rides_ et relâchez. Votre écran devrait ressembler à ceci :

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step8.png)
### Créer votre table d'agrégation

Vous allez maintenant agréger toutes les données importantes des sources (à savoir les trajets, les dates et les températures) dans une seule table qui sera utilisée dans l'application finale. Les tables d'agrégation consolident les données provenant de plusieurs tables sources.

Pour créer votre première table d'agrégation, cliquez sur l'icône bleue ➕. Sélectionnez _Create an empty table_, une configuration de nouvelle table s'affiche alors dans laquelle vous définissez un nom (_dataset\_history_ par exemple) puis l'enregistrez.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step9.png)
Ensuite, glissez-déposez _date_ et _station\_id_ depuis la table source _stations\_rides_ vers la table _dataset\_history_ et définissez ces attributs comme clés primaires.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step10.png)
Déplacez les attributs ci-dessous vers _dataset\_history_ et ne les définissez pas comme clés (puisqu'il s'agit de données simples de chaque ligne, non uniques) :

|        Original table       | Attributes to drag-and-drop                                              |
| :-------------------------: | ------------------------------------------------------------------------ |
|     **stations\_rides**     | _lat_ / _lng_  / _rides_ / _station\_name_                               |
| **chicago\_calendar\_full** | _month_ / _temperature_ / _week\_day_ / _week\_day\_label_ / _weekend_ / |

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step11.png)
Enfin, vous devrez créer un nouvel attribut pour aider à traduire les données de température numériques en catégories compréhensibles (froid, chaud, ...).

Commencez par cliquer sur l'icône ➕ qui apparaît en haut de la table _dataset\_history_ lorsque vous cliquez dessus. Vous pouvez alors créer ou modifier un attribut au sein d'une table.

Définissez l'attribut comme suit :

|    Attribute name    | Type   | Nature    |
| :------------------: | ------ | --------- |
| **cat\_temperature** | String | Dimension |

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step12.png)
:::info
Pour le moment, cet attribut n'est pas physiquement spécifié. Cela sera fait plus loin dans un autre composant : le Data Processing Engine.
:::

[<span aria-hidden="true">↪</span> En savoir plus sur les Tables](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/lakehouse-manager-tables.md)

### Finaliser le build

:::warning
Une dernière petite vérification ! Assurez-vous de **vérifier deux fois que votre modèle de données ressemble exactement à celui des captures d'écran** avant de passer à l'étape suivante. Si certains attributs sont manquants, vous risquez de rester bloqué dans les étapes ultérieures du tutoriel.
:::

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step13.png)
Maintenant, cliquez sur l'icône _Build_ (sous l'icône bleue ➕) pour effectivement créer/mettre à jour les tables et attributs dans votre dataset. Cela ne charge pas encore les données dans les tables (ce qui sera fait dans le prochain article) ; cela applique simplement le schéma logique aux tables et attributs de votre dataset sous-jacent.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/lakehouse-step14.png)
:::info
Alors que le schéma logique visuel des données est automatiquement sauvegardé, les changements apportés à vos tables ne seront pas visibles dans le reste de la Platform tant qu'elles ne sont pas buildées.
:::

La tâche de build pour ce tutoriel ne devrait pas prendre plus de quelques minutes à s'exécuter. Une fois terminée, vous pouvez continuer.

### Ajouter des métriques pertinentes avec les Virtual Attributes

Avant de passer au traitement physique (ETL/ELT) des données dans ce modèle, préparons des métriques supplémentaires pour l'analytique ultérieure. L'application finale que vous construisez en suivant ce tutoriel inclut un graphique avec le **nombre de trajets par jour pour une station donnée** :

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/dashboard-final-new.png)
Cependant, vous ne disposez pas des données nécessaires pour construire ce graphique directement sur les sources principales. Vous aurez besoin d'une métrique qui vous donne le nombre moyen de trajets par jour pour une station donnée et qui puisse être utilisée dans des requêtes et des dashboards.

Mais comment calculer cela avec la platform ? Une manière de le faire est de créer un **attribut virtuel**. Les virtual attributes vous permettent de calculer des formules SQL qui seront **calculées à la volée** et ne seront pas stockées dans la base de données. Elles peuvent être utilisées dans une requête ou un graphique de votre dashboard final.

:::info
Ajouter ou modifier des virtual attributes ne nécessite pas de reconstruire le schéma.
:::

Basculez vers la page **Attributes**. Cette page liste tous les attributs physiques et virtuels de votre modèle de données, ainsi que le lineage de votre Projet.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/attributes-step1.png)
Cliquez sur le bouton _New Attribute_ pour créer un virtual attribute.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/attributes-step2.png)
Dans la fenêtre de création, assurez-vous de sélectionner _Virtual_ comme realm.

![Lakehouse Manager](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/attributes-step3.png)
Ajoutez maintenant ces deux attributs et leur code SQL respectif :

|             Attribute name             | SQL                                                                                    |
| :------------------------------------: | -------------------------------------------------------------------------------------- |
| **avg\_rides\_per\_day\_per\_station** | SUM(rides)/COUNT(DISTINCT CONCAT(CAST(date AS VARCHAR), CAST(station\_id AS VARCHAR))) |
|              **yearmonth**             | SUBSTR(CAST(date as VARCHAR),1,7)                                                      |

L'attribut **yearmonth** vous donne l'année et le mois au format _yyyy-mm_. Vous l'utiliserez plus tard.

:::info
Remarquez que vous venez d'utiliser deux méthodes différentes pour générer de nouveaux attributs/métriques à partir des données importées : **ajouter un attribut physique à une table** et les **virtual attributes**.
:::

- Ajouter un nouvel attribut physique occupe de l'espace de stockage et nécessite de le définir physiquement dans le Data Processing Engine, mais cela les rend plus rigoureux car leurs spécifications peuvent ensuite être modifiées sans changer l'ensemble du modèle de données.
- Les virtual attributes constituent une solution rapide mais peuvent devenir difficiles à gérer si vous devez les modifier à mesure que vous montez en charge.

## Actions

Une [action](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe-actions.md) consiste en une opération physique unitaire sur les données. Les Actions peuvent être organisées en stages afin de produire des pipelines de traitement de données automatisés appelés [workflows](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-workflows.md).

Cliquez sur le menu **Actions** de votre Data Processing Engine. Vous devriez voir les deux actions _Load_ qui ont été [automatiquement générées à l'étape précédente](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-organize-data.md#organiser-vos-donn%C3%A9es-en-tables) :

![DPE Actions](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/actions-step1.png)
Ces actions Load vont physiquement extraire les données de vos sources et les charger dans votre data warehouse, en suivant le schéma défini dans le Lakehouse Manager.

### Créer plus d'actions

:::info
Notre Marketplace vous donne accès à une dizaine d'actions organisées pour démarrer rapidement vos Projets de traitement de données : des actions _load_, des actions _aggregate_, des actions _delete_, etc. Si vous ne trouvez pas ce dont vous avez besoin dans le catalogue, vous pouvez toujours recourir à une action _custom_ qui vous permet d'**exécuter n'importe quel morceau de code Python 3+** dans le cadre de vos pipelines de données.
:::

[<span aria-hidden="true">↪</span> En savoir plus sur les actions personnalisées](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-custom.md).

Pour ce tutoriel, vous allez créer une action utilisée pour agréger vos données dans la table _dataset\_history_ que vous avez créée dans la partie précédente.

Cliquez sur **New action** et sélectionnez le modèle _Aggregate action_ depuis le Platform Store.

![DPE agg action 1](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/actions-step2.png)
Il y aura 2 étapes simples pour configurer l'action Aggregate :

- **(1)** Sélectionner une table source : _stations\_rides_
- **(2)** Sélectionner la table de destination : _dataset\_history_

Après quelques secondes, le Data Processing Engine trouvera automatiquement toutes les conditions de jointure requises, et mappera les attributs.

Changez la condition de jointure en un _INNER join_ à l'aide du menu déroulant. Cela garantira que vous n'aurez aucun champ nul dans les enregistrements de votre table dataset\_history.

![DPE agg action 2](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/actions-step3.png)
Les attributs ont été mappés automatiquement. Trouvez l'attribut _rides_, qui est la métrique que vous cherchez à agréger, et basculez-le vers une fonction **SUM**. Partout ailleurs, laissez la fonction **MAX** telle quelle : la plupart des SGBD exigent d'appliquer une clause d'agrégation aux attributs qui ne font pas partie de la clause _GROUP BY_.

![DPE agg action 4](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/actions-step4.png)
Enfin, définissons l'attribut catégoriel _cat\_temperature_ que vous avez créé précédemment. Cliquez sur l'option **\< map >** (abréviation de « mapping ») dans le menu déroulant bleu comme indiqué ci-dessous, et basculez-la vers **\< sql >**.

![DPE agg action 3](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/actions-step5.png)
Copiez-collez simplement la commande SQL ci-dessous :

```
CASE 
WHEN MAX(chicago_calendar_full.temperature)<40 THEN 'very cold'
WHEN MAX(chicago_calendar_full.temperature)<48 THEN 'cold'
WHEN MAX(chicago_calendar_full.temperature)<55 THEN 'medium'
WHEN MAX(chicago_calendar_full.temperature)<62 THEN 'hot'
ELSE 'very hot'
END
```

:::warning
**Laisser un attribut de destination non mappé dans la configuration de l'action Aggregate déclenchera une erreur au lancement de l'action**. Si vous préférez laisser le champ de destination vide, veillez simplement à le retirer de la liste des attributs mappés.
:::

[<span aria-hidden="true">↪</span> En savoir plus sur les actions Aggregate](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-aggregate.md)

Cliquez sur **Create** en haut à droite.

![DPE agg action 3](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/actions-step6.png)
**Vous avez maintenant généré toutes les actions** requises pour ce tutoriel.

:::info
Bien sûr, votre Projet réel comportera probablement plus de 3 actions. Vous pouvez organiser vos actions en dossiers et les renommer si besoin. Vous pouvez également utiliser plus d'un repository, en particulier si vous travaillez en collaboration avec des coéquipiers. Les repositories d'actions peuvent être versionnés et également synchronisés avec des repositories Git externes. Consultez la page de [documentation produit dédiée](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-actions-manage.md#g%C3%A9rer-les-actions) pour en savoir plus sur la façon de procéder !
:::

[<span aria-hidden="true">↪</span> En savoir plus sur les Actions dans la documentation produit](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-dpe-actions.md)

## Workflows

Un workflow définit l'ordre d'exécution de vos actions.

Au sein d'un workflow, les actions sont organisées en stages séquentiels. Au sein d'un stage, toutes les actions seront exécutées en parallèle, tandis que les stages s'exécuteront toujours les uns après les autres. La même action peut être utilisée plusieurs fois dans le même workflow. Un workflow, tout comme une action, peut être lancé manuellement, configuré pour s'exécuter selon une planification, ou déclenché via un appel API.

:::info
Notez qu'il est important de retenir que les **stages s'exécutent les uns après les autres** dans l'ordre où vous les avez planifiés, tandis que les **actions contenues dans un stage s'exécutent toutes en même temps**, quel que soit leur ordre. En résumé, l'ordre des actions au sein d'un stage n'a pas d'importance, contrairement à l'ordre des stages au sein d'un workflow.
:::

Pour créer votre premier workflow, vous devrez vous rendre dans l'onglet _Workflow_ et cliquer sur **New Workflow**. Rendez-vous dans les préférences ou double-cliquez sur le nom d'en-tête pour définir un nouveau nom _Import Chicago Data_.

![DPE workflow 1](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step1.png)
Commençons par définir deux stages différents en cliquant sur **Add a stage**. Ensuite, ajoutez des actions dans chaque stage à l'aide du sélecteur de recherche déroulant, en suivant la capture d'écran fournie comme guide pour chaque stage.

![DPE workflow 2](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step2.png)
Après avoir créé le workflow (**create**), appuyez sur **Play**.

:::info
Veuillez noter que les workflows peuvent prendre quelques minutes à s'exécuter lorsque vous les lancez pour la première fois. Le temps total ne devrait pas dépasser 10 minutes - si c'est le cas, veuillez contacter notre équipe support.
:::

Pendant que le workflow s'exécute, vous pouvez en profiter pour **le planifier pour qu'il s'exécute quotidiennement** à l'aide d'un trigger.

Rendez-vous dans l'onglet _Preferences_ de vos workflows et faites défiler jusqu'au widget Triggers en bas à gauche. Cliquez sur **+Add**.

![DPE workflow 4](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step3.png)
Sélectionnez le type de trigger _CRON_ et le mode _Simple_. Naviguez vers l'onglet **Daily** et, dans la liste des options, sélectionnez _Every 1 day(s)_ comme indiqué dans l'image ci-dessous :

![DPE workflow 4](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step4.png)
Appuyez sur le bouton **Confirm** pour créer le nouvel événement de trigger avec le nom de votre choix, et il sera ajouté sous le _Launch Endpoint_ présent par défaut dans le tableau des Trigger event.

![DPE workflow 5](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step5.png)
:::info
Il y a bien plus que vous pouvez configurer dans les préférences d'un workflow. Notamment, vous pouvez [monter en charge horizontalement et verticalement](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-jobs-resources.md) n'importe quel job de traitement, utiliser la [segmentation de charge de travail](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/tutorials-segmentation.md) pour accélérer le traitement des données, et même sauvegarder toutes ces configurations pour une utilisation répétée grâce aux [environnements](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-environments.md).
:::

[<span aria-hidden="true">↪</span> En savoir plus sur la configuration des préférences d'exécution.](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/dpe-jobs-preferences.md)

:::warning
Assurez-vous de cliquer sur le bouton **Save** en haut à droite de l'écran chaque fois que vous apportez une modification à vos workflows. Les actions sont stockées dans des repositories qui peuvent être versionnés, ce qui n'est pas le cas pour les workflows ou les environnements. _Autosave_ est donc désactivé pour les workflows comme pour les environnements.
:::

## Jobs

Pour conclure cette section, voici quelques mots sur le dernier onglet du composant Data Processing Engine : les jobs.

L'onglet Jobs résume **toutes les exécutions déclenchées dans le Data Processing Engine** et inclut des rapports de métriques avancés. Les jobs sont listés sous trois catégories principales : running, queued et past executions. En consultant les derniers jobs exécutés, vous pouvez vérifier le statut du workflow que vous venez de lancer.

![DPE Jobs](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step6.png)
Vous avez maintenant terminé la section Data Engineering du tutoriel _Premiers pas_.

Une bonne manière de vous assurer que vos données ont été correctement chargées est de retourner dans le [Lakehouse Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/landing-page-lakehouse-manager.md) et de regarder le nombre de lignes chargées dans la table. Ouvrez simplement le **mode d'affichage liste** et vérifiez la colonne _rows_ ; si le champ affiche un nombre (indiquant combien de lignes ont été chargées), alors tout s'est bien passé.

![lignes chargées](/images/public-cloud/data-platform/getting-further/data-models-with-external/picts/workflows-step7.png)
Si vous souhaitez poursuivre le tutoriel de démarrage, vous pouvez passer directement à l'[étape 4 : l'Analytics Manager](https://docs.ovhcloud.com/fr/guides/public-cloud/data-platform/getting-started-create-queries.md)

## Aller plus loin

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](https://www.ovhcloud.com/fr/professional-services/) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

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/).
