Référence de l’API par location

Authentification

Quand vous louez un GPU, vous recevez aussitôt une clé API (gpurent_…), affichée sur votre page de location. Envoyez-la comme jeton Bearer à chaque requête :

Authorization: Bearer gpurent_your_key_here

La clé fonctionne exactement aussi longtemps que votre location — quand le temps réglé est écoulé, elle est désactivée automatiquement. L’API accepte les requêtes cross-origin : vous pouvez l’appeler depuis un navigateur, un serveur, un notebook, n’importe où.

Endpoints

URL de base : …/api/v1

Méthode	Chemin	Ce que ça fait
GET	/me	Votre location : modèle de GPU, VRAM, temps restant, état de l’agent.
POST	/jobs	Soumettre une tâche. Corps : {"command": "…", "timeout_s": 300} (délai de 5 à 3600 s, facultatif). Renvoie la tâche avec son id.
GET	/jobs	Lister vos tâches (sans leur sortie).
GET	/jobs/:id	Une tâche, avec tout son output jusqu’ici. Interrogez-la régulièrement tant que son statut est queued/running.
DELETE	/jobs/:id	Annuler une tâche en attente ou en cours.
PUT	/files?path=…	Envoyer un fichier dans l’espace de travail de la location — le corps de la requête contient les octets du fichier.
PUT	/files?path=…&offset=N	Un fichier de n’importe quelle taille, en morceaux de 16 Mo au plus (un envoi transporte environ 36 Mo) : offset=0 commence le fichier, et chaque morceau suivant commence à la size donnée par la réponse précédente. Un morceau qui ne commence pas là où le fichier s’arrête reçoit 409 avec la vraie size du fichier — reprenez à partir de là.
GET	/files?path=…	Télécharger un fichier depuis l’espace de travail de la location — un seul fichier (pas un dossier), jusqu’à 2 Go, envoyé avec sa taille. Sortez les fichiers plus gros de la machine depuis une tâche, vers votre propre stockage.

Les erreurs sont renvoyées en JSON : {"error": "human readable message"}, avec le statut HTTP approprié. Limite de débit : 120 requêtes/min par location.

Cycle de vie d’une tâche

• queued — acceptée, en attente que l’application RentGPUPower de l’hôte la prenne en charge (en général < 3 secondes).
• running — en cours d’exécution sur la machine de l’hôte. output s’allonge à mesure que la commande affiche du texte.
• succeeded — terminée avec le code 0.
• failed — code de sortie non nul, délai dépassé, ou la machine de l’hôte n’a pas pu l’exécuter (voir error).
• cancelled — vous l’avez annulée.
• expired — la location s’est terminée avant l’exécution de la tâche.

Les commandes s’exécutent avec sh dans le bac à sable de la location — un conteneur Linux sur la machine de l’hôte — en partant de /workspace. (Une annonce marquée ⚙ direct a son bac à sable désactivé : elles y tournent directement sur la machine de l’hôte.) La sortie (stdout+stderr) est plafonnée à 512 Ko par tâche.

Exemples

curl

# submit
curl -X POST /api/v1/jobs \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{"command": "nvidia-smi"}'

# poll (replace 42 with the job id you got back)
curl /api/v1/jobs/42 -H "Authorization: Bearer $KEY"

Python

import requests, time

API = "/api/v1"
H = {"Authorization": "Bearer " + KEY}

job = requests.post(f"{API}/jobs", json={"command": "python train.py"}, headers=H).json()["job"]
while job["status"] in ("queued", "running"):
    time.sleep(2)
    job = requests.get(f"{API}/jobs/{job['id']}", headers=H).json()["job"]
print(job["status"], job["output"])

JavaScript

const API = "/api/v1";
const H = { Authorization: "Bearer " + KEY, "Content-Type": "application/json" };

let { job } = await (await fetch(`${API}/jobs`, {
  method: "POST", headers: H, body: JSON.stringify({ command: "nvidia-smi" }),
})).json();

while (["queued", "running"].includes(job.status)) {
  await new Promise(r => setTimeout(r, 2000));
  ({ job } = await (await fetch(`${API}/jobs/${job.id}`, { headers: H })).json());
}
console.log(job.output);

Travailler sur le GPU depuis votre navigateur

Chaque location s’ouvre dans le navigateur — pas de clé SSH à créer, pas de port à rediriger, rien à installer. La machine de l’hôte n’ouvre jamais de port entrant : votre navigateur parle à RentGPUPower, et l’agent de l’hôte récupère le trafic par sa propre connexion sortante.

• Terminal — un vrai shell interactif dans le bac à sable de la location.
• Notebook / application — ce que lance votre environnement (JupyterLab, un serveur d’inférence), sur le même lien.
• Fichiers — parcourez l’espace de travail, envoyez et téléchargez des fichiers, ou récupérez un jeu de données directement depuis une URL.

Clusters : plusieurs machines, un réseau privé

Un cluster, ce sont plusieurs machines d’un même hôte, louées ensemble en une seule étape depuis sa page (la place de marché les liste). Chaque machine est une location ordinaire — son propre espace de travail, sa clé d’API et son règlement à la seconde — et /rental-group/<id> lance une commande sur toutes, ajoute du temps à toutes, ou les arrête ensemble.

Quand la page du cluster l’indique, leurs espaces de travail partagent un réseau privé : chaque machine est node1, node2, … dans le 10.77.N.0/24 propre à son cluster, dans /etc/hosts ; chacune trouve son nom dans /etc/gpurent-node et la liste complète dans /etc/gpurent-cluster. Il passe en WireGuard par le serveur de RentGPUPower, et fonctionne donc quel que soit le réseau de chaque hôte — adapté pour coordonner le travail et échanger des volumes de données modérés (jusqu’à l’allocation affichée sur la page du cluster), pas pour échanger des gradients à la vitesse d’un centre de données.

Chaque machine connaît aussi sa place dans ses shells : NODE_RANK (0 sur node1), NUM_NODES, MASTER_ADDR (node1) et MASTER_PORT (29500) — les noms que lisent PyTorch, Lightning et la plupart des lanceurs — et NCCL et Gloo sont dirigés vers le lien du cluster (NCCL_SOCKET_IFNAME=wg0). Une seule commande, la même sur chaque machine et lancée sur toutes à la fois depuis la page du cluster, démarre donc un travail PyTorch sur toutes ; mettez-la en arrière-plan pour tout ce qui dure plus de quelques minutes.

# PyTorch across the machines — the same command on every machine
nohup torchrun --nnodes=$NUM_NODES --node-rank=$NODE_RANK \
  --master-addr=$MASTER_ADDR --master-port=$MASTER_PORT \
  --nproc-per-node=gpu train.py > train.log 2>&1 &

# Ray: on node1, then on every other machine
ray start --head --port=6379
ray start --address=node1:6379

Modèles d’IA sur des appareils

Certaines annonces ne sont pas une machine mais un modèle d’IA, servi depuis un appareil du réseau de son hôte — un Mac qui fait tourner Ollama ou LM Studio, un PC dont seule une telle application sait utiliser la carte graphique, une console de jeu qui fait tourner un serveur de modèle. La place de marché les montre comme 🧠 modèle d’IA, avec le nom du modèle, la vitesse mesurée par l’application de l’hôte et son contexte, et vous les louez comme modèle : une discussion sur la page de la location, et une adresse compatible OpenAI pour votre propre code.

• L’adresse est sur la page de la location : son URL de base, le modèle, et la clé propre à la location (gpurent_…) comme clé API. N’importe quel client ou bibliothèque OpenAI fonctionne avec.
• Trois appels, rien d’autre : GET /v1/models, POST /v1/chat/completions et POST /v1/completions, streaming compris. Tout autre chemin est refusé avant d’atteindre l’appareil, et une telle location n’a ni terminal, ni fichiers, ni tâches, ni SSH.
• Son modèle est fixe : quel que soit le modèle qu’une requête nomme, c’est celui de l’appareil qui répond, avec une seule réponse par appel.
• La facturation est celle de toute location : à la seconde, gardée en séquestre, versée à l’hôte seulement pour le temps où le modèle répond vraiment. Un appareil qui cesse de répondre quitte aussitôt la place de marché, et le temps qu’il n’a pas fourni vous revient.
• Confidentialité : ce que vous envoyez est traité sur l’appareil de l’hôte, par un serveur de modèle que son propriétaire fait tourner. N’y mettez ni mots de passe, ni clés, ni données privées.

Depuis la Compute API, avec une clé de compte (gpuapi_…) : GET /api/v1/compute/models liste les modèles que servent les appareils libres, et un POST /api/v1/compute/chat/completions qui en nomme un loue l’appareil libre le moins cher qui le sert — une demi-heure réservée, payée à la seconde sur vos crédits — et répond à ce même appel. Son en-tête X-RentGPUPower-Instance nomme l’instance : les appels suivants l’utilisent, et DELETE /api/v1/compute/instances/ID l’arrête.

from openai import OpenAI

client = OpenAI(base_url="/api/v1/compute", api_key="gpuapi_…")
reply = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Hello!"}],
)
print(reply.choices[0].message.content)

Pour les hôtes de GPU

Le plus simple — l’application RentGPUPower. Téléchargez l’application (une ligne à coller) et connectez-vous avec votre compte RentGPUPower : elle détecte votre GPU, crée votre annonce et vous met en ligne en un clic. Par défaut, elle exécute les tâches des locataires dans un bac à sable Docker isolé, pour que personne ne puisse toucher à votre machine. Ni jeton, ni terminal.

Hôtes Linux : le bac à sable en une commande

Sous Linux, l’installateur met en place le bac à sable pour vous, à sa troisième étape — Docker Engine (le Docker gratuit et open source, pas Docker Desktop), le service activé au démarrage, l’autorisation pour votre utilisateur de s’en servir (le groupe docker), et le NVIDIA Container Toolkit s’il y a une carte NVIDIA. sudo vous demande votre mot de passe une fois. Si vous en avez de nouveau besoin — un nouvel utilisateur, un Docker réinstallé, le panneau de contrôle qui indique que c’est le bac à sable qui manque — c’est cette seule ligne (curl ou wget, selon ce que la machine possède), et elle ne fait que ce qui manque encore :

(curl -fsSL /setup-docker.sh || wget -qO- /setup-docker.sh) | sh

Fonctionne sur Debian, Ubuntu et les systèmes qui en dérivent (Linux Mint, Pop!_OS, Raspberry Pi OS), Fedora, RHEL et ses clones (Rocky, Alma, Oracle Linux), Amazon Linux, SLES et openSUSE, Arch et Alpine. Une machine qui utilise Podman à la place (Fedora Silverblue, Bazzite, RHEL avec podman-docker) est utilisée telle quelle — RentGPUPower fonctionne avec Podman, et une carte NVIDIA lui est confiée via CDI. Un Docker installé depuis le Snap Store et un Docker rootless sont démarrés comme il le faut ; sous NixOS, il vous indique plutôt la ligne de configuration. Une machine sans session de bureau (un serveur en SSH) affiche le tunnel qui mène au panneau de contrôle : ssh -L 4091:127.0.0.1:4091 you@that-machine, puis ouvrez le lien que RentGPUPower y a affiché (http://localhost:4091/?k=… — le k est la clé du panneau, qui en interdit l’accès aux autres comptes de cette machine ; relancez RentGPUPower pour l’afficher de nouveau). Les cartes AMD n’ont besoin de rien d’autre que Docker (ROCm donne aux conteneurs les nœuds de périphérique du pilote du noyau), et une machine sans GPU se propose comme unité CPU, sans rien de plus.

Hôtes Windows et macOS : Docker Desktop

Sous Windows et macOS, le bac à sable, c’est Docker Desktop. S’il est installé mais pas lancé — l’état habituel d’un PC à la maison — l’application RentGPUPower le démarre pour vous : appuyez sur Passer en ligne et votre GPU passe en ligne de lui-même dès que Docker est prêt, en général en moins de 60 secondes, sans rien d’autre à cliquer. S’il n’est pas installé, le panneau de contrôle l’installe pour vous : Installer Docker pour moi télécharge Docker Desktop depuis docker.com, vérifie qu’il est signé par Docker, puis l’installe — Windows vous demande votre autorisation une fois (et peut demander un redémarrage, après lequel RentGPUPower s’ouvre de lui-même et continue) ; un Mac demande son mot de passe une fois. Le téléchargement et l’installation en une ligne (winget install -e --id Docker.DockerDesktop sous Windows, brew install --cask docker sur Mac) fonctionnent aussi. Une fois Docker Desktop installé, son propre réglage « démarrer à l’ouverture de session » permet de proposer votre machine dès le démarrage, sans intervention.

Un Mac, une machine avec une puce graphique Intel ou une carte AMD que ROCm ne voit pas ne peut pas encore proposer sa partie graphique à la location — mais l’application RentGPUPower propose alors son processeur comme unité CPU (Ollama et PyTorch sur les cœurs, au prix des cœurs), dans le même bac à sable. Rien n’est refusé tant qu’il y a quelque chose à proposer.

Tout passe par l’application. L’agent qui exécute le travail des locataires fait partie de l’application RentGPUPower : l’application l’installe, en lance un par carte, le tient à jour et lui transmet vos réglages (le bac à sable, l’isolement de votre réseau domestique, le mode machine entière). Il n’est pas proposé en téléchargement séparé.

L’agent interroge la place de marché en HTTPS classique — aucun port entrant, et cela fonctionne derrière un NAT et une box. S’il s’arrête, votre annonce apparaît hors ligne en moins de 90 secondes et ne peut plus être louée. Une location active ne se met pas en pause : le compteur du locataire continue de tourner, ce temps compte comme non fourni, donc vous n’êtes pas rémunéré pour lui, et après une demi-heure de panne continue la location s’annule automatiquement et le reste est remboursé au locataire.

Machines sans aucun GPU

Un ordinateur sans carte graphique utilisable peut quand même être loué — pour ce qu’il est. L’application (ou l’agent) détecte le processeur comme unité de calcul, l’annonce s’étiquette d’elle-même (« … — CPU only ») avec la RAM de la machine comme mémoire, et on ne propose aux locataires que les environnements qui tournent vraiment sur des cœurs : PyTorch, TensorFlow et Ollama, Ollama par défaut. Les environnements réservés au GPU (comme vLLM) sont refusés au moment du paiement plutôt que vendus puis voués à l’échec. Le prix vient du nombre de cœurs et reflète honnêtement la lenteur du calcul sur processeur — en général quelques centimes de dollar de l’heure.

Cartes AMD (ROCm)

AMD est pris en charge, à trois conditions qui sont vérifiées plutôt que supposées :

• Linux. ROCm donne au conteneur les nœuds de périphérique du pilote du noyau (/dev/kfd, /dev/dri), et il n’existe pas d’équivalent sous Windows ou macOS.
• Une installation ROCm qui fonctionne — l’agent cherche ces nœuds de périphérique et rocm-smi au démarrage, et indique à la place de marché s’il les a trouvés. Tant que ce n’est pas le cas, l’annonce ne peut pas être louée et dit exactement ce qui manque. Avoir une image ROCm dans notre catalogue ne veut pas dire que votre machine peut la faire tourner.
• Les environnements conçus pour AMD. Un hôte AMD se voit proposer les environnements ROCm (PyTorch sur AMD, Ollama sur AMD) et pas ceux pour CUDA — ces images n’existent pas pour votre carte, et les proposer ne produirait qu’une location vouée à l’échec.

L’application RentGPUPower propose aussi les cartes AMD — elle interroge rocm-smi comme elle interroge nvidia-smi : sous Linux avec ROCm installé, la carte apparaît dans l’onglet « Cet ordinateur » et passe en ligne en un clic, bac à sable compris. Si rocm-smi manque, l’application le signale, et dit quoi installer. La mise en place du bac à sable en une ligne vaut aussi pour les hôtes AMD : Docker Engine et le groupe docker suffisent, et elle sait qu’une carte AMD n’a besoin d’aucun runtime de conteneur supplémentaire.

Un modèle d’IA sur n’importe quel appareil

Ce que le bac à sable ne peut pas louer — la puce graphique d’un Mac, une carte AMD ou Intel sous Windows, une console de jeu — peut quand même rapporter, comme le modèle qu’il fait tourner. Lancez sur cet appareil une application qui sert une API compatible OpenAI (Ollama, LM Studio, le serveur de llama.cpp, vLLM, PS5LM) avec son modèle chargé. Puis, dans l’application RentGPUPower, ouvrez Appareils d’IA sur votre réseau → Ajouter un appareil d’IA : tapez son adresse (cet ordinateur, ou un autre appareil de votre réseau), sa clé API s’il en demande une, et appuyez sur Vérifier — l’application lit le modèle, le serveur et son contexte, et mesure sa vitesse. Ajouter et passer en ligne le met en location.

• Votre réseau reste fermé. L’application n’envoie à l’appareil que les trois appels de modèle ci-dessus, avec son modèle imposé, et seulement à une adresse de votre propre réseau : une adresse publique est refusée, et un nom est résolu à nouveau avant chaque usage. Les locataires n’ont ni shell, ni fichiers, ni rien d’autre sur l’appareil, et rien n’atteint vos autres appareils.
• Gardez-le allumé. L’application interroge l’appareil toutes les quelques secondes. S’il cesse de répondre, ou sert un autre modèle, l’annonce quitte la place de marché jusqu’à son retour, et les locataires récupèrent le temps qu’il n’a pas fourni.
• Un prix selon ce qu’il fait. Le prix suggéré vient de la taille du modèle et de la vitesse mesurée par l’application — en général quelques centimes de l’heure ; changez-le sur la page de l’annonce. Quand personne ne le loue, il gagne aussi avec la Compute API, qui le loue par son modèle.

Utilisez votre propre appareil, et des logiciels que vous avez le droit d’y faire tourner.

Vérification du matériel

Chaque annonce est vérifiée par rapport à ce que signale l’application de l’hôte avant de pouvoir être louée :

• Quand l’application RentGPUPower de l’hôte se connecte, elle déclare le GPU que nvidia-smi détecte réellement (modèle, VRAM, pilote, UUID du GPU).
• La place de marché le compare au modèle annoncé. Les noms sont normalisés (« NVIDIA GeForce RTX 4090 » = « RTX 4090 ») et la VRAM doit couvrir ce que promet l’annonce.
• ✔ vérifié — le matériel correspond ; l’annonce peut être louée.
• ✖ non conforme — la machine déclare un autre GPU (ou aucun). La location est bloquée jusqu’à ce que le propriétaire corrige l’annonce ou déplace l’agent sur la bonne machine. Revérifié à chaque reconnexion.
• ◇ simulé — une carte fictive, qui sert à tester le site, sans aucun matériel réel derrière. Elle ne peut être louée que sur une place de marché de démonstration, jamais sur une place de marché réelle.

Séquestre et remboursements automatiques

Les paiements ne sont jamais remis directement à l’hôte — ils sont conservés sous séquestre et versés pour le service réellement fourni :

• Toutes les ~10 secondes, la place de marché vérifie chaque location active : l’agent donne-t-il signe de vie ? les tâches sont-elles prises en charge ? Le temps ne compte comme fourni que si les deux sont vrais.
• Un hôte qui reste « en ligne » mais ignore les tâches en attente pendant plus de 2 min est considéré comme ne fournissant pas le service (protection anti-blocage).
• À la fin de la location : l’hôte reçoit total × delivered% moins la commission de la plateforme ; le reste est remboursé automatiquement au locataire, sur son solde RentGPUPower. Une location réglée avec le solde remet l’argent exactement comme il était. Ce qu’un paiement par carte, PayPal ou en crypto a réglé revient en crédit : il paie n’importe quelle location mais ne peut pas être retiré — seul l’argent gagné par un travail fait ici se retire (comme hôte, ou par les tâches d’un téléphone pour les clients de l’API là où elles sont proposées), depuis Tableau de bord → Gains. Une location payée qui ne démarre jamais est un cas à part : un paiement par carte revient sur la carte, en entier.
• Si l’hôte est injoignable pendant plus de 2 min, le locataire peut mettre fin à la location plus tôt et récupérer tout le temps non fourni. Après une demi-heure de panne continue, elle s’annule automatiquement.
• Résultat : un hôte qui ne fournit jamais rien gagne 0,00 $US, et « louer » un GPU que vous n’avez pas l’intention de fournir ne rapporte rien — il n’y a aucun versement frauduleux à encaisser.

Réputation : avis et fiabilité

Chaque hôte a un historique public, pour que les locataires puissent choisir en confiance :

• Avis — une fois la location commencée, le locataire peut laisser une note de 1 à 5★ et un commentaire (un par location). Les notes apparaissent sur les cartes des annonces, sur la page de l’annonce et sur votre tableau de bord.
• Fiabilité — calculée automatiquement à partir du décompte de disponibilité du séquestre, et mesurée plutôt que déclarée. Sur les locations terminées d’un hôte, elle fait la moyenne du pourcentage fourni — mais la référence de la mesure dépend de la raison pour laquelle la location s’est terminée. Si l’hôte s’est éteint (ou si le locataire a arrêté parce que l’hôte ne fournissait pas le service — ce que nous jugeons d’après nos propres signaux, pas sur la parole du locataire), elle est mesurée par rapport à toute la réservation : une machine qui lâche au bout de 2 min sur une location de deux heures obtient un score proche de zéro, au lieu de s’abriter derrière ces 2 min. Si le locataire a simplement fini plus tôt, ou si la location s’est arrêtée pour inactivité, elle est mesurée par rapport au temps réellement occupé — un hôte n’est jamais pénalisé pour la décision de quelqu’un d’autre de partir. Les locations de moins de 60 secondes, et celles de l’API Compute, sont exclues pour que de courtes rafales ne noient pas le signal.
• Score de confiance — un mélange de fiabilité (60 %) et de note (40 %), utilisé par le tri Plus haute confiance de la place de marché. Les hôtes sans historique se placent au milieu, pas en tête.
• Favoris — ajoutez n’importe quelle annonce avec le ♥ et retrouvez-la dans Tableau de bord → Favoris, ou filtrez la place de marché sur « Favoris uniquement ».
• Prolonger — ajoutez des heures à une location active depuis sa page ; le temps supplémentaire est placé sous séquestre et décompté exactement comme le temps initial, et votre clé API continue de fonctionner sans interruption.

Modèle de sécurité

• Les locataires exécutent n’importe quelle commande shell sur les machines des hôtes — c’est le produit, sur le même modèle que n’importe quel fournisseur de GPU dans le cloud. L’application RentGPUPower exécute chaque location dans un conteneur Docker par défaut, ce qui tient le code des locataires à l’écart des fichiers de l’hôte ; un hôte peut désactiver cela sur une machine dédiée, et son annonce indique alors ⚙ direct.
• Le badge « 🔒 isolé » est déclaré par l’hôte, pas vérifié par nous. Une annonce l’affiche quand l’agent de cet hôte dit exécuter les tâches dans un conteneur Docker avec accès direct au GPU. Nous ne pouvons pas encore le prouver de l’extérieur — un hôte utilisant un agent modifié pourrait l’affirmer et voir quand même ce que vous exécutez. Considérez toute machine louée comme non fiable pour vos secrets : n’y collez pas de clés API à longue durée de vie ni d’identifiants que vous ne pouvez pas renouveler, et préférez des jetons à courte durée de vie. (L’attestation est prévue ; nous préférons le signaler honnêtement plutôt que de laisser croire à une garantie que nous ne pouvons pas donner.)
• Pour les hôtes : le bac à sable est borné. Le conteneur d’un locataire a un plafond de mémoire sans swap, un plafond de CPU qui laisse un cœur à votre machine, une limite de processus, et un seuil d’espace disque libre en dessous duquel il ne peut pas écrire — ce qu’il exécute est arrêté avant. Les fichiers qu’un locataire télécharge sont lus à l’intérieur du conteneur : un lien placé dans /workspace ne peut donc jamais atteindre un fichier de votre ordinateur.
• Les clés API et les jetons d’hôte sont des secrets aléatoires de 192 bits. Renouvelez un jeton d’hôte à tout moment depuis la page de gestion.
• Les applications qui tournent sur un GPU loué sont considérées comme non fiables. Elles atteignent votre navigateur via le relais, jamais directement, et chacune a son propre lien privé, qui ne s’ouvre que pour le compte qui a loué le GPU. Quand un opérateur a configuré un domaine séparé pour les applications, elles sont servies depuis leur propre origine : leur JavaScript n’a donc aucun accès à votre session RentGPUPower ; sinon, elles tournent sous une CSP de bac à sable qui a le même effet. Dans les deux cas, un hôte ne peut ni définir ni lire votre cookie de session RentGPUPower : sur l’origine de la place de marché, le relais supprime purement et simplement Set-Cookie et les en-têtes de sécurité propres à l’application, et sur un domaine séparé, l’application peut définir des cookies et sa propre CSP pour son seul nom d’hôte — l’attribut Domain= est retiré, si bien que rien de ce qu’elle définit ne peut atteindre RentGPUPower.
• Les écritures venant d’autres sites sont refusées. Toute requête qui modifie quelque chose et qui est authentifiée par votre cookie de connexion doit venir des pages de RentGPUPower ; une requête intersite est rejetée d’emblée plutôt qu’exécutée en silence.
• Aucun JavaScript tiers. Chaque script exécuté par ce site est servi depuis ce domaine — rien n’est chargé depuis un CDN public. Un script chargé depuis le serveur de quelqu’un d’autre s’exécute avec tous les droits de votre session, et sur la page de paiement, ce serait lui qui déciderait où va votre argent. Chaque bibliothèque que nous livrons est épinglée sur une empreinte publiée par npm et revérifiée avant chaque déploiement. La seule exception est Stripe.js, qui doit venir de js.stripe.com pour que vos coordonnées bancaires restent dans le cadre de Stripe et ne touchent jamais ce serveur. Les polices web sont elles aussi hébergées ici : aucune visite de page n’est signalée à un tiers.
• Les tarifs horaires sont bloqués au moment de la location ; un hôte qui change ses prix n’affecte jamais une location déjà réglée.
• Le matériel des annonces est vérifié (voir plus haut) et les paiements sont placés sous séquestre en fonction de la disponibilité fournie — les annonces fictives ou qui ne fournissent rien ne rapportent rien et sont remboursées automatiquement.
• En mode de paiement de démonstration, aucun argent réel ne circule. Avec Stripe configuré, les données de carte ne vont qu’à Stripe — jamais à ce serveur.