Étape 1 — choisir une offre, choisir un emplacement
Le configurateur /deploy/ vous guide à travers le niveau d'offre, le datacenter, l'OS, les options facultatives (IPv4 supplémentaire, disque plus grand). C'est un formulaire progressif en six étapes ; chaque étape apparaît une fois la précédente remplie. Aucun compte n'est requis pour atteindre l'étape de paiement.
Le configurateur ne demande pas d'e-mail avant la toute fin, et même là, c'est l'e-mail auquel vous souhaitez recevoir vos identifiants serveur — il n'est pas utilisé pour la vérification ou le marketing. Vous pouvez utiliser n'importe quel e-mail fonctionnel, y compris des alias (anonaddy, simplelogin, mailtm).
Étape 2 — commande créée, redirection vers /pay/
La soumission du configurateur crée un enregistrement de commande côté serveur, génère un identifiant de commande unique (CS-ORD-XXXXXXXXXX) et vous redirige vers /pay/
Important : votre mot de passe root (si vous en définissez un) n'est jamais persisté de notre côté. Nous hachons un flag de confirmation et oublions le texte en clair. La seule façon de le récupérer est de le définir lors de la première connexion SSH via cloud-init, ce qui est le pattern standard.
Étape 3 — choisir la crypto avec laquelle payer
Vous verrez une liste restreinte de cryptos supportées, filtrée en temps réel selon la liquidité actuelle : BTC, XMR, LTC, ETH, USDT-ERC20, USDT-TRC20, DASH, BCH, DOGE, SOL. La liste s'ajuste en temps réel — les cryptos temporairement désactivées (rare, mais cela arrive en période de congestion) disparaissent.
De notre côté, aucune crypto n'est préférée — payez avec ce que vous détenez. En coulisses, le paiement se règle en Monero ou USDT quel que soit ce que vous avez envoyé, donc votre choix de crypto est purement ergonomique (frais les plus bas : LTC/DOGE ; le plus privé : XMR ; le plus stable : USDT).
Étape 4 — adresse de dépôt à taux bloqué
Choisir une crypto renvoie une adresse de dépôt spécifique à votre commande, plus le montant exact à envoyer et une fenêtre de taux de 30 minutes. Le montant est le prix USD de votre offre converti au taux coté à ce moment ; si vous envoyez moins, le système complète la différence au nouveau taux ; si vous envoyez plus, le surplus est crédité sur votre compte.
30 minutes suffisent pour toute crypto de cette liste — même Bitcoin obtient une confirmation dans cette fenêtre avec des frais à priorité normale. Le système supporte aussi les paiements tardifs : si vous payez 4 heures plus tard à un taux différent, nous créditons quand même correctement, vous devrez peut-être juste compléter un petit delta.
Étape 5 — envoyer le paiement
Envoyez depuis n'importe quel portefeuille. Portefeuilles hardware (Ledger, Trezor), Monero CLI, Sparrow, Electrum, portefeuilles mobiles, retraits d'exchange — tout fonctionne. Nous ne faisons pas de fingerprinting sur l'origine des fonds et ne partageons pas ces données avec quiconque.
Un QR code est fourni pour les portefeuilles mobiles. L'adresse de dépôt est à usage unique par commande — envoyer dessus après la fin de la commande ne créditera pas un nouveau serveur (les fonds retourneront dans le float et vous devrez contacter le support pour les récupérer).
Étape 6 — confirmation et provisioning
Le statut passe par `awaiting → confirming → paid` au fur et à mesure que le réseau confirme votre transaction. Pour la plupart des cryptos : 1–3 confirmations suffisent ; le seuil s'adapte à la valeur déplacée (petites offres = 1 confirmation ; niveaux dédiés = 3). La page /pay/ sonde toutes les quelques secondes ; vous n'avez pas besoin de rafraîchir.
À l'état `paid`, l'orchestrateur récupère la commande dans la file et provisionne le serveur. Le délai médian de bout en bout du paiement confirmé à une connexion SSH fonctionnelle est de 41 secondes pour un VPS, 2–4 heures pour un dédié (car cela implique un racking physique et une configuration IPMI).
Les identifiants arrivent dans l'e-mail que vous avez fourni, chiffrés avec une clé à usage unique liée à l'identifiant de commande. Ils apparaissent aussi dans votre /panel/ si vous avez choisi de créer un compte ; les clients sans compte reçoivent tout par e-mail.
Ce en quoi nous règlons — et pourquoi ça compte
En interne, chaque paiement se règle en Monero ou USDT, quel que soit la crypto envoyée. Le choix dépend de la liquidité et du routage à ce moment ; en pratique ~70 % des commandes se règlent en USDT (saut le moins cher), le reste en Monero (préféré quand l'entrant était déjà routé de manière privée).
Pourquoi ça compte pour vous : cela signifie que nous n'accumulons pas de poussière dans une douzaine de chaînes différentes. Nous détenons notre trésorerie en deux cryptos, avec une comptabilité prévisible et une surface minimale pour l'analyse de chaîne. De votre côté c'est invisible — vous avez envoyé du BTC, le serveur s'est provisionné, et nos livres de comptes affichent ce qu'ils devaient afficher.
Cela signifie aussi : si vous avez envoyé une crypto que nous ne réglons pas directement (LTC, DOGE, DASH, BCH), il y a un petit spread entre ce que vous avez payé et ce que nous avons reçu. Nous absorbons ce spread ; vous êtes facturé au prix USD de l'offre, point.
Modes d'échec et résolution
Sous-paiement (vous avez envoyé légèrement moins que le montant indiqué) : le système affiche un avis de sous-paiement et une adresse de complément. Envoyez le delta, la commande se poursuit.
Sur-paiement (vous avez envoyé plus que le montant indiqué) : le surplus est crédité sur votre compte ; lors du prochain renouvellement il est automatiquement appliqué. Vous pouvez aussi demander un remboursement vers une adresse différente.
Paiement tardif (la fenêtre de taux a expiré) : le système calcule le nouveau montant dans votre crypto au taux actuel et affiche un devis actualisé. Les fonds déjà envoyés sont comptabilisés dans le nouveau total.
Mauvaise crypto envoyée (vous avez utilisé un portefeuille BTC pour payer une facture LTC — ça arrive plus souvent qu'on ne le pense) : contactez le support avec le hash de transaction ; nous récupérons les fonds et les créditons sur une nouvelle commande. Dans le pire cas, 48 heures.
La congestion réseau retarde la confirmation : la commande reste en `confirming` jusqu'à ce que le seuil soit atteint. Nous avons vu Bitcoin prendre 45 minutes en période de congestion maximale ; nous ne faisons pas expirer la commande avant la fin de la fenêtre de taux, puis nous recalculons simplement le devis.