Cloud Souverain & Hybride : Interconnecter un serveur local Proxmox VE avec une infrastructure cloud (Scaleway ou OVHcloud)

Pourquoi connecter Proxmox VE à un cloud souverain (Scaleway/OVHcloud) en 2026

En 2026, l’idée d’un cloud hybride n’est plus un truc de grosses DSI qui aiment les acronymes. C’est devenu une manière assez pragmatique de garder la main sur son infra locale, tout en se donnant une soupape côté cloud quand ça chauffe. Vous gardez Proxmox VE on prem pour ce qui doit rester proche, stable, contrôlé. Et vous utilisez Scaleway ou OVHcloud pour l’élasticité, la redondance géographique, la sauvegarde hors site. Sans devoir tout migrer, sans tout casser.

Le terme « cloud souverain » est parfois un peu marketing, donc clarifions vite fait ce qu’on vise ici. En pratique, on parle de choses concrètes : localisation des données (France, UE), conformité et responsabilités RGPD, conditions contractuelles plus lisibles, et surtout réversibilité. Le jour où vous voulez partir, vous devez pouvoir récupérer vos données et reconstruire ailleurs sans être otage d’un service opaque.

Et côté cas d’usage, on retrouve presque toujours les mêmes patterns qui marchent vraiment :

• PRA/PCA : un plan de reprise (et un plan de continuité) qui n’est pas juste un PDF.
• Burst de charge : vous gardez le socle local, vous « débordez » temporairement dans le cloud.
• Sauvegardes immuables : une copie hors site, chiffrée, avec rétention, difficile à ransomware.
• Environnements de test : des VM jetables, isolées, pas sur le LAN de prod.
• Services exposés : reverse proxy, WAF, bastion, et vous évitez d’ouvrir votre réseau local au monde.

Dans cet article, on va couvrir le réseau (interconnexion), la sécurité (pare-feu, exposition minimale), quelques patterns d’architecture simples, une méthode WireGuard étape par étape, et les pièges classiques. Le but n’est pas de faire « une interconnexion magique ». Juste une liaison propre, mesurable, documentée.

Pré-requis : ce qu’il vous faut avant de commencer

Avant même de parler VPN, il faut être carré sur la base. Sinon vous allez passer une journée à « debugger WireGuard » alors que le problème est un routeur qui NAT un truc bizarre.

Côté local (sur site)

• Un serveur Proxmox VE fonctionnel (idéalement à jour).
• Accès root et SSH.
• Un réseau stable, et une idée claire de vos sous-réseaux.
• Une sortie internet correcte. IP publique fixe c’est mieux, mais pas obligatoire.
• Un routeur ou une box où vous pouvez ouvrir un port UDP, ou au moins gérer des routes.

Côté cloud (Scaleway ou OVHcloud)

• Un compte actif, facturation OK.
• Un VPC ou réseau privé, avec au moins un sous-réseau.
• Une VM qui servira de gateway VPN (Ubuntu ou Debian, simple).
• Des règles de sécurité côté cloud (security groups, firewall, ACL selon le fournisseur).
• Optionnel mais souvent utile : une IP publique stable (floating IP si dispo) pour la gateway.

Compétences minimales

Vous n’avez pas besoin d’être expert BGP. Mais il faut être à l’aise avec : IP et subnets, routage, DNS, certificats TLS, SSH, pare-feu Linux (nftables/iptables/ufw), et les effets secondaires classiques (MTU, asymétrie de route, NAT).

Décider maintenant : l’objectif et les contraintes

Posez ça clairement, sinon l’archi part dans tous les sens.

• Objectif principal : accès admin aux VM, réplication/sauvegarde, exposition de services, ou burst de charge ?
• Contraintes : latence acceptable, débit, coût réseau (egress), maintenance, exigence de haute dispo.

Choisir son modèle d’interconnexion : 3 approches (et quand les utiliser)

Approche 1 : VPN site-à-site (recommandée)

C’est le choix le plus simple et le plus robuste pour démarrer. Deux sites, deux réseaux privés, un tunnel chiffré. Et ensuite on route proprement.

• WireGuard : léger, moderne, facile à auditer, très bon pour un setup « gateway à gateway ».
• IPsec : très standard, parfois mieux intégré dans certains firewalls, mais souvent plus pénible à configurer.

Avantages : clair, stable, gouvernance simple, pas besoin d’un tiers.

Limites : débit dépend de la CPU et du chiffrement, attention à la MTU, et la gestion des routes doit être propre.

Approche 2 : réseau overlay (Tailscale, ZeroTier)

Très pratique quand vous n’avez pas d’IP publique, ou quand vous voulez un déploiement rapide. Ça marche bien pour de l’admin, du support, des petits réseaux, des accès nomades.

Mais il y a un point important : gouvernance et contrôle. Vous déléguez une partie de la logique réseau à une couche overlay et à une identité. Ce n’est pas mauvais en soi. Juste, il faut l’assumer, documenter, et gérer les droits.

Approche 3 : lien dédié, peering (selon offre)

Quand le débit et la latence deviennent vraiment critiques, ou quand vous voulez une interconnexion plus « entreprise ». Selon Scaleway, OVHcloud, et votre contexte (datacenter, opérateur), ça peut exister, mais ce n’est pas toujours accessible, ni rentable pour un petit setup.

Règle pratique : commencez en VPN, souvent WireGuard. Et quand vous avez prouvé le besoin, vous upgradez.

Architecture cible : un schéma simple qui marche (local + cloud)

Le piège classique, c’est de faire une interco sans segmentation, puis de se retrouver avec un « grand LAN étendu » ingérable. Gardons un truc propre.

Segmentation côté local

Idéalement :

• Réseau Proxmox management (GUI, SSH, API).
• Réseau VM/CT (trafic applicatif).
• Réseau stockage (optionnel, si vous avez Ceph/NFS/iSCSI).

Même si tout est sur un seul switch au début, vous voulez au moins des VLAN logiques, ou un plan clair.

Dans le cloud

Un VPC avec :

• Un sous-réseau privé pour vos instances.
• Une VM « gateway » avec deux rôles : terminaison VPN + routage.
• Des VM de services : backup, reverse proxy, apps, bastion.

Plages IP sans chevauchement

C’est non négociable. Exemple simple :

• Local : 10.10.0.0/16
• Cloud : 10.20.0.0/16
• Tunnel WireGuard : 10.99.0.0/24

Routage

Décidez qui annonce quoi.

• La gateway cloud sait joindre 10.10.0.0/16 via le tunnel.
• Le routeur local (ou la gateway on prem) sait joindre 10.20.0.0/16 via le tunnel.

Évitez le hairpin inutile. Si un poste local veut joindre une VM cloud, il ne doit pas sortir vers internet puis revenir. Il doit router dans le tunnel, point.

DNS

Sans DNS, vous finissez à taper des IP partout. Deux options qui marchent :

• Split horizon : un même nom, résolution différente selon l’endroit.
• DNS interne : un DNS local + un DNS cloud, et vous forwardez proprement.

pbs.cloud.intraapp.test.intra

Étape par étape : interconnecter Proxmox VE et le cloud avec WireGuard (méthode pratique)

On va partir sur un setup classique : une VM gateway dans le cloud, et une terminaison côté local (routeur, VM dédiée, ou Proxmox). L'idée est la même.

1) Plan d'adressage et interfaces

Écrivez ça dans un doc. Vraiment. Parce que dans 6 mois vous ne vous souviendrez plus.

• 10.99.0.0/24
• 10.99.0.1
• 10.99.0.2
• 10.10.0.0/16
• 10.20.0.0/16

2) Déployer la VM gateway dans Scaleway/OVHcloud

Prenez Ubuntu LTS ou Debian stable. Une petite VM suffit au début.

• Activez une IP publique.
• Ouvrez un port UDP (exemple : 51820) dans le firewall cloud, de préférence uniquement depuis l'IP publique de votre site on prem. Sinon, ouvrez-le temporairement puis restreignez l'accès ensuite.

Installez WireGuard :

bash apt update apt install -y wireguard umask 077 wg genkey | tee /etc/wireguard/wg0.key | wg pubkey > /etc/wireguard/wg0.pub

3) Configurer WireGuard côté cloud

/etc/wireguard/wg0.conf

ini [Interface] Address = 10.99.0.1/24 ListenPort = 51820 PrivateKey = <contenu de /etc/wireguard/wg0.key>

[Peer] PublicKey = <clé_publique_du_site_local> AllowedIPs = 10.99.0.2/32, 10.10.0.0/16 PersistentKeepalive = 25

Démarrez :

bash systemctl enable --now wg-quick@wg0 wg show

4) Configurer WireGuard côté local

Même principe. Sur votre machine qui termine le VPN (on y revient juste après), installez WireGuard, générez les clés, puis :

ini [Interface] Address = 10.99.0.2/24 PrivateKey = <clé_privée_locale>

[Peer] PublicKey = <clé_publique_cloud> Endpoint = <ip_publique_cloud>:51820 AllowedIPs = 10.99.0.1/32, 10.20.0.0/16 PersistentKeepalive = 25

Là, vous avez un tunnel. Mais pas encore de routage complet.

5) Activer le forwarding IP et configurer le routage

Sur la gateway cloud :

bash sysctl -w net.ipv4.ip_forward=1

Et rendez-le persistent :

bash echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-forward.conf sysctl --system

10.10.0.0/16

10.20.0.0/16

6) Vérifier MTU et fragmentation

Symptôme classique : le ping marche, SSH marche, mais HTTP plante, ou SMB est instable. Souvent c’est MTU.

Test rapide :

bash ping -M do -s 1420 10.99.0.1

wg0.conf

ini [Interface] MTU = 1420

Appliquez, puis retestez.

7) Tests de bout en bout

Faites des tests bêtes, mais dans le bon ordre.

• ping
• ping
• traceroute
• Accès applicatif réel : HTTP, DNS, sauvegarde, etc.

Et surtout : test bidirectionnel. Local vers cloud, et cloud vers local.

Option : où terminer le VPN (sur Proxmox, sur un routeur, ou sur une VM dédiée)

• Sur Proxmox : rapide, mais ça augmente la surface d’attaque, et un reboot Proxmox coupe le lien.
• Sur un routeur/pare-feu (pfSense/OPNsense) : souvent le plus propre. Centralisation des routes, règles, logs.
• Sur une VM dédiée on prem : bon compromis, isolé, mais dépend du cluster et du stockage.

Choisissez selon votre maturité sécu, vos besoins HA, et votre tolérance à la coupure pendant maintenance.

Sécuriser WireGuard proprement (sans se tirer une balle dans le pied)

Quelques règles simples qui évitent 80 % des catastrophes :

• AllowedIPs0.0.0.0/0
• Firewall : n’autorisez UDP 51820 que depuis l’IP attendue si possible.
• Gestion des clés : stockage hors repo Git, rotation périodique, séparation des accès (admin vs services).
• Supervision : trafic, handshakes, débit. Node exporter et quelques alertes Prometheus peuvent suffire.

Réseau & sécurité : règles firewall, NAT, et exposition minimale

Décidez votre modèle. Deux grandes approches :

• Full mesh : tout le monde parle à tout le monde. Simple au début, dangereux si vous laissez traîner.
• Hub and spoke : tout passe par une gateway, vous filtrez. Souvent plus propre.

NAT : quand l’éviter, quand l’utiliser

Si vous pouvez, évitez le NAT. Le routage pur est plus lisible, plus debuggable, et meilleur pour des services internes.

Mais parfois vous n’avez pas le choix : limitations VPC, chevauchement partiel, ou besoin de masquer un réseau. Dans ce cas, faites-le explicitement, documentez-le, et limitez-le à un usage précis.

Filtrage inter-réseaux

Appliquez une politique « deny by default ». Puis ouvrez :

• Admin : SSH, Proxmox GUI, API, seulement depuis votre bastion ou votre réseau admin.
• Services : ports applicatifs stricts.
• Backup : uniquement ce qui est nécessaire (PBS, S3, rsync, etc).

Bastion, accès SSH, et hygiène de base

• Un jump host dans le cloud (ou sur la gateway si vous faites simple), accessible en SSH.
• MFA côté console cloud.
• Clé SSH uniquement, mot de passe désactivé.
• Fail2ban si exposition publique, et logs centralisés.

TLS et reverse proxy

Dès que vous exposez un service, mettez TLS. Let’s Encrypt si possible. Sinon AC interne.

Reverse proxy type Traefik ou Nginx, avec des règles claires. Et idéalement un WAF si vous exposez du web. Mais là, attention au scope, on peut vite complexifier.

Stockage, sauvegardes et PRA : le vrai gain du hybride

C’est souvent là que le cloud hybride devient vraiment rentable. Pas « cool ». Rentable. Parce qu’un PRA sans copie hors site, c’est du théâtre.

Sauvegardes Proxmox vers le cloud

Options classiques :

• vzdump
• Stockage objet S3 compatible (Scaleway Object Storage, OVHcloud Object Storage).
• Proxmox Backup Server (PBS), et c’est souvent le meilleur choix.

Proxmox backup server (PBS)

PBS apporte : déduplication, compression, chiffrement, rétention, et restauration granulaire. Et surtout, vous pouvez faire de la réplication.

Deux modèles simples :

• PBS principal on prem (proche des hôtes Proxmox), réplication vers un PBS dans le cloud.
• PBS on prem, copie chiffrée vers un bucket objet (selon vos outils et votre confort).

Chiffrez. Gérez les clés proprement. Et testez les restaurations. Sans tests, vous ne savez rien.

Rétention simple, efficace

Un exemple qui marche souvent :

• Quotidien : 7 à 14 jours
• Hebdo : 4 à 8 semaines
• Mensuel : 6 à 12 mois

Et une règle interne : une restauration test par mois minimum, même petite.

Pattern concret : « sauvegarde locale + copie chiffrée dans le cloud »

Le pattern le plus réaliste pour beaucoup :

• Local : PBS principal, performant, rapide à restaurer.
• Cloud : réplication planifiée la nuit vers un PBS secondaire, ou export chiffré vers objet.
• Chiffrement : côté PBS si possible, sinon chiffrement applicatif (restic, rclone avec crypt, etc).
• Rétention : appliquée au bon endroit, et documentée.

Ce pattern vous donne : vitesse locale + résilience hors site. Sans dépendre d’un seul point.

Workloads : quelles VM/CT déplacer (et lesquelles garder on prem)

Tout n’a pas vocation à bouger. Et si vous migrez « par principe », vous allez vous punir sur la latence, les coûts, ou la complexité.

Bons candidats cloud

• Frontaux web, reverse proxy, API stateless.
• Jobs batch, workers, traitement asynchrone.
• Environnements de test et CI.
• Outils internes accessibles à distance (wiki, dashboard, vault), si bien sécurisés.

À garder local

• Charges ultra sensibles à la latence : AD/LDAP, certaines bases de données critiques, systèmes temps réel.
• Stockage lourd et constant (coûts et egress).
• Services collés au LAN (imprimantes, OT, équipements spécifiques).

Approche progressive

Déplacez un service non critique, validez : réseau, DNS, TLS, monitoring, sauvegarde. Puis seulement ensuite, vous élargissez.

Et pensez dépendances : IP fixes, endpoints, secrets, règles firewall. Souvent ce n’est pas la VM le problème. C’est tout ce qu’il y a autour.

Observabilité & exploitation : éviter le « ça marche… jusqu’au jour où »

Un tunnel VPN qui marche aujourd’hui peut mourir silencieusement demain, après un update, un changement MTU, une règle firewall cloud, ou une route supprimée.

Monitoring

À minima, surveillez :

• Disponibilité WireGuard (handshake récent).
• Latence et perte de paquets entre sites.
• Bande passante et saturation CPU de la gateway.
• État des routes (un ping ne suffit pas toujours).

Logs

Centralisez les logs de :

• Gateway VPN
• Proxmox
• Services cloud exposés

Syslog, Loki, ELK, peu importe, mais ne laissez pas tout sur chaque machine.

Mises à jour

Planifiez. Snapshots avant changements. Et un rollback possible.

Et oui, documentez les fenêtres de maintenance. Même pour une infra perso, ça sauve des soirées.

Documentation

Schéma réseau, plages IP, ports, procédures de reprise, inventaire des clés. C’est chiant à faire. Mais c’est pire à reconstruire de mémoire.

Pièges fréquents (et comment les éviter)

• Chevauchement d’IP : ça casse tout. Faites un plan d’adressage dès le début.
• MTU : symptômes trompeurs. Ajustez MTU WireGuard, et si besoin MSS clamping.
• Routage asymétrique : le trafic part par un chemin et revient par un autre. Résultat : timeouts bizarres. Tracez, et imposez les routes.
• AllowedIPs
• Coûts réseau : egress, IP publiques, stockage objet, snapshots. Mettez des alertes budget, sinon surprise.

Exemple de plan de déploiement en 7 jours (simple et réaliste)

Jour 1 : cadrage

Cas d’usage, RPO/RTO, plan IP, choix WireGuard, décision sur où terminer le VPN.

Jour 2 : fondations cloud

VPC, subnets, VM gateway, règles firewall cloud, IP publique.

Jour 3 : tunnel et routage

WireGuard up, routes statiques, tests ping et traceroute, réglage MTU si besoin.

Jour 4 : sécurité

Deny by default, bastion SSH, clés, restrictions IP, premières règles inter-réseaux.

Jour 5 : sauvegardes

PBS ou objet, première réplication, test d’une restauration simple.

Jour 6 : premier workload

Un service non critique, DNS interne, TLS, monitoring.

Jour 7 : documentation et test PRA

Procédure de reprise, checklist d’exploitation, test de restauration sérieux, et validation finale.

Conclusion : une interconnexion sobre, sécurisée, et vraiment utile

Le cloud hybride avec Proxmox VE, Scaleway ou OVHcloud, ça peut devenir un gros monstre. Mais ce n’est pas obligatoire. Le bon chemin, celui qui tient dans la durée, c’est souvent : un VPN WireGuard propre, des routes claires, une sécurité stricte (bastion + firewall), puis un vrai gain concret autour du backup et du PRA.

Commencez petit, mesurez, documentez. Et seulement ensuite, industrialisez. Haute dispo de la gateway, double fournisseur, automatisation Terraform ou Ansible. Oui, ça viendra peut-être. Mais d’abord, faites un truc simple qui marche. Et qui marche encore dans trois mois, sans que vous ayez peur d’y toucher.

Questions fréquemment posées

Pourquoi connecter Proxmox VE à un cloud souverain comme Scaleway ou OVHcloud en 2026 ?

Connecter Proxmox VE à un cloud souverain permet de bénéficier d'une infrastructure hybride pragmatique : garder le contrôle sur l'infrastructure locale tout en profitant de l'élasticité, la redondance géographique et la sauvegarde hors site offertes par le cloud. Cela évite une migration complète et garantit conformité RGPD, localisation des données en France/UE, et réversibilité.

Quels sont les cas d'usage typiques pour une interconnexion entre Proxmox VE on-premise et un cloud souverain ?

Les cas d'usage courants incluent : un plan de reprise d'activité (PRA) et continuité (PCA) opérationnel, le burst de charge temporaire dans le cloud, les sauvegardes immuables chiffrées hors site, les environnements de test isolés, ainsi que l'exposition sécurisée de services via reverse proxy, WAF ou bastion sans ouvrir le réseau local.

Quels sont les prérequis nécessaires avant de configurer une interconnexion VPN entre Proxmox VE et un cloud souverain ?

Du côté local : un serveur Proxmox VE fonctionnel avec accès root/SSH, réseau stable avec sous-réseaux définis, sortie internet correcte (idéalement IP publique fixe), et un routeur permettant ouverture port UDP. Du côté cloud : compte actif chez Scaleway ou OVHcloud, VPC avec sous-réseau privé, VM gateway VPN (Ubuntu/Debian), règles de sécurité adaptées, et idéalement une IP publique stable pour la gateway.

Quelles compétences techniques sont recommandées pour réussir la connexion entre Proxmox VE et un cloud souverain ?

Il est recommandé d'avoir une bonne maîtrise des notions suivantes : IP et sous-réseaux, routage réseau, DNS, certificats TLS, SSH, gestion des pare-feux Linux (nftables/iptables/ufw), ainsi que comprendre les problématiques liées au MTU, asymétrie de routes et NAT. Une expertise avancée en BGP n'est pas nécessaire.

Quels modèles d'interconnexion sont disponibles pour relier Proxmox VE à un cloud souverain et quand les utiliser ?

Trois approches principales existent : 1) VPN site-à-site (recommandé) utilisant WireGuard ou IPsec pour une liaison sécurisée entre deux réseaux privés ; 2) Réseau overlay (Tailscale, ZeroTier) adapté sans IP publique ; 3) Autres méthodes selon besoins spécifiques. Le VPN site-à-site est simple, robuste et gouvernable pour commencer.

Quels objectifs doit-on définir avant de mettre en place une interconnexion entre Proxmox VE on-premise et un cloud souverain ?

Il est crucial de clarifier l'objectif principal : accès administrateur aux VM, réplication/sauvegarde des données, exposition sécurisée de services ou gestion du burst de charge. Il faut aussi considérer les contraintes telles que latence acceptable, débit nécessaire, coût réseau (egress), maintenance possible et exigences en haute disponibilité afin d'adapter l'architecture correctement.