FAQ

Questions fréquemment posées

De petits guides pratiques pour la configuration du service, l'accès et les actions courantes des clients.

> Generer une cle SSH publique dans le terminal

Cree une cle SSH publique pour acceder au service et partage seulement la public key.
faq/generer-une-cle-ssh-publique

Utiliser seulement la cle publique

SSH utilise une paire de cles. Dans les parametres du service, colle seulement la cle publique, generalement le fichier .pub. La cle privee reste sur ton appareil.

Etapes dans le terminal

  1. Ouvre Terminal, Windows Terminal ou PowerShell.
  2. Execute: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Accepte l emplacement par defaut ou choisis un chemin sur.
  4. Affiche la cle publique avec: cat ~/.ssh/id_ed25519.pub.
  5. Dans Windows PowerShell utilise: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Copie toute la ligne ssh-ed25519 dans le champ SSH public key.

Verifier avant de coller

Ne copie pas la cle privee. Si tu definis une passphrase, conserve-la en securite pour plus tard.

> Creer une cle SSH avec une interface graphique Windows

Methode graphique Windows avec PuTTYgen pour creer une cle SSH.
faq/creer-une-cle-ssh-windows-interface-graphique

Seule la partie publique suffit

PuTTYgen cree une cle publique et une cle privee. Ajoute seulement la cle publique dans Cli>_ et garde la cle privee localement.

Etapes dans Windows

  1. Ouvre PuTTYgen.
  2. Choisis EdDSA / Ed25519 si disponible.
  3. Utilise RSA 4096 seulement comme solution de repli.
  4. Clique sur Generate et bouge la souris jusqu a la creation de la cle.
  5. Enregistre la cle privee sur ton ordinateur.
  6. Copie le texte de la cle publique dans le champ SSH public key.

Ne partage pas de donnees secretes

N envoie pas de fichiers .ppk, cles privees, passphrase, mots de passe ou tokens au support ou dans des formulaires.

> Connecter votre propre domaine

Avant de basculer un domaine, vérifie DNS autoritatif, hostname exact, type d’enregistrement, apex ou sous-domaine, et anciens conflits.
faq/connecter-votre-propre-domaine

Le hostname exact compte

Détermine d’abord si tu connectes un domaine apex comme example.com ou un sous-domaine comme app.example.com. Chaque variante peut demander un type DNS différent et dépendre des limites du fournisseur DNS.

Avant de modifier DNS

  1. Vérifie où les enregistrements DNS autoritatifs du domaine se modifient.
  2. Supprime ou ajuste les A/AAAA, CNAME, ALIAS, ANAME ou redirections en conflit.
  3. Utilise le type d’enregistrement recommandé pour le service et le hostname.
  4. Après la modification, attends la propagation DNS avant de tester le HTTPS final.

Retour arrière sûr

Ne coupe pas l’ancien hébergement avant que le nouveau hostname réponde correctement. En cas de problème, envoie le domaine, la cible attendue et le résultat DNS public, pas les accès au registrar.

> Deleguer une zone DNS

A/AAAA pointent vers des adresses, CNAME vers un alias, MX vers le mail et TXT vers vérification, SPF, DKIM ou DMARC.
faq/deleguer-une-zone-dns

Ne pas mélanger les enregistrements au hasard

Chaque type DNS a un rôle différent. A et AAAA pointent vers des IP, CNAME crée un alias pour un sous-domaine, MX route le mail, TXT porte validations et politiques mail, CAA limite les autorités de certification.

Lors de la copie des enregistrements

  1. Copie nom, type et valeur exactement selon les instructions du service.
  2. Ne mets pas CNAME sur un hostname qui a déjà d’autres enregistrements si les règles DNS l’interdisent.
  3. Place DKIM sous le selector du fournisseur et DMARC généralement sous _dmarc.
  4. Configure CAA avec prudence car une mauvaise valeur peut bloquer le certificat.

Quand DNS ne fonctionne pas

Envoie hostname, type d’enregistrement, valeur attendue et résultat public visible. N’envoie pas de login DNS ni captures avec données d’accès sensibles.

> Création de compte et première connexion

Crée un compte de travail, complète les données de facturation et utilise une adresse e-mail que l’équipe gardera dans le temps.
faq/account-registration-and-login

Un compte pour commander et gérer

Le compte sert de point durable pour les commandes, les données de facturation, les services, les domaines et les échanges avec le support. Utilise idéalement une adresse professionnelle accessible à l’équipe même après des changements de personnes.

Avant la première commande

  1. Inscris-toi avec une adresse e-mail professionnelle.
  2. Confirme l’adresse si le site le demande.
  3. Complète les données de facturation avant une commande payante.
  4. Active l’authentification à deux facteurs dès qu’elle est disponible.

Accès de l’équipe

N’envoie pas ton mot de passe par chat ou e-mail. Utilisez un gestionnaire de mots de passe interne ou demandez une procédure d’équipe adaptée; le support n’a pas besoin de ton mot de passe.

> Fonctionnement du crédit prépayé

Le crédit affiche le solde, l’autonomie estimée, la consommation quotidienne des services actifs et l’échéance visible de suppression en cas de suspension.
faq/prepaid-credit-how-it-works

Le crédit se consomme pendant l’exécution du service

Pour les services prépayés, le solde diminue selon le temps actif et les paramètres choisis. Le prix quotidien aide à estimer combien de jours le service peut rester actif et quand une échéance de suppression peut apparaître.

Éviter la suspension

  1. Après connexion, surveille le solde et l’autonomie estimée.
  2. Vérifie le nouveau prix quotidien avant de confirmer une commande ou modification.
  3. Recharge avec une marge, pas le jour de l’épuisement.
  4. Pour un service suspendu, lis tout de suite l’échéance possible de suppression des données.

Si le solde surprend

Envoie le numéro de commande, le nom du service et la période à vérifier. N’envoie pas de données de carte, mots de passe, clés privées ni relevés complets avec données sensibles.

> Estimation mensuelle, annuelle et consommation quotidienne réelle

Les prix mensuels et annuels servent à comparer; pour les services prépayés, la consommation quotidienne après confirmation compte.
faq/billing-periods-and-credit-burn

La comparaison n’est pas un calendrier de facture

Utilise l’estimation mensuelle comme comparaison sur 31 jours et l’annuelle sur 372 jours. La consommation réelle dépend du temps actif du service et de la configuration confirmée.

Vérifier une variation de prix

  1. Compare la consommation quotidienne avant et après la modification.
  2. Plus de CPU, RAM, disque ou options payantes augmente la consommation.
  3. Considère la modification active seulement après confirmation, paiement si nécessaire et application.
  4. Conserve confirmation de commande et historique de crédit pour la comptabilité.

Discuter une période précise

Le support a besoin du numéro de commande, du nom du service et des dates à contrôler. N’envoie pas de données bancaires ni captures contenant des données personnelles inutiles.

> Statut de commande après paiement

Après paiement, une commande peut attendre la confirmation du prestataire; ne crée un doublon qu’après annulation ou expiration claire.
faq/order-status-and-payment-confirmation

Pending ne veut pas toujours dire échec

Après la page de paiement, la commande peut encore attendre la confirmation du prestataire. Tant que le statut n’est pas clairement échoué ou expiré, une commande dupliquée peut compliquer le rapprochement.

Après le paiement

  1. Reviens dans Cli>_ une fois le paiement terminé.
  2. Vérifie le statut de commande et le message éventuel de paiement dans ton compte.
  3. Si la commande attend encore, laisse le prestataire confirmer.
  4. En cas de problème, envoie au support le numéro de commande et la référence visible du paiement.

Données de paiement inutiles

Le support n’a pas besoin des données de carte, du mot de passe ni du reçu bancaire complet. Le numéro de commande, l’heure de paiement, le statut visible et une capture masquée suffisent.

> Informations qui accélèrent la mise en place du service

Prépare le nom du service, le domaine, la taille de stockage, l’e-mail d’accès et la clé SSH publique; les données sensibles ne vont pas dans les formulaires.
faq/service-setup-information-needed

Des entrées précises font gagner du temps

Les formulaires de commande doivent contenir des valeurs publiques ou non sensibles: nom du service, domaine, plan DNS, stockage, CPU, RAM, e-mail admin ou clé SSH publique. Les mots de passe et clés privées n’y ont pas leur place.

À préparer avant la commande

  1. Choisis un nom de service reconnaissable par l’équipe.
  2. Décide entre domaine propre et hostname temporaire.
  3. Prépare la clé SSH publique si le service la demande.
  4. Vérifie stockage et ressources selon l’application à exploiter.

Ne pas envoyer de valeurs sensibles

Si tu ne sais pas si une donnée est sensible, demande sans l’envoyer. Clés privées, mots de passe, exports de base de données et fichiers de configuration complets ne doivent pas être envoyés dans le chat ou la commande.

> Modifier CPU, RAM, disque ou rétention après commande

Modifie un service existant depuis son détail, pas avec une nouvelle commande; prix, consommation quotidienne, redémarrage et indisponibilité peuvent changer.
faq/change-service-resources-after-order

Tu modifies un service existant

Si le service fonctionne déjà, change ses ressources depuis son détail. Une nouvelle commande créerait un autre service au lieu d’ajuster l’existant et peut changer le prix, la consommation quotidienne et le comportement opérationnel.

Avant de confirmer

  1. Vérifie CPU, RAM, disque, backups et rétention Offsite Archive actuels.
  2. Contrôle le nouveau prix quotidien et l’impact sur le crédit.
  3. Lis les avertissements de redémarrage, maintenance ou coupure.
  4. Fais ton propre export des données importantes avant un changement risqué.

Si le changement ne se passe pas comme prévu

Envoie le nom du service, l’heure du changement, le statut visible et le message d’erreur. N’envoie pas de clés privées ni mots de passe; contexte public et capture masquée suffisent.

> Annulation du service et échéance de suppression des données

Un service déjà mis en place est d’abord suspendu, affiche une échéance configurable de suppression, puis peut être purgé définitivement.
faq/cancel-service-and-data-retention

Annuler ne supprime pas toujours immédiatement

Pour un service déjà mis en place, le service est d’abord suspendu et une échéance configurable de suppression s’affiche, laissant le temps de décider d’une restauration ou d’un export. Les commandes impayées en attente sans données actives peuvent suivre un autre comportement.

Avant d’annuler

  1. Crée ton propre export des données à conserver longtemps.
  2. Lis la date et l’heure de suppression prévue sur le service suspendu.
  3. Ne confonds pas backups et Offsite Archive avec la suppression liée au cycle de vie du service.
  4. Contacte le support avant l’échéance si tu hésites.

Après l’échéance, la restauration peut être impossible

Après l’échéance visible, ne considère plus les données comme disponibles. Pour une question, envoie numéro de commande et nom de service, pas des exports de base de données ni identifiants.

> Backups et demandes de restauration

Les backups servent à la restauration opérationnelle, pas à remplacer un export; une restauration peut écraser des données plus récentes.
faq/backups-and-restore-requests

Un backup n’est ni une archive ni un export

La rétention des backups dépend du produit et des options. Le backup aide à restaurer après incident, mais ne remplace pas un export propre, une archive d’audit ni Offsite Archive. Une restauration peut écraser des changements récents.

Préparer une demande de restauration

  1. Indique le nom du service et le numéro de commande.
  2. Décris le moment approximatif auquel revenir.
  3. Précise si tout le service ou une partie doit être restauré, si c’est supporté.
  4. Ajoute l’erreur visible ou le contexte sans mots de passe ni clés privées.

Prévoir l’impact

Si le service a reçu de nouvelles données entre-temps, la restauration peut les remplacer par un état plus ancien. Informe l’équipe et exporte ce que tu ne veux pas perdre avant confirmation.

> À quoi sert Offsite Archive

Offsite Archive garde des copies d’archive distantes, séparées des backups courts et du cycle de vie du service.
faq/offsite-archive-purpose

Archive hors exploitation courante

Offsite Archive est destiné aux copies d’archive distantes et à une conservation plus longue. Ce n’est pas un disque live pour l’application, ni un remplacement d’export local, ni la même chose que des backups opérationnels courts.

Quand l’activer

  1. Utilise-le pour des données à conserver hors de l’exploitation normale du service.
  2. Choisis les jours de rétention selon compliance, besoin métier ou objectif de recovery.
  3. Surveille le coût, qui augmente avec volume stocké et durée de conservation.
  4. Pour de gros volumes, planifie l’archive avec ton propre processus d’export.

Comprendre le prix

La base est MB-days: volume stocké multiplié par nombre de jours conservés. Le tarif est affiché en EUR/GB/mois et le résultat est arrondi au centime.

> Choisir CPU, RAM et disque pour un VPS

Dimensionne le VPS selon application, base de données, cache, logs et croissance; OOM ou swap indiquent souvent un besoin de RAM.
faq/vps-cpu-ram-and-disk-sizing

Partir de la charge réelle

Un petit site statique n’a pas les mêmes besoins qu’une base de données, une application Java, un moteur de recherche ou un conteneur de build. Prévois mémoire applicative, cache, base, logs, uploads et marge de croissance.

Signes d’un plan trop petit

  1. Augmente la RAM en cas de OOM, out of memory, process killed ou swap permanent.
  2. Augmente le CPU pour calcul soutenu, compression, builds ou workers très occupés.
  3. Augmente le disque avant saturation du système de fichiers, des logs ou de la base.
  4. Après chaque changement, vérifie que l’application ne touche plus l’ancienne limite.

Demande de sizing utile

Le nom du service, le type d’application, l’erreur visible, l’heure approximative et les CPU, RAM et disque actuels aident. N’envoie pas de mots de passe, clés privées ni fichiers de configuration internes.

> Quand une IP publique pour VPS est utile

Une IP publique dédiée aide pour les allowlists, l’accès inbound, une source outbound stable ou les services liés à une adresse.
faq/vps-public-ip-options

Identifier le sens de communication

Une IP publique n’est pas automatiquement nécessaire pour chaque service. Elle répond surtout aux exigences de partenaires, prestataires ou firewalls: allowlist, source outbound stable ou accès inbound sur un port précis.

Questions avant de commander une IP

  1. Demande au partenaire si l’allowlist concerne inbound, outbound ou les deux.
  2. Utilise des noms DNS plutôt que des IP numériques quand le système externe le permet.
  3. N’ouvre que les ports réellement nécessaires à l’application.
  4. Envoie l’exigence d’allowlist au support avant de modifier l’accès production.

Ce qui doit rester fermé

Une IP publique ne signifie pas ouvrir tous les ports. Conçois l’accès avec le minimum de services nécessaires et n’envoie pas de mots de passe, clés privées ni notes firewall sensibles.

> Accès SSH partagé au VPS

Sans IP publique achetée, le VPS se connecte via un endpoint SSH partagé avec port élevé; avec IP publique, un second chemin SSH direct apparaît.
faq/shared-ssh-access-for-vps

Pourquoi le SSH partagé utilise un port élevé

Plusieurs services VPS peuvent partager le même endpoint SSH public, donc chaque service reçoit son propre port élevé. Ce port fait partie du routage vers ton service; sans lui, la connexion ne pourrait pas être livrée de façon unique au bon VPS.

Connexion selon le type d’accès

  1. Pour le SSH partagé, copie depuis le service le nom d’utilisateur SSH, le host public et le port élevé.
  2. Utilise le format ssh -p <port> <username>@<public-host>.
  3. Si le service a une IP publique achetée, il peut aussi avoir un second endpoint SSH directement sur cette IP ou son nom DNS.
  4. Utilise la clé privée uniquement localement via ton client SSH ou agent; pour le support, indique host public, port, nom d’utilisateur et erreur visible.

Deuxième chemin avec IP publique

L’IP publique ne remplace pas rétroactivement l’endpoint SSH partagé; elle ajoute un accès séparé utile aux allowlists, au monitoring ou aux connexions directes. Tu peux donc voir un host partagé avec port élevé et un host ou IP direct pour le service.

> Checklist avant de connecter un domaine personnalisé

Avant de basculer un domaine, vérifie DNS autoritatif, hostname exact, type d’enregistrement, apex ou sous-domaine, et anciens conflits.
faq/custom-domain-readiness-checklist

Le hostname exact compte

Détermine d’abord si tu connectes un domaine apex comme example.com ou un sous-domaine comme app.example.com. Chaque variante peut demander un type DNS différent et dépendre des limites du fournisseur DNS.

Avant de modifier DNS

  1. Vérifie où les enregistrements DNS autoritatifs du domaine se modifient.
  2. Supprime ou ajuste les A/AAAA, CNAME, ALIAS, ANAME ou redirections en conflit.
  3. Utilise le type d’enregistrement recommandé pour le service et le hostname.
  4. Après la modification, attends la propagation DNS avant de tester le HTTPS final.

Retour arrière sûr

Ne coupe pas l’ancien hébergement avant que le nouveau hostname réponde correctement. En cas de problème, envoie le domaine, la cible attendue et le résultat DNS public, pas les accès au registrar.

> Types d’enregistrements DNS pour les services

A/AAAA pointent vers des adresses, CNAME vers un alias, MX vers le mail et TXT vers vérification, SPF, DKIM ou DMARC.
faq/dns-record-types-for-services

Ne pas mélanger les enregistrements au hasard

Chaque type DNS a un rôle différent. A et AAAA pointent vers des IP, CNAME crée un alias pour un sous-domaine, MX route le mail, TXT porte validations et politiques mail, CAA limite les autorités de certification.

Lors de la copie des enregistrements

  1. Copie nom, type et valeur exactement selon les instructions du service.
  2. Ne mets pas CNAME sur un hostname qui a déjà d’autres enregistrements si les règles DNS l’interdisent.
  3. Place DKIM sous le selector du fournisseur et DMARC généralement sous _dmarc.
  4. Configure CAA avec prudence car une mauvaise valeur peut bloquer le certificat.

Quand DNS ne fonctionne pas

Envoie hostname, type d’enregistrement, valeur attendue et résultat public visible. N’envoie pas de login DNS ni captures avec données d’accès sensibles.

> Propagation DNS et TTL sans promesse à la minute

Le TTL indique combien de temps les resolvers peuvent garder une ancienne réponse; anciens et nouveaux résultats peuvent coexister.
faq/dns-propagation-and-ttl

La propagation est du cache, pas de la magie

En DNS, il n’existe pas de promesse fixe à la minute. Après une modification du DNS autoritatif, différents resolvers peuvent encore renvoyer anciennes et nouvelles réponses jusqu’à expiration du cache selon le TTL.

Pour une modification planifiée

  1. Si le fournisseur le permet, baisse le TTL avant la bascule prévue.
  2. Après la modification DNS, évite les changements aléatoires répétés pendant l’expiration des caches.
  3. Teste depuis plusieurs resolvers si les résultats divergent.
  4. Note l’heure du changement, l’ancienne valeur, la nouvelle valeur et le TTL.

Données utiles au diagnostic

Indique hostname, cible attendue, ancienne réponse visible, nouvelle réponse visible, TTL et heure de changement. Les accès au compte DNS ne sont pas nécessaires.

> Planifier le stockage Nextcloud

Compte les fichiers utilisateurs, dossiers partagés, versions, corbeille, aperçus, surcharge de synchronisation et croissance de l’équipe.
faq/nextcloud-storage-planning

Nextcloud grandit au-delà des fichiers visibles

La capacité est consommée par les fichiers utilisateurs, dossiers partagés, fichiers supprimés, versions, aperçus, miniatures, clients de synchronisation et imports. Proche de la limite, uploads ou synchronisation peuvent échouer.

Avant de commander la capacité

  1. Additionne les données utilisateurs actuelles et dossiers communs.
  2. Ajoute une marge pour versions, corbeille, aperçus et surcharge de synchronisation.
  3. Prends en compte gros imports, nouvelles équipes et croissance attendue.
  4. Augmente la capacité avant que les utilisateurs atteignent la limite.

En cas de problème de synchronisation

Envoie taille du service, utilisation approximative, heure du problème et erreur visible du client. N’envoie pas de fichiers personnels, mots de passe ni exports de données utilisateurs sauf demande explicite par un moyen sûr.

> Migration de dépôts vers Gitea

Planifie le transfert des dépôts Git avec LFS, submodules, droits, deploy keys, webhooks et CI/CD.
faq/gitea-repository-migration

La migration n’est pas seulement git clone

Au-delà de l’historique du dépôt, il faut transférer ou recréer propriétaires, équipes, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks et intégrations CI/CD.

Contrôle avant le cutover

  1. Liste les dépôts, propriétaires, groupes d’accès et comptes d’automatisation.
  2. Vérifie objets Git LFS, submodules, branch protections et tag protections.
  3. Après transfert, teste clone, push, Git LFS, submodules et exécution CI.
  4. Supprime ou renouvelle proprement les anciens accès après migration.

Données sensibles pendant la migration

N’envoie pas de clés privées, partie privée de deploy key ni valeurs CI confidentielles. Les noms de dépôts, type d’intégration, erreur visible et comportement fonctionnel avant migration suffisent.

> Domaine d’envoi pour Listmonk

Pour les campagnes, prépare domaine ou sous-domaine sender, identité From, SPF, DKIM, DMARC, bounce et désinscription.
faq/listmonk-sender-domain-basics

La délivrabilité commence par le domaine

Listmonk a besoin d’une identité From claire et d’enregistrements DNS vérifiables par les systèmes mail. SPF, DKIM et DMARC doivent correspondre au domaine ou sous-domaine d’envoi.

Avant la première campagne

  1. Choisis domaine ou sous-domaine sender et nom From.
  2. Ajoute DNS de vérification, SPF, DKIM selector et DMARC.
  3. Teste livraison, bounce ou Return-Path et liens du message.
  4. Vérifie désinscription et List-Unsubscribe avant l’envoi réel.

Les accès mail ne vont pas dans le ticket

Pour le diagnostic, envoie domaine, type d’enregistrement, valeur DNS publique et message d’erreur. N’envoie pas de mots de passe SMTP, clé DKIM privée ni export de destinataires avec données personnelles.

> Paramètres Runtime pour Classic Hosting

Classic Hosting peut fonctionner en Runtime auto ou manuel; CPU, RAM, stockage, rétention backup, Offsite Archive, uploads, cache et logs influencent prix et stabilité.
faq/classic-hosting-runtime-settings

Le mode auto n’est pas toujours le bon choix

Auto Runtime aide pour les projets reconnus, mais le mode manuel convient si tu veux choisir précisément Nginx, Apache, FrankenPHP ou un runtime de langage. Utilise PHP selector seulement là où le runtime choisi le supporte.

Paramètres avant déploiement

  1. Choisis auto ou manuel selon le framework et la méthode de build.
  2. Choisis PHP 8.2, 8.3 ou 8.4 seulement pour les scénarios PHP supportés.
  3. Configure CPU, RAM, disque, rétention backup et Offsite Archive selon données et trafic.
  4. Après deploy, teste uploads, cache, logs et erreurs applicatives visibles.

Si l’application ne démarre pas

Envoie mode runtime, langage ou version PHP, erreur visible, changement effectué et heure approximative du déploiement. N’envoie pas de fichiers .env, mots de passe ni logs complets avec valeurs sensibles.

> Quelles informations envoyer au support en sécurité

Les plus utiles sont numéros de commande, noms de services, domaines, heures, hosts publics, ports, paramètres d’hébergement et erreurs visibles sans données sensibles.
faq/support-safe-information-to-share

Un bon ticket donne du contexte, pas des données sensibles

Le support répond plus vite avec numéro de commande, nom du service, domaine, host public ou port, heure du problème, changement réalisé et message d’erreur visible exact.

Contenu sûr du message

  1. Indique commande, service, domaine, heure et étape où le problème apparaît.
  2. Pour l’hébergement, ajoute runtime, PHP ou langage, CPU, RAM, disque, uploads, cache et logs sans valeurs sensibles.
  3. Découpe ou masque les captures avant envoi.
  4. Si tu hésites sur une information, demande d’abord sans l’envoyer.

À ne jamais envoyer

N’envoie pas de mots de passe, clés privées, recovery seeds, session cookies, exports de base de données, fichiers .env complets, logs complets avec valeurs sensibles ni détails internes d’infrastructure.