Résumé

  • Un cloud GPU vend trois choses séparables — un accélérateur, une machine hôte qui l'alimente, un chemin réseau qui fait entrer et sortir le travail — et les facture d'un seul chiffre. Le dossier public de Genesis Cloud documente la troisième couche et laisse les deux premières largement illisibles.
  • L'outil de routage de Hurricane Electric enregistre AS209045 au nom de Genesis Cloud Limited, pays d'origine Malte, avec deux préfixes IPv6 annoncés et aucun préfixe IPv4, et des pairs IPv6 observés chez euNetworks et OVH.
  • Un relevé résumé de cette même page, capturé le 18 octobre 2026, indique que l'ASN n'a pas été visible dans la table de routage mondiale depuis le 16 avril 2026. Le dossier ne dit pas pourquoi.
  • La mécanique de facturation du secteur explique l'écart : la capacité est provisionnée à l'instance mais annoncée à l'heure-GPU, la sortie de données est mesurée séparément au volume, et le débit multi-GPU dépend de la topologie d'interconnexion bien plus que du modèle d'accélérateur.

Le chiffre que l'on compare

Toute discussion sur le calcul pour l'intelligence artificielle commence par un chiffre qui ressemble à un prix et se comporte comme un slogan : le dollar par heure-GPU. C'est le chiffre qui figure dans les tableurs d'achat, dans les tableaux comparatifs qui circulent sur les canaux internes, et dans la diapositive qu'une équipe financière prépare lorsqu'elle veut savoir si un programme d'entraînement est finançable.

C'est aussi le chiffre qui répond à la question la moins intéressante de la pièce. Une heure-GPU indique ce que coûte l'occupation d'un accélérateur pendant soixante minutes. Elle n'indique pas ce que coûte votre tâche, parce que votre tâche n'est pas un accélérateur immobile. Votre tâche est une suite d'opérations dans laquelle un accélérateur attend la bande passante mémoire d'un hôte, un chemin de stockage, un saut réseau, et l'interconnexion qui permet à plusieurs accélérateurs de se comporter comme une machine plus grande.

L'unité facturée et l'unité livrée sont deux objets différents, et l'écart entre les deux est précisément là où réside le risque d'achat.

Cet écart est généralement décrit comme une question d'opacité des fournisseurs. Il se comprend mieux comme un problème de couches séparables que l'on présente comme si elles étaient fusionnées. Un cloud GPU ne vend pas un GPU. Il vend un accélérateur, plus un hôte, plus un chemin — et la grille tarifaire est un chiffre unique couvrant les trois, la composition étant laissée à l'imagination de l'acheteur.

Cet article prend le dossier public d'un exploitant et pose une question étroite : laquelle des trois couches peut réellement être vérifiée à partir de documents accessibles à un acheteur, et lesquelles relèvent de la confiance ? L'exploitant est la société inscrite dans l'annuaire de BTW sous le nom Genesis Cloud Routing, Peering and DNS, fournisseur de cloud GPU dont l'identité de routage se révèle bien mieux documentée que le produit de calcul.

Trois couches, trois états de preuve

Séparer les couches n'est pas un procédé rhétorique. Cela change ce qui compte comme preuve.

La couche accélérateur appartient au marketing. Elle se décrit en noms de produits, en tailles de mémoire et en promesses de génération, et c'est la couche que les acheteurs croient comparer. Pour cet exploitant, elle n'a pas pu être lue : la page tarifaire, les conditions de service et les pages d'instances GPU n'ont pas renvoyé de texte exploitable lors des tentatives menées les 17 et 18 octobre 2026. Il reste l'autodescription de la société comme fournisseur d'infrastructure cloud spécialisé dans l'accélération GPU, et une fiche de base de données d'entreprises qui la classe comme organisation privée du marché du cloud GPU. Ni l'une ni l'autre n'établit un catalogue d'accélérateurs.

La couche hôte est celle que presque personne ne documente. Elle couvre l'équilibre entre processeur et GPU, la mémoire système par accélérateur, le débit du stockage local, et la politique d'ordonnancement qui décide si votre instance partage une machine avec un voisin dont la charge sature le même bus mémoire. Ce ne sont pas des informations exotiques ; les grands fournisseurs les publient. Mais c'est la couche où la capacité bon marché devient bon marché, et c'est la couche qu'aucun document public de ce dossier n'aborde.

La couche réseau est celle qui s'est révélée documentée — non parce que l'exploitant l'a publiée, mais parce que le routage Internet est un fait public par construction. Les registres et les outils de routage enregistrent qui détient un numéro de système autonome, quel espace d'adressage il annonce, et avec qui il s'appaire. Ce dossier existe que l'entreprise le veuille ou non, et pour ce sujet c'est la seule couche où un document peut être cité plutôt qu'une affirmation répétée.

Trois couches, donc, dans trois états : proclamée, absente, documentée. La question intéressante n'est pas que les deux premières soient minces. C'est que la troisième le soit d'une manière précise et mesurable — et que cette minceur soit invisible pour qui ne lit que la page produit.

Ce qu'une heure-GPU mesure réellement

La mécanique de facturation du cloud GPU n'est pas secrète. Elle n'est simplement pas résumée sur la grille tarifaire.

La capacité est provisionnée sous forme d'instance — une machine virtuelle disposant d'une part définie d'un hôte physique — alors qu'elle est annoncée et comparée comme un montant par heure-GPU. Les deux unités ne sont pas identiques. Comme l'expose une note explicative du secteur sur la facturation du cloud GPU, les fournisseurs facturent au niveau de l'instance même lorsque les coûts sont calculés et annoncés par heure-GPU, et la granularité de cette facturation varie d'un fournisseur à l'autre, de la seconde à la minute puis à l'heure (note explicative sur la facturation du cloud GPU). La granularité ressemble à un détail comptable jusqu'au moment où l'on enchaîne beaucoup de tâches courtes : un fournisseur qui arrondit à l'heure et un fournisseur qui arrondit à la seconde peuvent différer d'un multiple important sur la même charge, à tarif affiché identique.

La même source relève la deuxième caractéristique structurelle : les tarifs à la demande et les tarifs réservés divergent fortement, et la réservation transforme un coût variable en engagement dont la valeur dépend d'un taux d'utilisation que l'acheteur doit prévoir. C'est une décision de financement déguisée en remise.

La troisième caractéristique est celle qui fait le plus souvent dérailler un budget après coup. La bande passante sortante est fréquemment facturée séparément, mesurée au volume de données quittant le réseau du fournisseur, et pour les charges d'IA à haut débit elle peut modifier sensiblement le coût total de possession. Un prix par heure-GPU ne contient aucune sortie de données. Un point de contrôle de modèle écrit chaque nuit, un jeu de données relu à chaque époque, un corpus d'entraînement répliqué entre régions — chacun ajoute une ligne que la grille tarifaire n'a jamais montrée.

Réunissez ces trois éléments et l'arithmétique d'une tâche achevée ne ressemble plus du tout à l'arithmétique d'une heure d'accélérateur. Le coût par tâche est fonction du temps d'accélérateur, de l'équilibre de l'hôte, du chemin de stockage, de l'efficacité de l'interconnexion, du volume sortant et des clauses d'interruption. Le chiffre annoncé couvre le premier terme et fait signe vers les autres.

La topologie est un terme de performance, pas une spécification

S'il existe un fait technique qui démonte l'idée de l'heure-GPU comme unité de travail, c'est celui-ci : le débit multi-GPU est gouverné par la manière dont les accélérateurs communiquent entre eux.

La documentation technique de NVIDIA est directe sur ce point. NVLink fournit une interconnexion directe à haut débit qui contourne les limites du bus PCIe pour l'accès mémoire de GPU à GPU, et les charges d'entraînement à haut débit s'appuient sur elle pour éviter les goulots de communication lors de la synchronisation des gradients entre plusieurs GPU (NVIDIA sur NVLink et l'efficacité de l'entraînement multi-GPU). Lorsque les accélérateurs sont plutôt reliés en PCIe, l'interconnexion devient la contrainte, et les accélérateurs passent leurs heures facturées à attendre.

Les conseils de facturation du secteur formulent le même point du côté commercial : le débit multi-GPU dépend fortement de la topologie d'interconnexion, NVLink offrant une communication GPU à GPU à haut débit et à faible latence par comparaison avec le PCIe standard, et InfiniBand étant couramment déployé pour la communication rapide entre nœuds dans les grappes de calcul intensif.

Cela compte parce que la topologie d'interconnexion n'est pas une propriété de l'accélérateur. Deux fournisseurs peuvent afficher le même modèle d'accélérateur au même tarif horaire et livrer des débits radicalement différents sur une tâche multi-GPU, parce que l'un a câblé huit dispositifs en une fabrique cohérente et l'autre non. L'acheteur qui compare des dollars par heure-GPU compare une constante à une variable. Ce n'est pas une comparaison de prix ; c'est une erreur de catégorie assortie d'un processus d'achat.

Il existe une conséquence de second ordre qui apparaît rarement dans les comparatifs. La topologie détermine la manière dont une charge se met à l'échelle, et la mise à l'échelle détermine le nombre d'accélérateurs qu'il faut louer pour terminer dans un temps donné. Une configuration mal interconnectée peut consommer davantage d'heures-GPU pour achever le même travail. Le tarif horaire le moins cher coûte alors plus cher par tâche, et la facture qui arrive ressemble à une erreur de prévision plutôt qu'à ce qu'elle est : l'achat de la mauvaise unité.

Ce que dit réellement AS209045

Face à ce brouillard commercial, le dossier de routage est presque étonnamment concret.

L'outil de routage de Hurricane Electric, qui publie les relations entre numéros de système autonome, préfixes et titulaires, enregistre AS209045 au nom de Genesis Cloud Limited, avec un pays d'origine : Malte et deux préfixes annoncés au total (fiche AS209045 dans l'outil de routage de Hurricane Electric). L'extrait verbatim du dossier indique :

AS209045 Genesis Cloud Limited

Country of Origin: Malta

Prefixes Originated (all): 2

AS209045 IPv6 Peers — AS13237 AS16276 — AS16276 OVH SAS, AS13237 euNetworks GmbH

Prefix Description 2a09:7000::/31 Genesis Cloud LIR Admin ; 2a09:7007::/36 Genesis Cloud LIR Admin

Trois faits en découlent directement, et chacun est vérifiable par quiconque dispose d'un navigateur.

Premièrement, le nom du titulaire sur le dossier de routage est un nom de forme juridique — Genesis Cloud Limited — assorti d'une juridiction précise : Malte. C'est un type d'affirmation différent du libellé descriptif sous lequel la société apparaît dans un annuaire. C'est une déclaration d'enregistrement, faite dans un système conçu exactement pour cela.

Deuxièmement, l'espace d'adressage annoncé se compose de deux préfixes IPv6 et de rien d'autre. Aucun préfixe IPv4 n'apparaît dans le dossier. Les deux préfixes portent la description « Genesis Cloud LIR Admin », qui renvoie à une administration de registre Internet local plutôt qu'à une plage de service destinée aux clients.

Troisièmement, les pairs IPv6 observés sont deux opérateurs européens bien connus : euNetworks, fournisseur de fibre et de connectivité de centres de données, et OVH, le groupe français d'hébergement et de cloud. Une observation à deux pairs n'est qu'une tranche étroite d'une table de routage, pas une topologie complète, mais elle apprend à un acheteur quelque chose qu'une grille tarifaire ne dira jamais — que ce chemin réseau s'ancre dans l'infrastructure d'opérateurs et d'hébergeurs européens plutôt que dans un réseau dorsal mondial qui lui serait propre.

Deux préfixes et aucun IPv4

Il vaut la peine de s'arrêter sur la petitesse de cette empreinte, car la taille ici n'est pas une insulte. C'est une mesure.

Un système autonome qui annonce deux préfixes IPv6 et aucun espace IPv4 ne gère pas un large patrimoine d'adresses publiques. Il n'annonce pas des milliers de routes à la table mondiale. C'est un enregistrement étroit, cohérent avec un exploitant qui atteint ses clients par les réseaux d'autrui — les relations de transit et d'appairage faisant le travail qu'une grande empreinte auto-annoncée ferait autrement.

C'est une manière parfaitement ordinaire d'exploiter un cloud. La plupart des fournisseurs n'annoncent pas le trafic de leurs clients comme le leur ; ils achètent du transit et s'appairent aux points d'échange, et leur numéro de système autonome porte du trafic de gestion et de bordure plutôt que la somme de leur activité commerciale. L'erreur serait de lire le numéro de système autonome comme une mesure de l'empreinte de calcul. Il ne l'est pas, et cet article ne le fait pas.

Mais la même observation joue en sens inverse pour l'acheteur. Si le chemin réseau est étroit et largement externalisé vers des relations d'opérateurs, alors les déterminants du coût réseau d'une tâche — où la sortie est facturée, quelles routes sont empruntées, comment le trafic atteint le client — résident dans des conditions commerciales plutôt que dans un dossier de routage public. Le dossier de routage vous dit que le chemin existe et à peu près où il atterrit. Il ne vous dit pas ce que le traverser coûte.

Et c'est précisément l'asymétrie que cet article voulait éprouver. La couche publiquement documentée est celle qui compte le moins dans le prix d'une tâche achevée. Les couches qui dominent le prix — l'équilibre de l'hôte et les conditions de sortie — sont celles qui n'ont aucun document public.

La question du retrait

La ligne la plus lourde de conséquences du dossier est aussi celle qui exige le plus de prudence.

Le relevé résumé de cette même page d'outil, capturé le 18 octobre 2026, indique qu'AS209045 n'a pas été visible dans la table de routage mondiale depuis le 16 avril 2026. C'est une affirmation sur la visibilité, non sur l'intention. Un enregistrement peut subsister alors que les annonces s'arrêtent, et les raisons d'un tel arrêt sont nombreuses et le plus souvent banales : une renumérotation, une migration vers un autre transitaire, un changement de fournisseur, une période de restructuration interne, ou une décision opérationnelle de cesser d'annoncer un espace qui n'est plus utilisé.

Le dossier n'établit laquelle de ces explications s'applique. Ce qu'il établit, c'est la forme de la chose qu'un acheteur ne verrait jamais du côté produit. Une société peut continuer à présenter une offre de cloud GPU pendant que la présence de routage publique associée à son nom de réseau enregistré se tait pendant six mois. Rien là-dedans n'est nécessairement fautif. Mais les deux faits ne sont reliés dans aucun document qu'un acheteur est susceptible de lire, et ce lien est exactement le genre de chose qu'un processus de vérification technique est censé produire.

Cela donne aussi à l'article son illustration la plus claire de la thèse. Le chemin réseau n'est pas un attribut permanent d'un fournisseur ; c'est un état opérationnel vivant qui peut changer sans aucune modification correspondante d'une grille tarifaire, d'une page marketing ou d'une conversation commerciale. Si le modèle de coût d'un acheteur dépend de l'endroit où le trafic atterrit et de la manière dont il y arrive, alors un changement de visibilité d'annonce est un fait significatif — et il apparaît dans un outil de routage, non dans les conditions d'un fournisseur.

Le nom sur la fiche et le nom au registre

La fiche d'annuaire de ce sujet est classée sous un nom descriptif : Genesis Cloud Routing, Peering and DNS. Ce nom est une étiquette utile. Ce n'est pas une identité juridique, et ce n'est pas ce que dit le dossier de routage.

Le dossier de routage dit Genesis Cloud Limited. Les métadonnées de la fiche d'annuaire concèdent elles-mêmes l'écart : son rôle connu est le générique « opérateur d'infrastructure réseau », sa seule base de preuve citée est une consultation RDAP d'autnum pour AS209045, et ses lacunes déclarées listent comme non vérifiés le pays de l'entité juridique, les services actuels, les actifs visibles, les liens de société mère ou de filiale, et les contacts de direction publics responsables. La fiche a été publiée automatiquement.

Une étiquette d'annuaire descriptive et un nom de titulaire au registre sont deux types d'affirmation différents, et l'espace entre les deux est celui où les identités sont supposées plutôt qu'établies. « Genesis Cloud » apparaît dans le dossier de routage, dans la présence web de la société elle-même, et dans une fiche de base de données d'entreprises qui la classe comme organisation privée du marché du cloud GPU (profil Genesis Cloud sur Crunchbase). C'est un ensemble cohérent, et la cohérence n'est pas la confirmation : aucun document obtenu pour cet article n'établit la relation sociale entre l'activité de cloud GPU et le titulaire d'AS209045 au-delà du nom partagé et de la mention d'administration de registre local sur les préfixes.

Pour un article sur la vérifiabilité, cette distinction n'est pas de la pédanterie. C'est tout l'enjeu. La couche qui semblait la plus solide — une société nommée dans un registre — se révèle solide sur un nom et silencieuse sur l'entité commerciale qui le porte. Le produit de calcul, lui, est décrit à la première personne par un site qui n'a pas pu être lu.

Ce qui n'a pas pu être lu, et quand

Une frontière datée est plus utile qu'une impression vague ; la voici donc en entier. Tout ce qui suit a été tenté et a échoué entre le 17 et le 18 octobre 2026.

Le dossier de registre sur lequel repose l'identité de l'annuaire. La consultation RDAP d'autnum pour AS209045, citée par la fiche d'annuaire comme sa seule base de preuve, n'a renvoyé aucun candidat source (la consultation RDAP citée par la fiche d'annuaire). Le texte du registre lui-même — titulaire, pays, identifiants de contact, remarques — n'a donc pas été lu au cours de ce travail. Ce que cet article sait du titulaire de l'ASN vient d'une base de routage tierce, non du registre.

Le produit et les conditions commerciales de l'exploitant. Les tentatives d'accès au site principal, à la page tarifaire, aux conditions de service et aux pages d'instances GPU n'ont pas renvoyé de texte exploitable (site de Genesis Cloud ; le même site en www). Aucun modèle d'accélérateur, aucune configuration mémoire, aucune spécification d'hôte, aucun détail d'interconnexion, aucune granularité de facturation, aucun tarif de sortie, aucun crédit de service et aucune clause d'interruption ne sont établis dans cet article.

Politique d'appairage et présence aux points d'échange. La fiche PeeringDB d'AS209045 était à accès restreint lors de la consultation, de sorte que la politique d'appairage publiée, la présence aux points d'échange, les ratios de trafic et la posture ouverte ou sélective n'ont pas pu être extraits (fiche AS209045 sur PeeringDB).

Corroboration indépendante des faits de routage. La vue de bgp.tools sur le même ASN était également à accès restreint, et la page de statut de RIPEstat ne portait aucun texte descriptif de titulaire ou de routage (vue AS209045 sur bgp.tools ; page RIPEstat pour AS209045). Les faits de préfixes et de pairs reposent donc sur une seule source tierce. Ils sont verbatim et vérifiables, mais ils ne sont pas doublement sourcés dans ce dossier.

Performance mesurée. Aucune mesure indépendante de débit soutenu n'a été trouvée pour une instance Genesis Cloud. Aucun chiffre de jetons par seconde, aucune courbe de mise à l'échelle multi-nœuds, aucun débit de stockage, aucun coût réel d'achèvement de tâche.

Telle est la frontière. Elle est large, elle est datée, et elle est asymétrique : la couche dotée d'infrastructure publique — le routage — est documentée ; les couches au contenu commercial — catalogue, conditions, sortie, performance — ne le sont pas.

Pourquoi l'absence est le sujet, et non le scandale

Il serait facile, et faux, d'écrire ceci comme l'histoire d'une société qui cache des choses. Rien dans le dossier ne le soutient. Des pages échouent pour des raisons sans rapport avec l'intention : protection contre les robots, blocage régional, rendu dépendant de scripts, site derrière un défi qu'une récupération automatisée ne peut franchir. Une grille tarifaire publiée n'est pas non plus une obligation légale pour une société privée vendant à des entreprises par vente directe.

Ce que le dossier soutient, c'est une observation structurelle sur le marché du cloud GPU dans son ensemble. L'information dont un acheteur a besoin pour chiffrer une tâche n'est pas l'information que le marché rend comparable. Les heures-GPU annoncées sont comparables entre fournisseurs précisément parce qu'elles sont dépouillées de l'équilibre de l'hôte, de l'interconnexion, de la sortie et des clauses d'interruption. Ces termes se négocient, se citent, ou s'enfouissent dans une annexe.

Le seul chiffre comparable est donc celui qui ne détermine pas le coût, et les chiffres qui déterminent le coût sont ceux qui ne peuvent pas être comparés.

Un marché qui fonctionne ainsi ne produit pas des acheteurs irrationnels. Il produit des acheteurs qui optimisent la variable visible, puis découvrent dans la facture qu'ils optimisaient un substitut. Le correctif n'est pas l'indignation. C'est un processus d'achat qui exige les autres couches par écrit — spécifications au niveau de l'instance, topologie d'interconnexion, tarifs de sortie, clauses d'interruption et de crédit, et une mesure sur la charge de l'acheteur plutôt que sur un graphique du fournisseur.

Ce qu'un acheteur peut faire de trois couches

Si un cloud GPU est trois achats, alors la vérification préalable a trois parties, et elles peuvent être spécifiées.

Pour la couche accélérateur, les questions utiles sont ennuyeuses et répondables : quelles générations de dispositifs sont proposées, quelle quantité de mémoire par instance, et quel est le rapport entre accélérateur, processeur hôte et mémoire système. Ce dernier rapport est celui qui décide si l'accélérateur est alimenté ou affamé, et c'est le plus souvent omis.

Pour la couche hôte, demandez le modèle d'ordonnancement et la garantie de tenancy. Une instance donnée est-elle sur un hôte dédié ou partagé ? Que se passe-t-il lorsqu'un colocataire sature la bande passante mémoire ? Quel est le débit du stockage local, et est-il attaché au réseau ? Ces questions ont des réponses, et un fournisseur incapable d'y répondre vous dit quelque chose.

Pour la couche réseau, les questions sont celles auxquelles le dossier de routage ne peut pas répondre : quel est le tarif de sortie par gigaoctet, l'entrée est-elle facturée, existe-t-il une remise sur volume engagé, et où le trafic quitte-t-il physiquement le réseau du fournisseur ? Un acheteur qui pose ces trois questions avant de signer en apprend davantage sur le coût livré que ne le fera jamais une comparaison de tarifs affichés.

Et pour les trois, le contrôle le moins coûteux est une mesure sur votre propre charge, exécutée avant l'engagement, avec une facture confrontée à la mesure plutôt qu'à la grille tarifaire.

Ce qui modifierait ce constat

Les conclusions ici sont bornées par la récupération, non par la conduite, et elles évolueraient si l'un des éléments suivants devenait disponible.

Un dossier RDAP d'autnum lisible nommant le même titulaire, avec identifiants de contact et remarques, ferait passer l'identité de l'ASN de l'attribution tierce au fait de registre. Une grille tarifaire et des conditions de service publiées feraient passer les couches accélérateur et sortie de la frontière à la preuve. Une fiche PeeringDB énonçant la politique d'appairage et la présence aux points d'échange corroborerait ou compliquerait l'observation à deux pairs.

Une mesure indépendante de débit soutenu éprouverait si l'interconnexion derrière cette offre peut porter une charge multi-GPU au rythme dont un acheteur aurait besoin. L'un de ces éléments suffirait à déplacer le centre de gravité de l'article, et tous sont le genre de document qu'un fournisseur sérieux de ce marché finit par publier.

D'ici là, l'énoncé honnête est le plus étroit : la couche de routage est documentée, les couches de calcul ne le sont pas, et l'écart entre les deux est l'endroit où repose actuellement le modèle de coût d'un acheteur.

L'unité qu'un acheteur devrait tarifer

Une heure-GPU est une unité d'occupation. Une tâche achevée est une unité de travail. Tout ce qui détermine la seconde — équilibre de l'hôte, interconnexion, chemin de stockage, sortie, clauses d'interruption — tombe en dehors de la première, et un marché qui ne cite que la première demande aux acheteurs de tarifer un substitut et d'appeler cela un coût.

Le dossier public de Genesis Cloud rend cette abstraction inhabituellement visible, parce qu'il documente une couche et laisse les autres dans l'obscurité. AS209045 est Genesis Cloud Limited de Malte, annonçant deux préfixes IPv6, s'appairant avec euNetworks et OVH, et selon le relevé résumé du dossier, non visible dans la table de routage mondiale depuis le 16 avril 2026. C'est un ensemble de faits réels, vérifiables et précis à propos d'un chemin réseau.

C'est aussi, à lui seul, une base insuffisante pour toute affirmation sur la vitesse à laquelle une tâche d'entraînement s'exécutera ou sur ce qu'elle coûtera.

La discipline que le dossier récompense est simple et peu glorieuse : tarifez la tâche, pas l'accélérateur ; demandez les conditions, pas le graphique ; et traitez la couche publiquement documentée comme un point de départ plutôt que comme un résumé du tout. Les trois choses qu'un cloud GPU vend sont séparables. Les acheteurs qui les séparent obtiennent un coût. Ceux qui ne le font pas obtiennent un tarif.