FAQ

Foire aux questions

Courts guides pratiques pour configurer les services, accéder aux fonctionnalités et effectuer les opérations courantes.

> Comment fonctionne le système de crédit Cli>_ ?

Un solde prépayé commun finance tous les services éligibles et n’est consommé que lorsqu’ils sont actifs.

faq/prepaid-credit-how-it-works

Votre compte Cli>_ possède un solde prépayé commun. Les nouveaux clients éligibles ne peuvent demander le Starter Credit qu’après avoir effectué les vérifications requises du compte et de prévention des abus. Les services actifs éligibles consomment le solde au fil du temps. L’estimation mensuelle utilise 31 jours et un nouveau service ne peut démarrer que si le solde couvre au moins 7 jours. Une alerte rouge apparaît lorsque l’autonomie estimée passe sous 7 jours ; sinon, une alerte orange apparaît lorsqu’elle passe sous 14 jours.

Une fois le solde épuisé, le service est suspendu après 7 jours, cesse de consommer du crédit et le délai de conservation et de suppression de 7 jours commence. Avant l’échéance affichée, vous pouvez le redémarrer avec assez de crédit. L’annulation d’un service provisionné le suspend également et lance le même délai. Un service en attente et non provisionné peut être désactivé immédiatement. Après l’échéance, la désactivation et le retrait du service provisionné commencent. Force delete désactive immédiatement le service, ignore la conservation et lance son retrait du runtime actif ; la fin dépend du traitement du déploiement et de GitOps. Les sauvegardes et Offsite Archive ont des règles de conservation distinctes.

Exemple OpenCode à 9,90 EUR : 9,90 / 31 ≈ 0,319 EUR par jour. Après 10 jours complets, environ 3,19 EUR ont été consommés. Avec un solde initial exact de 9,90 EUR et aucun autre service, il reste environ 6,71 EUR. La consommation s’arrête après désactivation.

Cet exemple est indicatif. Les prix actuellement affichés dans Cli>_ font toujours foi.

> Comment générer une clé SSH publique via l'invite de commandes

Créez une clé SSH publique pour un accès sécurisé à votre serveur virtuel privé (VPS). Partagez uniquement la clé publique avec Cli>_; conservez la clé privée sur votre appareil.

faq/generer-une-cle-ssh-publique

La clé publique est partagée, la clé privée vous appartient

N'insérez que la clé SSH publique lors de votre commande ou de la configuration du service. La clé privée reste sur votre ordinateur et n'est jamais envoyée au support ni saisie dans un formulaire web.

Procédure

  1. Ouvrez le terminal sur votre ordinateur.
  2. Exécutez la commande : ssh-keygen -t ed25519 -C "votre_adresse@example.com".
  3. Confirmez l'emplacement du fichier ou choisissez un chemin personnalisé. Ne communiquez jamais votre clé privée.
  4. Affichez la clé publique avec la commande : `cat ~/.ssh/id_ed25519.pub`.
  5. Copiez la ligne entière commençant par `ssh-ed25519` et collez-la dans le champ "Clé publique SSH" lors de la commande ou de la configuration du service.
  6. Copiez toute la ligne commençant par `ssh-ed25519` et collez-la dans le champ "Clé publique SSH".

PowerShell pour Windows 10/11

  1. Ouvrez PowerShell ou Windows Terminal.
  2. Exécutez la commande : ssh-keygen -t ed25519 -C "votre_adresse@example.com".
  3. Appuyez sur Entrée pour enregistrer la clé dans C:\Users\votre_utilisateur\.ssh\id_ed25519, ou indiquez un chemin personnalisé.
  4. Si Windows vous demande une phrase de passe, utilisez-en une que vous pouvez stocker en toute sécurité, ou appuyez sur Entrée pour une configuration simple.
  5. Affichez la clé publique avec la commande : Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Copiez uniquement la ligne entière commençant par ssh-ed25519. Ne copiez pas et ne téléchargez pas le fichier de clé privée.
> Comment créer une clé SSH graphiquement sous Windows

Guide visuel pour créer une paire de clés SSH sous Windows, sans utiliser l'invite de commandes.

faq/creer-une-cle-ssh-windows-interface-graphique

Utilisez un outil Windows et collez uniquement la clé publique

Vous pouvez créer une paire de clés SSH graphiquement à l'aide d'un client SSH Windows tel que PuTTYgen. Cli>_ a besoin uniquement de la clé publique. Conservez le fichier de clé privée sur votre ordinateur et ne le téléchargez jamais via un formulaire web.

Procédure

  1. Installez PuTTY ou ouvrez PuTTYgen si vous l'avez déjà installé.
  2. Choisissez EdDSA/Ed25519, si disponible, sinon choisissez RSA 4096.
  3. Cliquez sur Générer et déplacez votre souris dans la zone vide jusqu'à ce que la clé apparaisse.
  4. Ajoutez une phrase secrète si vous souhaitez une protection locale supplémentaire pour la clé privée.
  5. Enregistrez la clé privée sur votre appareil et gardez-la confidentielle.
  6. Copiez le texte de la clé publique et collez-le dans le champ "Clé publique SSH" dans Cli>_.

Ne divulguez aucune information sensible

Veuillez ne pas envoyer de fichiers .ppk, de clés privées, de mots de passe ou de jetons au support technique ou dans les formulaires.

> Apportez votre propre domaine

Apprenez comment pointer votre propre domaine ou sous-domaine vers un service CLIopen avant d'activer la fonction "Bring your own domain".

faq/connecter-votre-propre-domaine

Ce que fait ce paramètre

L'option "Utiliser votre propre domaine" permet à votre service de répondre sur votre propre nom d'hôte, par exemple app.example.com, au lieu d'utiliser uniquement le nom d'hôte généré par défaut *.co.cliopen.cloud. Votre DNS doit pointer vers CLIopen avant que le nom d'hôte puisse être utilisé en toute sécurité par le service.

Avant de commencer

  1. Choisissez le nom de domaine exact que vous souhaitez utiliser, par exemple app.example.com. L'utilisation d'un sous-domaine est l'option la plus simple.
  2. Accédez à l'interface de gestion DNS de votre registraire de domaine ou de votre fournisseur DNS.
  3. Supprimez tous les enregistrements A, AAAA, CNAME, ALIAS ou redirections conflictuels pour ce nom de domaine.
  4. Conservez l'hôte CLIopen généré automatiquement tant que votre propre nom d'hôte n'est pas vérifié et pleinement fonctionnel.

Configuration DNS recommandée pour un sous-domaine

Créez des enregistrements DNS pour le nom d'hôte exact que vous saisirez dans CLIopen. Pour app.example.com, le libellé DNS est app. Dirigez-le vers les adresses ingress de CLIopen fournies par le support CLIopen ou dans votre documentation de service. Si votre fournisseur demande un type d'enregistrement, utilisez un enregistrement A pour IPv4 et un enregistrement AAAA pour IPv6 lorsque ces adresses sont fournies.

Exemple :

app.example.com.  A     <adresse IPv4 CLIopen>
app.example.com.  AAAA  <adresse IPv6 CLIopen, si disponible>

Lorsque CLIopen fournit une cible CNAME

Certains services peuvent vous fournir un nom d'hôte généré, par exemple service.customer.co.cliopen.cloud. Si les instructions de votre service indiquent explicitement d'utiliser un enregistrement CNAME, créez un enregistrement tel que app.example.com CNAME service.customer.co.cliopen.cloud. Utilisez uniquement des enregistrements CNAME pour les sous-domaines, et non pour le domaine racine, sauf si votre fournisseur DNS prend en charge l'équivalence ALIAS ou ANAME.

Utilisation du domaine racine

Pour un domaine simple comme example.com, la plupart des fournisseurs DNS n'autorisent pas l'utilisation d'un enregistrement CNAME standard. Utilisez les enregistrements A/AAAA pointant vers les adresses d'entrée CLIopen, ou utilisez la fonctionnalité ALIAS/ANAME de votre fournisseur si CLIopen vous a fourni un nom d'hôte cible.

Délégation d'une sous-zone entière

Si vous souhaitez que CLIopen gère les enregistrements sous une sous-zone telle que apps.example.com, créez des enregistrements NS pour cette sous-zone pointant vers les serveurs de noms CLIopen que vous avez reçus. Ne modifiez pas les serveurs de noms du domaine entier, sauf si vous souhaitez intentionnellement que CLIopen (ou un autre service DNS) gère tous les enregistrements.

Liste de contrôle

  1. Attendez la propagation DNS. Les petits changements sont souvent visibles en quelques minutes, mais certains fournisseurs mettent plus de temps à mettre en cache.
  2. Vérifiez que le nom de domaine pointe vers la cible CLIopen et non vers un ancien fournisseur.
  3. Dans le champ "Bring your own domain", saisissez le nom de domaine exact, sans `https://` ni chemin d'accès.
  4. Après la mise à jour, testez `https://app.example.com` dans votre navigateur.
  5. Conservez les anciens enregistrements DNS uniquement s'ils ne sont pas en conflit avec le nouveau nom de domaine.
> Comment transférer une zone DNS vers CLIopen

Délegez le nom de domaine à ns1.cliopen.com et ns2.cliopen.com afin que CLIopen publie les enregistrements pour toute la zone.

faq/deleguer-une-zone-dns

Que signifie le transfert de zone ici ?

Pour un client utilisant notre service DNS, le transfert signifie modifier les serveurs de noms autoritaires auprès de votre registraire de domaine. Une fois la délégation effectuée vers CLIopen, les enregistrements DNS ajoutés dans CLIopen sont publiés par nos serveurs de noms autoritaires.

Avant de modifier les serveurs de noms

  1. Copiez les enregistrements DNS existants dont vous avez encore besoin, tels que ceux pour le site web, la messagerie, les vérifications, SPF, DKIM, DMARC et les enregistrements de services.
  2. Ajoutez la zone dans CLIopen DNS. Si la délégation n'est pas encore prête, CLIopen l'enregistre mais ne l'active pas pour le client tant que la validation n'est pas réussie.
  3. Créez les enregistrements nécessaires dans CLIopen DNS avant de modifier les serveurs de noms, si possible.
  4. Configurez CAA avec soin, car des valeurs incorrectes peuvent empêcher l'émission de certificats.

Déléguer la zone

  1. Ouvrez les paramètres de votre domaine auprès de votre registraire, par exemple example.com.
  2. Recherchez les serveurs DNS (Nameservers), la délégation DNS ou les paramètres DNS autoritaires.
  3. Remplacez les serveurs DNS actuels par ns1.cliopen.com et ns2.cliopen.com.
  4. Enregistrez les modifications et attendez que les mises à jour soient propagées dans le registre et les résolveurs.

Validation

Retournez à CLIopen DNS et cliquez sur "Vérifier à nouveau la délégation". Lorsque les enregistrements NS publics affichent ns1.cliopen.com et ns2.cliopen.com, la zone est mise en file d'attente pour la synchronisation et les enregistrements deviennent actifs depuis CLIopen.

> Enregistrement du compte et première connexion

Créez un compte professionnel, complétez les informations de facturation et conservez l'accès par e-mail pour que votre équipe ne le perde pas.

faq/account-registration-and-login

Un seul compte pour vos commandes et la gestion

Utilisez ce compte comme un espace permanent pour vos commandes, informations de facturation, services, domaines et communication avec le support. Il est préférable d'utiliser une adresse e-mail professionnelle à laquelle l'équipe aura accès même après des changements de personnel.

Avant votre première commande

  1. Inscrivez-vous avec votre adresse e-mail professionnelle.
  2. Confirmez l'e-mail si le site vous y invite.
  3. Veuillez compléter vos informations de facturation avant de passer une commande payante.
  4. Activez l'authentification à deux facteurs dès qu'elle sera disponible.

Accès pour l'équipe

Ne communiquez jamais votre mot de passe par chat ou par e-mail. Si plusieurs personnes ont besoin d'y accéder, utilisez un gestionnaire de mots de passe interne ou demandez la procédure recommandée pour les équipes ; le support technique n'a pas besoin de votre mot de passe ni de votre jeton d'authentification.

> Estimation mensuelle, estimation annuelle et consommation quotidienne réelle

Les prix mensuels et annuels servent de référence ; pour les services prépayés, la consommation quotidienne est déterminante après confirmation des modifications.

faq/billing-periods-and-credit-burn

La comparaison n'est pas un calendrier de facturation

Utilisez l'estimation mensuelle comme référence pour 31 jours, et l'estimation annuelle pour 372 jours. La consommation réelle du crédit est déterminée par le temps d'utilisation du service et la configuration confirmée.

Ce qu'il faut vérifier lors d'une modification de prix

  1. Comparez la consommation quotidienne avant et après le changement.
  2. Si vous augmentez le processeur (CPU), la mémoire vive (RAM) ou le disque, ou si vous choisissez des options payantes, prévoyez une consommation quotidienne plus élevée.
  3. La modification ne prend effet qu'après confirmation, éventuel paiement et application.
  4. Pour la comptabilité, conservez la confirmation de commande et l'historique du crédit.

Veuillez préciser la période concernée pour toute question.

Le service client a besoin du numéro de commande, du nom du service et des dates à vérifier. Ne transmettez pas d'informations bancaires, de relevés de paiement complets ni de captures d'écran contenant des informations personnelles non souhaitées.

> État de la commande après le paiement

Après le paiement, la commande peut nécessiter un certain temps pour être confirmée par le fournisseur. Ne dupliquez la commande qu'une fois que la première est clairement annulée ou expirée.

faq/order-status-and-payment-confirmation

"En attente" ne signifie pas toujours un échec

Après le retour de la page de paiement, la commande peut encore attendre une confirmation du prestataire de services. Tant que l'état n'est pas clairement indiqué comme échoué ou expiré, une nouvelle commande en double risque de compliquer le rapprochement.

Que faire après le paiement

  1. Une fois le paiement effectué, revenez à Cli>_.
  2. Vérifiez l'état de votre commande et tout message associé au paiement dans votre compte.
  3. Si la commande est toujours en attente, accordez un délai au fournisseur pour confirmer.
  4. En cas de problème, veuillez contacter le support en indiquant le numéro de commande et la référence de paiement, si vous la voyez.

Ce qu'il ne faut pas envoyer

Le service d'assistance n'a pas besoin des informations relatives à votre carte de crédit, de votre mot de passe ou de l'intégralité du relevé bancaire. Veuillez fournir uniquement le numéro de commande, l'heure du paiement, l'état visible et une capture d'écran masquée si une erreur s'affiche.

> Informations qui accélèrent la configuration du service

Préparez le nom du service, le domaine, la taille de stockage, l'adresse e-mail d'accès et la clé SSH publique. Les informations confidentielles ne doivent pas être saisies dans les formulaires.

faq/service-setup-information-needed

Des informations précises vous font gagner du temps

Utilisez les formulaires pour saisir des informations publiques ou non sensibles : nom du service, domaine, plan DNS, taille de stockage, CPU, RAM, adresse e-mail administrateur ou clé SSH publique. Les mots de passe, clés privées et jetons ne doivent pas être inclus dans ces formulaires.

Préparez-vous avant de passer votre commande

  1. Choisissez un nom de service que votre équipe reconnaîtra facilement.
  2. Déterminez si vous souhaitez utiliser votre propre domaine ou un nom d'hôte temporaire fourni par le système.
  3. Préparez une clé SSH publique si le service la requiert.
  4. Vérifiez l'espace de stockage et les ressources en fonction de l'application que vous allez exécuter.

Ne pas envoyer d'informations confidentielles

Si vous n'êtes pas sûr qu'une information soit confidentielle, demandez plutôt sans l'envoyer. Ne partagez pas de clés privées, de mots de passe, de jetons, de bases de données exportées ou de fichiers de configuration complets dans le chat ou la commande.

> Modification du processeur, de la mémoire vive, du disque ou de la période de rétention après commande

Modifiez le service existant via ses détails, et non en créant une nouvelle commande. Tout changement de ressource peut entraîner une modification du prix, du coût du service, de la consommation quotidienne de crédit, nécessiter un redémarrage et présenter un risque d'interruption de service.

faq/change-service-resources-after-order

Vous modifiez un service existant

Si le service est déjà en cours d'exécution, modifiez ses ressources depuis sa page de détails. Une nouvelle commande créerait un autre service au lieu de modifier celui existant et peut entraîner des modifications du prix, de la consommation quotidienne de crédits et du comportement opérationnel après confirmation, paiement et application de la modification.

Avant de confirmer

  1. Consultez l'utilisation actuelle du CPU, de la RAM, du disque, des sauvegardes et la période de rétention de l'archivage hors site.
  2. Vérifiez le nouveau prix journalier et son impact sur votre crédit.
  3. Lisez les notifications concernant les redémarrages, la maintenance ou les interruptions de service.
  4. Effectuez une sauvegarde des données importantes avant tout changement risqué.

Que faire si la modification ne se déroule pas comme prévu

Veuillez indiquer le nom du service, l'heure de la modification, l'état visible et le message d'erreur. Ne communiquez pas les clés privées, les mots de passe ou les jetons ; pour le diagnostic, un contexte public et une capture d'écran masquée suffisent.

> Annulation du service et période de conservation des données

Le service provisionné est d'abord suspendu, puis une période visible et configurable de conservation est affichée avant que la suppression définitive ne puisse avoir lieu.

faq/cancel-service-and-data-retention

L'annulation ne supprime pas immédiatement tous les services

Pour un service déjà provisionné, le service est d'abord suspendu et une échéance de suppression configurable s'affiche, ce qui permet de décider d'une restauration ou d'un export. Les commandes impayées en attente sans données actives peuvent avoir un comportement différent, et la suppression définitive ne se produit qu'après l'expiration du délai de cycle de vie.

Vérifiez avant d'annuler

  1. Créez votre propre exportation des données que vous souhaitez conserver à long terme.
  2. Consultez la date et l'heure de suppression prévues pour un service suspendu.
  3. N'oubliez pas que les sauvegardes et l'archivage hors site sont distincts de la suppression liée au cycle de vie du service.
  4. Si vous n'êtes pas sûr, contactez le support avant la date limite de suppression.

La restauration après la date limite peut ne pas être possible.

Après l'expiration du délai visible, ne considérez plus les données comme disponibles. Pour toute question, veuillez indiquer le numéro de commande et le nom du service, et non les exports de base de données ni les informations d'identification.

> Sauvegardes et demandes de restauration

Les sauvegardes servent à la récupération opérationnelle, et ne remplacent pas l'export. La restauration peut écraser des données plus récentes.

faq/backups-and-restore-requests

La sauvegarde n'est ni une archive ni un export

La durée de conservation des sauvegardes dépend du produit et des options sélectionnées. La sauvegarde permet la restauration en cas d'incident, mais ne remplace pas une exportation propre, une archive d'audit ou une archive hors site. Une restauration peut écraser les modifications récentes.

Comment préparer une demande de restauration

  1. Indiquez le nom du service et le numéro de commande.
  2. Décrivez la date et l'heure auxquelles vous souhaitez revenir.
  3. Précisez si vous souhaitez restaurer l'intégralité du service ou une partie spécifique, le cas échéant.
  4. Veuillez inclure une erreur visible ou le contexte, sans mots de passe, clés privées ni jetons.

Anticipez les conséquences avant la restauration

Si le service a reçu de nouvelles données entre-temps, la restauration peut remplacer ces données par un état antérieur. Avant de confirmer la restauration, veuillez informer l'équipe et exporter les données que vous ne souhaitez pas perdre.

> À quoi sert Offsite Archive

Offsite Archive conserve des copies d'archives distantes, séparées des sauvegardes opérationnelles à court terme et du cycle de vie du service.

faq/offsite-archive-purpose

Archive hors exploitation courante

Offsite Archive est conçu pour les copies d'archive distantes et le stockage à long terme. Ce n'est pas un disque en direct pour l'application, ni un remplacement de l'export local, ni la même chose que des sauvegardes opérationnelles courtes.

Quand l'activer

  1. Utilisez-le pour les données que vous souhaitez conserver en dehors du fonctionnement normal du service.
  2. Choisissez le nombre de jours de rétention en fonction des exigences de conformité, des besoins commerciaux ou des objectifs de récupération.
  3. Surveillez l'augmentation des coûts en fonction du volume stocké et de la durée de conservation.
  4. Pour les grands volumes de données, planifiez l'archivage conjointement avec votre propre processus d'exportation.

Comment comprendre les prix

La base est le nombre de MB multiplié par le nombre de jours de conservation. Le tarif affiché au client est en EUR/Go/mois et le résultat est arrondi au centime.

> Sélection du processeur, de la mémoire vive et du disque pour un VPS

Choisissez la taille de votre VPS en fonction de l'application, de la base de données, du cache, des journaux et de la croissance prévue. Le dépassement de capacité (OOM) ou l'utilisation excessive de la mémoire virtuelle indiquent souvent qu'il faut plus de RAM.

faq/vps-cpu-ram-and-disk-sizing

Commencez en fonction de la charge réelle, pas d'une estimation

Un petit site web statique a des besoins différents d'une base de données, d'une application Java, d'un moteur de recherche ou d'un conteneur de build. Lors de la planification, tenez compte de la mémoire applicative, du cache, de la base de données, des journaux, des téléchargements et de la marge de croissance.

Signes indiquant que le plan est trop petit

  1. Augmentez la RAM en cas d'erreur OOM (Out Of Memory), de terminaison de processus ou de swap excessif.
  2. Augmentez le CPU en cas de charge de calcul soutenue, de compression, de compilation ou d'activité intense des workers.
  3. Augmentez la taille du disque avant que le système de fichiers, les journaux ou la base de données ne soient saturés.
  4. Après chaque modification, vérifiez si l'application a réellement cessé d'atteindre la limite initiale.

Que devez-vous indiquer lorsque vous posez une question concernant les ressources nécessaires ?

Indiquez le nom du service, le type d'application, l'erreur visible, l'heure approximative et les ressources CPU, RAM et disque actuellement utilisées. Ne transmettez pas de mots de passe, de clés privées ni de fichiers de configuration internes.

> Quand une adresse IP publique a-t-elle un sens pour un VPS ?

Une adresse IP publique dédiée peut être utile pour les listes blanches, l'accès entrant, une source de sortie stable ou les services associés à une adresse.

faq/vps-public-ip-options

Déterminez d'abord le sens de la communication

Une adresse IP publique n'est pas automatiquement nécessaire pour chaque service. Elle répond généralement aux exigences des partenaires, des fournisseurs ou des pare-feu : liste blanche, source sortante stable ou accès entrant sur un port spécifique.

Questions à poser avant de commander une adresse IP

  1. Demandez au partenaire s'il doit autoriser le trafic entrant, sortant ou les deux sens.
  2. Utilisez des noms DNS plutôt que des adresses IP numériques lorsque le système externe le permet.
  3. Ouvrez uniquement les ports dont l'application a réellement besoin.
  4. Veuillez envoyer votre demande d'ajout dans la liste blanche au support technique avant de modifier les paramètres d'accès en production.

Ce qu'il faut laisser fermé

Une adresse IP publique ne signifie pas l'ouverture de tous les ports. Configurez l'accès uniquement pour les services essentiels et n'envoyez pas de mots de passe, de clés privées ni de règles de pare-feu internes sous forme de captures d'écran contenant des informations sensibles.

> Accès SSH partagé pour VPS

Sans adresse IP publique, le VPS se connecte via un point d'accès SSH partagé utilisant un port élevé. Avec une adresse IP publique, un accès SSH direct est également disponible à cette adresse.

faq/shared-ssh-access-for-vps

Pourquoi l'accès SSH partagé utilise-t-il un port élevé ?

Plusieurs services VPS peuvent partager le même point d'accès SSH public, c'est pourquoi chaque service reçoit son propre port élevé. Ce port fait partie du routage vers votre service ; sans lui, la connexion ne pourrait pas être acheminée de manière unique vers le bon serveur VPS.

Comment se connecter en fonction du type d'accès

  1. Pour le SSH partagé, copiez depuis le service le nom d'utilisateur SSH, l'hôte public et le port élevé.
  2. Utilisez la commande ssh -p <port> <username>@<public-host>.
  3. Si le service dispose d'une adresse IP publique, il peut également avoir un second point de terminaison SSH directement sur cette adresse IP ou son nom DNS.
  4. Utilisez la clé privée uniquement localement via votre client SSH ou agent ; fournissez au support uniquement l'hôte public, le port, le nom d'utilisateur et l'erreur visible.

Lorsque vous avez une adresse IP publique supplémentaire

L'adresse IP publique ne remplace pas le point de terminaison SSH partagé ; elle ajoute un moyen d'accès distinct adapté aux listes blanches, à la surveillance ou aux connexions directes. Vous pouvez donc voir deux types de connexions SSH : un hôte partagé avec un port élevé et un hôte ou une adresse IP directe pour le service.

> Vérification avant la connexion de votre propre domaine

Avant de passer à un autre domaine, vérifiez les serveurs DNS autoritaires, le nom d'hôte exact, le type d'enregistrement (domaine principal ou sous-domaine) et l'absence d'anciens enregistrements conflictuels.

faq/custom-domain-readiness-checklist

L'hostname exact est important

Déterminez d'abord si vous connectez un domaine principal (apex) comme example.com ou un sous-domaine comme app.example.com. Chaque option peut nécessiter un type d'enregistrement DNS différent, ainsi que tenir compte des limitations du fournisseur DNS.

Avant de modifier les paramètres DNS

  1. Vérifiez où les enregistrements DNS autoritaires du domaine sont modifiés.
  2. Supprimez ou modifiez les enregistrements A/AAAA, CNAME, ALIAS, ANAME ou de redirection conflictuels.
  3. Utilisez le type d'enregistrement recommandé pour le service et le nom d'hôte.
  4. Après avoir effectué les modifications, attendez que la propagation DNS soit terminée avant de tester la configuration HTTPS finale.

Restaurer en toute sécurité

Ne désactivez pas l'hébergement précédent tant que le nouveau nom d'hôte ne répond pas correctement. En cas de problème, veuillez fournir le domaine, la cible attendue et les résultats DNS visibles, mais pas les informations d'identification du registraire.

> Types d'enregistrements DNS pour les services

Les enregistrements A/AAAA pointent vers des adresses, CNAME vers un alias, MX vers le courrier électronique et TXT vers des vérifications, SPF, DKIM ou DMARC.

faq/dns-record-types-for-services

Ne pas mélanger les enregistrements au hasard

Chaque type d'enregistrement DNS a un rôle différent. Les enregistrements A et AAAA pointent vers des adresses IP, CNAME crée un alias pour un sous-domaine, MX dirige le courrier électronique, TXT contient des informations de vérification et des politiques de messagerie, et CAA limite les autorités de certification.

Lors de la copie des enregistrements

  1. Copiez le nom, le type et la valeur exactement selon les instructions du service.
  2. N'utilisez pas CNAME pour un nom d'hôte qui possède déjà d'autres enregistrements si les règles DNS l'interdisent.
  3. Placez DKIM sous le sélecteur du fournisseur et DMARC généralement sous _dmarc.
  4. Configurez CAA avec soin, car une valeur incorrecte peut empêcher l'émission du certificat.

Que faire lorsque le DNS ne fonctionne pas

Veuillez communiquer au support le nom d'hôte, le type d'enregistrement, la valeur attendue et le résultat visible publiquement. Ne communiquez pas les identifiants de connexion à l'administration DNS ni les captures d'écran contenant des informations sensibles.

> Propagation DNS et TTL : sans engagement quant au temps

Le TTL (Time To Live) détermine la durée pendant laquelle les résolveurs peuvent conserver une ancienne réponse. Pendant la phase de propagation, d'anciennes et de nouvelles réponses peuvent coexister.

faq/dns-propagation-and-ttl

La propagation DNS : un mécanisme de cache, pas de magie

Dans le système DNS, il n'existe aucune garantie précise concernant le temps de propagation. Après une modification du serveur DNS autoritaire, différents résolveurs peuvent encore renvoyer des réponses anciennes et nouvelles jusqu'à ce que leur cache expire, conformément à la valeur TTL (Time To Live). Par conséquent, les résultats peuvent varier en fonction des réseaux, des pays ou des résolveurs DNS utilisés.

Lors d'un changement planifié

  1. Si le fournisseur le permet, réduisez la durée de vie (TTL) avant tout changement prévu.
  2. Après avoir modifié les enregistrements DNS, évitez de faire des modifications répétées tant que les caches n'ont pas expiré.
  3. Testez à partir de plusieurs résolveurs si les résultats sont différents.
  4. Notez l'heure du changement, la valeur précédente, la nouvelle valeur et le TTL.

Que signaler lors du diagnostic

Indiquez le nom d'hôte, le résultat attendu, l'ancienne réponse visible, la nouvelle réponse visible, le TTL et l'heure du changement. Ne communiquez pas les informations de connexion au compte DNS ni les notes internes du fournisseur.

> Planification du stockage pour Workspace Suite

Lors de la planification de la capacité, tenez compte des fichiers utilisateur, des dossiers partagés, des versions, de la corbeille, des miniatures, de la surcharge de synchronisation et de la croissance de l'équipe.

faq/nextcloud-storage-planning

Workspace Suite évolue au-delà des fichiers visibles

L'espace de stockage est utilisé par les fichiers utilisateurs, les dossiers partagés, les fichiers supprimés, l'historique des versions, les aperçus, les miniatures, les clients de synchronisation et les importations. Lorsque le stockage approche de sa limite, les téléchargements ou la synchronisation peuvent échouer.

Avant de commander la capacité

  1. Additionnez les données actuelles des utilisateurs et les dossiers partagés.
  2. Prévoyez de l'espace pour les fichiers supprimés, l'historique des versions, les aperçus et la synchronisation.
  3. Tenez compte des gros imports, des nouvelles équipes et de la croissance prévue.
  4. Augmentez la capacité avant que les utilisateurs ne rencontrent des limitations.

En cas de problème de synchronisation

Veuillez indiquer la taille du service, l'utilisation approximative, l'heure du problème et l'erreur visible côté client. Ne transmettez pas de fichiers personnels, de mots de passe ni d'exports de données utilisateur, sauf demande explicite de l'assistance via un moyen sécurisé.

> Migration des dépôts vers Gitea

Planifiez la migration de vos dépôts Git, en incluant LFS, les sous-modules, les permissions, les clés de déploiement, les webhooks et l'intégration continue/déploiement continu (CI/CD).

faq/gitea-repository-migration

La migration ne se limite pas à un simple `git clone`

Outre l'historique du dépôt, il est nécessaire de transférer ou de recréer les propriétaires, les équipes, les branches protégées, les balises protégées, Git LFS, les sous-modules, les clés de déploiement, les webhooks et les intégrations CI/CD.

Vérification avant la transition

  1. Listez les dépôts, les propriétaires, les groupes d'accès et les comptes d'automatisation.
  2. Vérifiez les objets Git LFS, les sous-modules, les protections de branche et les protections de balises.
  3. Après le transfert, testez les opérations de clonage, de push, Git LFS, les sous-modules et l'exécution des pipelines CI.
  4. Supprimez ou invalidez les anciens jetons après la migration, sans partager leurs valeurs.

Données sensibles lors de la migration

Ne transmettez pas de jetons, de clés privées, de parties privées des clés de déploiement ni de secrets CI. Indiquez plutôt les noms des dépôts, le type d'intégration, l'erreur visible et les informations sur ce qui fonctionnait avant la migration.

> Domaine d'expédition pour Listmonk

Pour vos campagnes, configurez un domaine ou un sous-domaine expéditeur, ainsi que l'identité "From", les enregistrements SPF, DKIM, DMARC, la gestion des messages de rebond et les options de désinscription.

faq/listmonk-sender-domain-basics

La délivrabilité commence avec le domaine

Listmonk nécessite une identité "From" claire et des enregistrements DNS que les systèmes de messagerie peuvent vérifier. SPF, DKIM et DMARC doivent correspondre au domaine ou sous-domaine à partir duquel vous souhaitez envoyer vos campagnes.

Avant votre première campagne

  1. Choisissez un domaine ou sous-domaine pour l'envoi et définissez l'identité de l'expéditeur (From).
  2. Ajoutez les enregistrements DNS de vérification, SPF, le sélecteur DKIM et DMARC demandés par votre fournisseur de messagerie.
  3. Envoyez des messages de test avant une campagne réelle et vérifiez le placement dans le spam, le comportement en cas de rebond, le chemin de retour (Return-Path) et les liens.
  4. Vérifiez les options de désinscription et le paramètre List-Unsubscribe avant d'envoyer la campagne.

Les informations relatives aux e-mails ne doivent pas figurer dans les tickets.

Pour le diagnostic, veuillez fournir le nom de domaine, le type d'enregistrement, la valeur DNS publique et le message d'erreur. Ne communiquez pas les mots de passe SMTP, les clés API privées, les clés DKIM privées ni les exportations de destinataires contenant des données personnelles.

> Paramètres d'exécution pour Classic Hosting

Classic Hosting peut fonctionner en mode d'exécution automatique ou manuel. Le processeur (CPU), la mémoire vive (RAM), le stockage, la rétention des sauvegardes, la rétention de l'archive externe, les téléchargements, le cache et les journaux ont une incidence sur le coût et la stabilité.

faq/classic-hosting-runtime-settings

Le mode automatique n'est pas toujours le meilleur choix

Auto Runtime facilite la gestion des projets reconnus, mais le mode manuel est préférable lorsque vous souhaitez choisir précisément Nginx, Apache, FrankenPHP ou un environnement d'exécution spécifique. Utilisez le sélecteur PHP uniquement là où l'environnement d'exécution choisi le prend en charge.

Paramètres avant le déploiement

  1. Choisissez le mode automatique pour les builds détectés ou le mode manuel pour un contrôle précis de l'environnement d'exécution Nginx, Apache ou FrankenPHP.
  2. Sélectionnez PHP 8.2/8.3/8.4 uniquement lorsque l'environnement d'exécution choisi prend en charge cette option.
  3. Configurez le CPU, la RAM, le stockage, la rétention des sauvegardes et la rétention de l'archive hors site en fonction du trafic et des données.
  4. Après le déploiement, testez les uploads, la mise en cache, les journaux et les erreurs applicatives visibles.

Que faire si l'application ne démarre pas

Veuillez indiquer le mode d'exécution, la langue ou la version de PHP, l'erreur visible, les modifications apportées et l'heure approximative du déploiement. Ne partagez pas les fichiers .env, les mots de passe ni les journaux complets contenant des informations sensibles.

> Quelles informations partager en toute sécurité avec le support

Les informations les plus utiles pour nous aider sont : numéros de commande, noms des services, domaines, heures, serveurs publics, ports, durée de conservation des sauvegardes, durée de conservation de l'Offsite Archive, téléchargements, cache, journaux, captures d'écran et erreurs visibles (sans informations confidentielles).

faq/support-safe-information-to-share

Une demande de qualité contient des informations pertinentes, pas des données confidentielles.

Le support peut répondre plus rapidement lorsqu'il reçoit le numéro de commande, le nom du service, le domaine, l'hôte public ou le port, l'heure du problème, les modifications apportées et un message d'erreur précis.

Contenu sécurisé du message

  1. Indiquez le numéro de commande, le service concerné, le domaine, l'heure approximative et l'hôte ou le port public si pertinent.
  2. Pour les problèmes liés à l'hébergement, veuillez inclure le mode d'exécution, le langage ou la version PHP, le CPU, la RAM, le stockage, la conservation des sauvegardes, la conservation de l'archive hors site, les téléchargements, le cache et les journaux, ainsi que les modifications récentes.
  3. Veuillez découper ou masquer les informations sensibles (mots de passe, jetons, clés privées, sessions, données personnelles) avant d'ajouter des captures d'écran.
  4. Si vous n'êtes pas sûr qu'une information soit pertinente pour le ticket, demandez-la avant de l'envoyer.

Ce qu'il ne faut jamais envoyer

Ne partagez pas de mots de passe, de clés privées, de phrases de récupération, de cookies de session, d'exports de bases de données, de fichiers .env complets, de journaux complets contenant des informations sensibles ni de détails internes sur l'infrastructure.