Déployer QloApps sur VPS pour hôtellerie : tutoriel 2026

📍 Article principal : Système booking hôtelier open-source 2026

Introduction

Pour l’hôtel boutique de Saint-Louis du Sénégal mentionné dans le pilier, le déploiement initial de QloApps a pris 4 jours de consultant local. Le résultat : un système de réservation directe complet, intégré au site WordPress existant, avec paiement Wave, channel manager Channex, et formation de la responsable réception. Ce tutoriel détaille le déploiement complet pas-à-pas, depuis le provisioning du VPS jusqu’à la mise en service avec les premières réservations directes. L’objectif est de permettre à un développeur ou consultant local de reproduire ce déploiement pour ses propres clients hôteliers, en quelques jours, sur la base d’un compromis Scaleway ou OVH selon les préférences de souveraineté.

Prérequis

• Compte cloud (Scaleway PAR1 ou OVH SBG selon préférence souveraineté)
• Domaine pour l’hôtel (par exemple reservation.hotel-monsite.sn)
• Bases SSH, Docker, MySQL/MariaDB
• Photos professionnelles des chambres et installations préparées
• Niveau : intermédiaire — Temps : 4-6 heures déploiement initial + 1-2 jours configuration métier

Étape 1 — Provisionner le VPS

QloApps demande des ressources modérées : 4 Go RAM minimum, 40 Go de disque, 2 vCPUs. Sur Scaleway, un Stardust2 (2 vCPU, 2 Go RAM, 20 Go SSD) à 4 euros par mois suffit pour démarrer un petit hôtel de 10-20 chambres, à monter en DEV1-S (4 Go RAM) à 8 euros mensuels pour plus de confort. Sur OVH, un VPS SSD-2 (4 Go RAM, 80 Go SSD) à 7 euros mensuels offre un bon équilibre. Pour les structures qui veulent absolument héberger en Afrique, des fournisseurs locaux comme Africloud ou Sénégal Numérique SA proposent des VPS adaptés à des tarifs un peu plus élevés mais avec souveraineté nationale.

La distribution recommandée est Debian 13 ou Ubuntu 24.04 LTS pour stabilité long terme et support Docker natif. Premier réflexe après création : durcir le SSH, créer un utilisateur non-root, désactiver l’auth par mot de passe. Cette base de sécurité prend 30 minutes mais protège contre les attaques opportunistes. Pour un système qui hébergera des données clients sensibles (paiements, identités), cette discipline est non-négociable.

Étape 2 — Installer Docker et préparer l’environnement

Docker simplifie radicalement le déploiement de QloApps en encapsulant PHP, MySQL, et les dépendances dans des containers reproductibles. L’installation via le script officiel Docker prend quelques minutes. On crée ensuite la structure de projet QloApps avec les volumes persistants pour les données et les uploads.

# Installation Docker
curl -fsSL https://get.docker.com | sh
usermod -aG docker votre_user

# Préparer le dossier projet
mkdir -p /srv/qloapps/data /srv/qloapps/db
cd /srv/qloapps

# Créer docker-compose.yml
cat > docker-compose.yml <<'EOF'
services:
  qloapps:
    image: qloapps/qloapps:latest
    ports: ["8080:80"]
    environment:
      QLO_DB_HOST: db
      QLO_DB_NAME: qloapps
      QLO_DB_USER: qlo
      QLO_DB_PASSWORD: ${DB_PASS}
      QLO_DOMAIN: reservation.hotel-monsite.sn
    volumes:
      - ./data:/var/www/html
    depends_on: [db]

  db:
    image: mariadb:10.11
    environment:
      MARIADB_DATABASE: qloapps
      MARIADB_USER: qlo
      MARIADB_PASSWORD: ${DB_PASS}
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASS}
    volumes: [./db:/var/lib/mysql]
EOF

Cette configuration de base démarre QloApps avec sa base MariaDB. Les volumes locaux (./data et ./db) garantissent la persistance des données entre redémarrages des containers. Pour la sécurité, générer des mots de passe robustes via openssl rand et les stocker dans un fichier .env protégé.

Étape 3 — Reverse proxy Caddy avec HTTPS

Pour exposer QloApps en HTTPS, on installe Caddy en frontal qui gère automatiquement les certificats Let’s Encrypt. Cette protection chiffre les communications et est essentielle pour les paiements en ligne. Avant configuration, le DNS du domaine doit pointer vers l’IP du VPS.

apt install -y caddy

cat > /etc/caddy/Caddyfile <<EOF
reservation.hotel-monsite.sn {
    reverse_proxy localhost:8080
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
    }
}
EOF

systemctl reload caddy

Une fois propagation DNS effectuée, l’application est accessible en HTTPS valide reconnu par tous les navigateurs. Cette base sécurité est minimum pour un système qui traitera des transactions de paiement réelles.

Étape 4 — Installation initiale via wizard

Au premier accès à l’URL, QloApps lance son assistant d’installation qui guide la configuration de base : informations hôtel, devise principale (XOF pour zone CFA), email administrateur, langue par défaut. Cet assistant prend 15-20 minutes et configure les paramètres fondamentaux. Une fois terminé, supprimer le dossier /install pour sécurité.

L’interface admin de QloApps devient ensuite accessible. Premier réflexe : changer immédiatement le mot de passe admin pour une valeur robuste, configurer la 2FA si possible (plugin disponible), et créer les comptes pour les autres membres de l’équipe avec rôles appropriés (réception, comptabilité, direction). Cette ségrégation des accès suit le principe du moindre privilège.

Étape 5 — Configurer les chambres et tarifs

La configuration métier prend l’essentiel du temps de mise en place. Pour chaque type de chambre (standard, supérieure, suite), créer une entrée avec : description détaillée bilingue ou trilingue (français, anglais, optionnellement portugais selon clientèle), photos professionnelles haute résolution, capacité (adultes, enfants), équipements (climatisation, vue mer, terrasse), tarifs saisonniers fins.

Pour les tarifs, configurer typiquement 3-4 saisons par an : haute saison (novembre-mars pour les hôtels balnéaires), saison moyenne (avril, octobre), basse saison (mai-juin), hivernage (juillet-septembre). Chaque saison a son tarif propre. Cette segmentation fine maximise le revenu en période forte tout en stimulant la demande en période creuse via tarifs attractifs.

Étape 6 — Intégrer paiement Wave et Stripe

Pour accepter le mobile money local et les cartes internationales, deux modules de paiement à configurer. Wave Direct via le plugin PrestaShop officiel ou via PayDunya pour couvrir aussi Orange Money et MTN. Stripe pour les cartes Visa/MasterCard internationales avec une présence forte des touristes européens et nord-américains. La configuration de chaque module se fait via les credentials API obtenus auprès des prestataires respectifs.

Pour les tests, activer le mode sandbox des deux passerelles, effectuer des transactions tests pour valider le flux complet (paiement réussi, paiement échoué, remboursement). Cette validation pré-production évite les déconvenues en conditions réelles. Une fois validé, basculer en mode production avec credentials réels et premières transactions live.

Étape 7 — Sauvegardes automatisées

Les données de réservation sont irremplaçables. Configurer des sauvegardes nocturnes chiffrées vers un object storage externe est indispensable. Pour la souveraineté, Scaleway Object Storage PAR1 ou OVH Object Storage RBX conviennent en alternative à Hetzner. Un script bash simple combine pg_dump équivalent MariaDB, gzip, gpg pour chiffrement, et rclone pour upload.

#!/usr/bin/env bash
DATE=$(date +%Y%m%d)
docker exec qloapps-db-1 mariadb-dump -uroot -p${DB_ROOT_PASS} qloapps \
  | gzip \
  | gpg --batch --passphrase-file /root/.backup-pass --symmetric \
  | rclone rcat scaleway:hotel-backups/db-${DATE}.sql.gz.gpg

# Sauvegarder aussi les fichiers uploadés (photos, factures PDF)
tar czf - /srv/qloapps/data/img \
  | gpg --batch --passphrase-file /root/.backup-pass --symmetric \
  | rclone rcat scaleway:hotel-backups/files-${DATE}.tar.gz.gpg

# Rétention 30 jours
rclone delete --min-age 30d scaleway:hotel-backups/

Cron quotidien à 3h du matin local. Tester la restauration trimestriellement pour valider la procédure. Sans ce test régulier, la sauvegarde reste une fausse impression de sécurité que la première vraie panne révélera.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, optimiser pour mobile reste la priorité : tester sur Tecno, Itel, Infinix d’entrée de gamme avec connexion 3G simulée pour valider l’expérience réelle des clients ouest-africains qui réservent depuis leur smartphone. Deuxièmement, supporter les indicatifs téléphoniques régionaux dans les formulaires : +221 Sénégal, +225 Côte d’Ivoire, +223 Mali, +226 Burkina Faso, etc. Validation lib JavaScript adaptée au format E.164. Troisièmement, prévoir des messages de confirmation réservation en français standard plus optionnellement en wolof, bambara, ou peul selon la clientèle ciblée. Cette attention culturelle améliore considérablement la perception de qualité.

Pour les coûts d’opération typiques d’un hôtel de 20 chambres, prévoir 8-15 euros par mois infrastructure (VPS plus stockage backups), 30-80 euros mensuels en frais channel manager si externe, environ 2 % de commission sur les paiements mobile money. Total mensuel inférieur à 100 euros, à comparer aux centaines d’euros économisés sur les commissions OTA.

Tutoriels frères

• Channel manager Channex
• Paiement mobile money
• SEO local hôtellerie

Pour aller plus loin

• 🔝 Pilier : Hôtellerie booking 2026
• Doc : QloApps documentation

FAQ

Combien de temps pour le déploiement complet ?
4-6 heures pour un développeur familier de Docker et PrestaShop. 1-2 jours supplémentaires pour la configuration métier complète (chambres, tarifs, services).

QloApps supporte-t-il les hôtels avec restaurant intégré ?
Oui via le module restaurant qui permet la facturation des couverts, room service, mini-bar séparément ou ajoutés à la note de chambre.

Quelle alternative si QloApps ne convient pas ?
HotelDruid pour très petites structures, ou SaaS comme Mews/Cloudbeds pour hôtels qui veulent zéro maintenance technique.

Comment migrer depuis un autre PMS ?
Export des données via API du PMS source, transformation au format QloApps, import via scripts CSV. Demande quelques jours mais reste faisable pour la majorité des PMS établis.

Configuration multilingue avancée

Pour les hôtels qui ciblent une clientèle internationale diversifiée, configurer correctement le multilingue est crucial. QloApps supporte nativement plusieurs langues simultanément avec traduction de chaque contenu (descriptions chambres, conditions, emails de confirmation). Pour un hôtel balnéaire ouest-africain, prévoir au minimum trois langues : français pour la clientèle francophone (locale, française, belge, suisse), anglais pour anglophones (Royaume-Uni, États-Unis, Pays-Bas, Allemagne nordiste, Nigeria, Ghana voisins), et selon clientèle portugais (Portugal, Brésil, Cap-Vert, Angola).

La configuration linguistique se fait via Préférences → Localisation → Langues. Importer les packs de langue officiels QloApps puis traduire les contenus métier spécifiques (descriptions chambres, services). Pour la qualité des traductions, ne pas se contenter de Google Translate qui produit des textes maladroits — investir dans un traducteur professionnel pour les contenus principaux ou utiliser DeepL (qualité supérieure pour les langues européennes). Le surcoût initial paye sur la durée par un taux de conversion supérieur des clients étrangers.

Optimisations de performance

Pour des performances optimales en contexte ouest-africain où la connectivité varie, plusieurs optimisations standard. Premièrement, activer le cache PrestaShop (sous-jacent QloApps) : Smarty cache, cache CCC pour CSS/JS combinés et minifiés. Cette configuration via le panneau admin réduit drastiquement les temps de chargement. Deuxièmement, mettre Cloudflare en frontal du domaine pour cache edge et compression Brotli — gain typique 50-60 % de réduction du temps de chargement perçu en Afrique de l’Ouest grâce aux PoPs Lagos et Accra. Troisièmement, optimiser les images : convertir toutes les photos en format WebP, redimensionner aux tailles d’affichage exactes plutôt que servir des originaux haute résolution. Cette optimisation seule peut diviser par 5 le poids des pages catalogue.

Pour valider les optimisations, utiliser Lighthouse en mode Slow 4G pour simuler les conditions réelles ouest-africaines. Viser un score Performance supérieur à 80 et un LCP sous 2,5 secondes. Au-delà, l’expérience commence à frustrer les utilisateurs et le taux de conversion chute mécaniquement.

Conformité RGPD pour clients européens

Beaucoup de clients hôteliers ouest-africains sont européens, ce qui rend la conformité RGPD obligatoire pour les données traitées. Trois mesures essentielles côté QloApps. Premièrement, afficher une bannière de cookies conforme avec choix granulaire (essentiels, analytics, marketing) avant tout dépôt de cookies non-essentiels. Plusieurs modules PrestaShop gratuits font le travail. Deuxièmement, prévoir une page Politique de confidentialité claire qui explique : quelles données sont collectées, pourquoi, combien de temps elles sont conservées, droits des personnes (accès, rectification, suppression, portabilité). Troisièmement, implémenter techniquement les droits utilisateurs : un client peut demander un export de ses données ou leur suppression — la réponse doit arriver sous 30 jours selon le règlement.

Pour les hôteliers qui traitent peu de clients européens, ces mesures peuvent paraître excessives mais elles deviennent progressivement la norme attendue par les voyageurs informés. Anticiper cette conformité plutôt que la subir suite à une plainte est largement plus économique.

Plusieurs prestataires juridiques locaux et européens proposent des templates de politique de confidentialité conformes à adapter au contexte spécifique de l’hôtel.

Pour des hôtels qui veulent une approche plus formalisée, faire valider la politique par un avocat spécialisé en droit du numérique reste l’option la plus sûre malgré le coût supplémentaire.

Cette validation juridique est particulièrement recommandée pour les structures qui ambitionnent de servir une clientèle institutionnelle (entreprises, ONG, séjours groupés) où les exigences contractuelles sont plus formalisées.