Logo des bases de données gérées OVHcloud

Géré · PostgreSQL + MySQL Maîtrise PostgreSQL / MySQL

Connecter Bases de données gérées par OVHcloud vers Excel, Sheets et l'IA

Bases de données gérées par OVHcloud — PostgreSQL ou MySQL. Aiven s’exécute en arrière-plan, ce qui explique les valeurs par défaut affichées dès que vous les voyez.

1connexion
0ports d'entrée
lecture seuleappliqué

Une seule connexion, chaque surface

Où vos données OVHcloud peuvent-elles être stockées ?

Connectez-vous à OVHcloud une seule fois : cette même connexion en lecture seule alimentera tous ces services, sans configuration supplémentaire ni copie supplémentaire des données. Neuf des onze services proposent un guide pas à pas.

Guide

OVHcloud vers Excel

Microsoft Excel · Complément Excel

Importez directement les résultats OVHcloud en direct dans une feuille de calcul et actualisez-les à la demande — Excel de bureau, Excel Online, Microsoft 365.

Lisez le guide PostgreSQL
Guide

OVHcloud vers Google Sheets

Module complémentaire Sheets

Exécutez une requête OVHcloud enregistrée depuis la barre latérale et glissez-déposez les lignes dans la feuille. Les collaborateurs peuvent ensuite la mettre à jour eux-mêmes.

Lisez le guide PostgreSQL
Guide

Serveur MCP OVHcloud

Claude, clients de Cursor et MCP

Donnez à un assistant IA un accès en lecture seule à OVHcloud avec le schéma dont il a besoin pour écrire du SQL correct — aucune information d'identification dans la conversation.

Lisez le guide PostgreSQL
Guide

API REST OVHcloud

point de terminaison HTTP

Publiez une requête OVHcloud sous forme de point de terminaison JSON authentifié, accessible à toute application, avec une spécification OpenAPI 3.1 et des collections Postman, Insomnia et Hoppscotch prêtes à l'emploi. Aucun port de base de données n'est ouvert.

Lisez le guide PostgreSQL
Guide

OVHcloud vers Airtable

Plateforme d'automatisation

Synchronisez les lignes OVHcloud avec une base Airtable selon une planification, ou récupérez-les dans un script d'automatisation Airtable.

Lisez le guide PostgreSQL
Guide

OVHcloud vers Baserow

Plateforme d'automatisation

Alimentez une table Baserow depuis OVHcloud via le point de terminaison REST — auto-hébergé ou Baserow cloud.

Lisez le guide PostgreSQL
Guide

OVHcloud vers SeaTable

Plateforme d'automatisation

Maintenez une base SeaTable à jour avec les données OVHcloud sans exporter de fichier ni exposer la base de données.

Lisez le guide PostgreSQL
Guide

OVHcloud vers Smartsheet

Plateforme d'automatisation

Intégrez les résultats d'OVHcloud dans une grille Smartsheet afin que les plans et les rapports soient lus à partir du système source et non de l'exportation de la semaine précédente.

Lisez le guide PostgreSQL
Guide

OVHcloud vers Anvil

Anvil Works · Plateforme d'applications

Utilisez OVHcloud pour alimenter une application Anvil Python via le point de terminaison REST au lieu d'intégrer les identifiants de base de données dans l'application.

Lisez le guide PostgreSQL
Prise en charge

OVHcloud vers Power BI

Power Query M

Collez le code Power Query M généré dans l'éditeur avancé de Power BI et le rapport affichera les résultats OVHcloud en direct via HTTPS — sans pilote ODBC ni port de base de données ouvert.

Comment fonctionne Power BI Aucune solution complète pour OVHcloud n'a encore été rédigée.
Prise en charge

Alertes et rapports OVHcloud

Slack · Discord · Courriel · Webhook

Programmez une requête OVHcloud et faites en sorte que les lignes soient envoyées à Slack, Discord, par e-mail ou via un webhook signé, ou conservez le message jusqu'à ce qu'un nombre de lignes, un seuil ou un pourcentage de variation dépasse la limite que vous avez définie.

Fonctionnement des alertes et des rapports Aucune solution complète pour OVHcloud n'a encore été rédigée.

Comment ça marche

5 étapes, aucune modification du pare-feu entrant

01

Installez l'agent réseau sur n'importe quel port accessible par le service. Il n'établit que des connexions sortantes ; aucune règle de pare-feu entrante n'est donc nécessaire.

02

Dans le gestionnaire OVHcloud, ouvrez votre service de base de données et copiez l'URI du service.

03

Collez-le dans le premier champ. L'hôte, le port, la base de données, le nom d'utilisateur et le mot de passe seront lus, et le sélecteur de moteur suivra ce schéma.

04

Vérifiez le port. OVHcloud attribue un port par service au lieu d'utiliser celui par défaut du moteur ; il est donc conseillé de le vérifier même lors du copier-coller.

05

Laissez l'option « Utiliser SSL » activée, testez et enregistrez. Vous pourrez ensuite lire les données depuis Microsoft Excel, Google Sheets, Power BI, MCP ou via une API REST.

Analyse approfondie des fonctionnalités

Ce qu'OVHcloud vous offre

Aiven en dessous, ce qui explique les valeurs par défaut

Si vous avez déjà utilisé Aiven, cette carte vous semblera familière. Sinon, les paramètres par défaut peuvent paraître arbitraires jusqu'à ce qu'on en comprenne la raison.

  • Le nom d'utilisateur par défaut est avnadmin, et non un nom spécifique à OVH. C'est la convention d'Aiven, ce qui se reflète dans… — la carte le préremplit car elle a généralement raison.
  • La base de données par défaut est defaultdb, une autre définition d'Aiven. La chaîne de connexion qu'OVH appelle URI de service est également un terme utilisé par Aiven.
  • Le port est attribué par service et non pas 5432 ou 3306, comme le fait Aiven. Copiez-le depuis le gestionnaire plutôt que de le supposer.
  • La seule fonctionnalité d'Aiven qui fait défaut est le pooler. Aiven expose des pools de connexions PgBouncer sur sa propre plateforme ; OVHcloud ne les rend pas accessibles, il n'y a donc aucun point de terminaison poolé à choisir ni rien à configurer.

Deux régions, deux extensions de nom d'hôte

Un petit détail qui compte lorsqu'il s'agit de vérifier si la carte a reconnu votre hôte.

  • Les services européens se terminent par .database.cloud.ovh.net et les services américains par .database.cloud.ovh.us. La carte reconnaît les deux.
  • La reconnaissance est ce qui motive l'attribution du badge OVHcloud et, sur PostgreSQL, le chiffrement forcé décrit ci-dessous. L'une ou l'autre option vous donne accès aux deux.
  • Un nom d'hôte de la forme postgresql-abc-123.database.cloud.ovh.net est la forme habituelle.
  • Du point de vue de l'agent, rien d'autre ne change entre les deux régions. — la même connexion, le même pilote, les mêmes garanties.

Une carte, deux moteurs, et ils diffèrent par leur cryptage.

Le sélecteur de moteur en haut change plus que le pilote, et c'est la partie qu'il vaut la peine de lire avant de décocher une case.

  • Sélectionnez PostgreSQL et l'agent forcera le chiffrement pour toute extension du nom d'hôte OVHcloud, quelle que soit la valeur de la case à cocher. OVHcloud exige l'option `sslmode=require` et l'agent n'y enverra aucun texte en clair.
  • Sélectionnez MySQL : la case à cocher constitue l’intégralité du mécanisme. Elle est activée par défaut et la connexion est chiffrée tant qu’elle reste activée, mais rien ne la désactive si vous la désactivez.
  • La raison est structurelle et non due à un oubli : l’agent conserve une table des noms d’hôtes PostgreSQL hébergés pour lesquels il impose le protocole TLS, et il n’existe pas d’équivalent pour MySQL. Cette même séparation s’applique à chaque carte multi-moteurs.
  • Les instructions pratiques sont les mêmes dans les deux cas. — Laissez l'option « Utiliser SSL » activée. Sur MySQL, c'est le seul moyen de protéger la connexion.
  • Dans aucun des deux cas, la chaîne de certificats n'est vérifiée. Le chiffrement sert à empêcher toute interception du trafic, et non à prouver quel serveur a répondu.
  • Tout ce que l'agent exécute est en lecture seule, et vos identifiants ne quittent jamais la machine sur laquelle il s'exécute.
-- Lecture seule, quel que soit le moteur que vous avez choisi\nSELECT c.name,\n COUNT(o.id) AS orders,\n SUM(o.amount) AS revenue\nFROM customers AS c\nJOIN orders AS o ON o.customer_id = c.id\nWHERE o.placed_at >= now() - interval '30 days'\nGROUP BY c.name\nORDER BY revenue DESC;

Partagé par tous les connecteurs de base de données

C'est valable pour tous les connecteurs de base de données.

  • Sortant uniquement L'agent ouvre une connexion chiffrée vers Query Streams. Aucun port entrant à rediriger, aucun VPN, aucune liste blanche d'adresses IP : votre base de données n'est en aucun cas exposée sur Internet.
  • Les identifiants restent en place — Le nom d'utilisateur et le mot de passe de la base de données sont stockés sur la machine où l'agent est installé. Query Streams ne les reçoit jamais et ne peut pas accéder à votre base de données par lui-même.
  • Lecture seule, obligatoire — une seule instruction à la fois, SELECT et les instructions associées uniquement. Une tentative d'écriture est bloquée sur votre machine avant même d'être envoyée au serveur, sans dépendre d'une autorisation préalablement définie par un tiers.
  • Déployez autant d'agents que vous le souhaitez — un par site, région ou cloud. Toutes les sources de données visibles apparaissent dans un menu déroulant unique ; il est donc inutile de savoir quel agent héberge quoi.

Voici ce que vous obtenez une fois qu'une requête est enregistrée.

  • Partagez les compétences, pas le SQL. — un collègue ou un partenaire externe peut exécuter votre requête et modifier ses filtres sans jamais voir la requête sous-jacente.
  • Filtres provenant des deux directions — Déclarez-les vous-même comme @variables, ou laissez le connecteur repérer les valeurs littérales déjà présentes dans votre clause WHERE et les proposer sous forme de listes déroulantes.
  • Lisez-le depuis n'importe où — Microsoft Excel, Google Sheets, Power BI, l'API REST, les assistants IA via MCP, le générateur de requêtes et Nova lisent tous la même requête enregistrée.
  • Exécutez-en plusieurs simultanément — cinq requêtes enregistrées dans cinq onglets de feuille de calcul, diffusées simultanément, quelle que soit la taille des résultats.
  • Connectez-le à tout autre élément que vous avez connecté. — une autre base de données, une API métier ou un dossier de fichiers, dans une seule instruction en lecture seule.

SQL inter-sources

Associez OVHcloud au reste de vos données

Une seule requête peut couvrir simultanément OVHcloud et vos autres connexions. Chaque source exécute uniquement la partie qu'elle peut, renvoie le résultat, et la jointure est centralisée : les sources ne communiquent jamais entre elles et aucune donnée n'est copiée.

3 connexions · 3 agents

Bases de données gérées par OVHcloud Géré · PostgreSQL + MySQL
Microsoft SQL Server Moteur relationnel
Rayure Paiements et facturation

Une déclaration

-- rien copié, rien fusionné, rien programmé
SELECTIONNER   c.region, COUNT(*) AS commandes, SUM(i.montant_dû) AS facturé
DE     ovh_db.public.orders1    f
JOINDRE     erp_sql.dbo.clients2   c ON c.id = f.customer_id
JOINDRE     facturation.stripe.factures3 i ON i.customer = c.stripe_id
GROUPE PAR région c.
ORDER BY facturé DESC;

Les trois éléments sont la connexion, le schéma et la table ; le nom de la connexion est celui que vous lui avez donné. Les colonnes sont données à titre d'exemple ; vos tables seront les vôtres. Chaque élément est en lecture seule : seules les instructions SELECT, WITH et EXPLAIN sont autorisées, avec une limite quant aux données qu'une source peut transmettre pour une requête donnée. Fonctionnement des requêtes fédérées

Détails de connexion

Ce dont OVHcloud a besoin

Hôte
postgresql-abc-123.database.cloud.ovh.net en Europe, ou .database.cloud.ovh.us aux États-Unis. La carte reconnaît les deux
Port
Attribué par service et laissé volontairement vide — copiez-le depuis le gestionnaire OVHcloud
Moteurs
PostgreSQL ou MySQL, à choisir en haut de la fiche. Un URI de service collé permet de le configurer.
Conducteur
Npgsql ou MySqlConnector, fournis par l'agent — aucune installation requise côté OVH
Format de collage
L'URI du service fournie par le gestionnaire, sous la forme d'un URI postgres:// ou mysql://
Valeurs par défaut
L'utilisateur avnadmin et la base de données defaultdb, tous deux hérités d'Aiven sous-jacente
TLS
Obligé par l'agent pour les deux extensions de nom d'hôte OVHcloud sur PostgreSQL. Activé par une case à cocher sur MySQL ; laissez-la cochée. La chaîne de certificats n'est vérifiée dans aucun cas.
Mise en commun
Aucun. OVHcloud n'expose pas les pools PgBouncer d'Aiven ; il n'y a donc aucun point de terminaison mutualisé à sélectionner.
Enregistré sous
PostgreSQL ou MySQL, avec OVHcloud conservé comme badge.
Schéma par défaut
public sur PostgreSQL. Une connexion MySQL est qualifiée par sa base de données à la place.

Il est important de connaître la provenance de la carte Aiven, car cela permet d'en prévoir le fonctionnement. Une fois que l'on sait qu'avnadmin et defaultdb sont des conventions Aiven et non des spécificités d'OVH, les valeurs préremplies ne semblent plus être des suppositions et le port par service n'apparaît plus comme un oubli. Cela permet également de définir clairement les attentes : il s'agit du moteur Aiven avec le panneau de contrôle et les régions d'OVH, et non d'une simple réutilisation de toutes les fonctionnalités d'Aiven.

Le pooler en est l'exemple le plus flagrant. Sur Aiven, vous deviez choisir entre une connexion directe et un pool PgBouncer, et ce choix était crucial. Ici, ce choix n'existe pas, ce qui réduit d'autant les risques d'erreur.

Pour une requête inter-sources, le qualificateur suit le moteur de requête plutôt que son identifiant. Une connexion PostgreSQL nommée ovh_db est écrite ovh_db.public.orders ; la même connexion sur MySQL est qualifiée par sa base de données. Elle peut effectuer des jointures avec un dossier de fichiers CSV, un système d'information local ou une API de facturation en une seule instruction en lecture seule.

Documentation du fournisseur : www.ovhcloud.com

FAQ

Questions concernant les bases de données gérées par OVHcloud

Quels outils peuvent lire les données des bases de données gérées par OVHcloud via les flux de requêtes ?

Tous ces outils, depuis une seule connexion : Excel, Google Sheets, MCP, API REST, Airtable, Baserow, SeaTable, Smartsheet, Anvil, Power BI, alertes et rapports programmés. Connectez la base de données une seule fois et tous les systèmes accèdent à la même connexion en lecture seule ; aucune configuration n’est requise pour chaque outil et aucune copie supplémentaire des données n’est nécessaire.

Dois-je ouvrir un port de pare-feu pour ma base de données OVHcloud Managed Databases ?

Non. L'agent réseau Query Streams s'exécute au sein de votre réseau et ouvre une seule connexion sortante chiffrée. Aucun trafic entrant n'est intercepté, aucun VPN n'est requis et la base de données conserve ses règles de pare-feu existantes.

Les flux de requêtes peuvent-ils modifier les données dans les bases de données gérées par OVHcloud ?

Non. L'agent impose un accès en lecture seule lors de l'exécution : une seule instruction à la fois, uniquement SELECT et les instructions associées. Les informations d'identification restent sur l'agent et ne sont jamais envoyées aux flux de requêtes.

De quoi Query Streams a-t-il besoin pour se connecter aux bases de données gérées par OVHcloud ?

Un hôte accessible, un rôle et son mot de passe : l’agent intègre le pilote, aucune installation n’est donc requise sur la base de données. Hôte : postgresql-abc-123.database.cloud.ovh.net en Europe ou .database.cloud.ovh.us aux États-Unis. La carte reconnaît les deux. Port : attribué par service et laissé volontairement vide ; copiez-le depuis le gestionnaire OVHcloud. Moteurs : PostgreSQL ou MySQL, à choisir en haut de la carte. L’URI du service, une fois collée, est automatiquement configurée. Pilote : Npgsql ou MySqlConnector, fourni par l’agent ; aucune installation n’est requise côté OVH.

Puis-je joindre des bases de données gérées par OVHcloud à une autre base de données dans la même requête ?

Oui, il s'agit bien d'une requête fédérée. Une seule instruction peut référencer simultanément les bases de données gérées par OVHcloud et vos autres connexions, sous la forme `connection.schema.table`. Chaque source exécute uniquement la partie qu'elle peut traiter et renvoie le résultat. La jointure est centralisée, ce qui évite toute connexion entre les sources et empêche toute copie ou planification. L'accès en lecture seule s'applique à chaque élément (SELECT, WITH et EXPLAIN uniquement), et la quantité de données qu'une source peut transmettre pour une requête donnée est limitée. Les requêtes fédérées sont incluses dans votre abonnement ; la page dédiée affiche les limites actuelles de sources et de taille.

La connexion aux bases de données gérées par OVHcloud est-elle différente de la connexion à PostgreSQL ?

Seule la chaîne de connexion est nécessaire. Les bases de données gérées par OVHcloud utilisent le protocole PostgreSQL ; par conséquent, les filtres, la planification, le partage, les modules complémentaires Excel et Google Sheets ainsi que le serveur MCP fonctionnent de manière identique. La carte OVHcloud pré-remplit les paramètres d'hôte, de port et SSL attendus par le fournisseur.

Existe-t-il un guide pour convertir OVHcloud en Excel ?

Oui, il s'agit bien du guide PostgreSQL, et il est correct pour les bases de données gérées par OVHcloud. OVHcloud utilise le protocole PostgreSQL ; la connexion d'OVHcloud à Excel, à Google Sheets et à toute autre destination suit donc les mêmes étapes. Seule la chaîne de connexion est spécifique à OVHcloud, et la carte OVHcloud la renseigne automatiquement.

Installez OVHcloud là où le travail se déroule.

Installez l'agent, configurez-le pour qu'il pointe vers votre base de données et choisissez une destination.

Lecture seule Sortant uniquement Les identifiants restent sur l'agent