Résumé

  • Avec un domaine sans version, Fastly permet de gérer le nom public indépendamment d'une version de service. La préparation de l'adresse et le travail applicatif peuvent suivre des calendriers distincts.
  • Cette souplesse n'a de valeur lors d'une passation que si les droits de compte, la preuve de contrôle du domaine, les certificats et le DNS sont effectivement pris en charge.
  • La délégation entre comptes ne constitue ni un transfert de propriété juridique ni une sortie de Fastly. Les domaines classiques et Platform TLS imposent en outre des procédures différentes.

Deux échéances dans un même contrat

Imaginons une entreprise qui change d'agence web à la fin d'un contrat. La nouvelle équipe doit reprendre l'application ; l'ancienne reste disponible pour une passation organisée. Les achats ont fixé une date, les développeurs une livraison. Mais une troisième échéance peut se cacher dans l'opération : le moment où la nouvelle organisation disposera réellement de l'autorité nécessaire sur l'adresse utilisée par les clients.

Il ne s'agit pas d'un différend connu chez Fastly. Ce cas hypothétique permet d'isoler une question de marché : qu'achète-t-on lorsqu'on confie l'exploitation d'un site ? Le code, les compétences et le suivi quotidien ne sont pas identiques aux moyens qui autorisent le déplacement de son point d'entrée. Une livraison applicative peut être achevée tandis que cette seconde partie de la passation reste à organiser.

Les domaines sans version de Fastly rendent cette distinction plus lisible. Ils se gèrent séparément d'une version de service. On peut ajouter un domaine sans lui associer immédiatement un service et modifier sa gestion sans incrémenter la version du service. Une tâche d'administration du nom n'a donc plus à être embarquée dans chaque cycle de mise en production.

L'intérêt est concret. Une équipe peut préparer l'adresse pendant qu'une autre finalise le service destiné à la recevoir. Le calendrier de l'application n'est plus le seul cadre possible pour organiser le travail. Mais la contrepartie est tout aussi concrète : valider une version ne permet pas de conclure que tout ce qui dirige le public vers cette version a été transmis.

Préparer sans déplacer immédiatement les visiteurs

La séparation prend tout son sens avec les certificats. Dans son guide des certificats gérés, Fastly décrit la validation ACME par DNS utilisée par défaut : seul le sous-domaine de vérification est dirigé vers Fastly. Il est donc possible de préparer TLS avant de déplacer le trafic de production.

C'est une différence importante pour une passation. Les équipes peuvent régler une partie des prérequis alors que les utilisateurs continuent d'emprunter l'ancienne voie. Elles gagnent un temps de préparation distinct du moment où les clients seront effectivement concernés. Ce n'est pas une garantie d'absence d'interruption ; le service d'arrivée doit encore fonctionner comme attendu.

L'autre méthode, la validation par HTTP, dirige immédiatement le trafic. La documentation prévient qu'une configuration TLS ou un service incomplets peuvent alors provoquer des avertissements de sécurité ou rendre le site inaccessible. Derrière deux options techniques se trouve donc une différence de répartition du risque : les travaux inachevés restent-ils entre les mains des équipes, ou arrivent-ils déjà devant les visiteurs ?

Pour l'acheteur, pouvoir anticiper certaines démarches constitue une marge de manœuvre. Un accès manquant peut être découvert avant la dernière réunion de transition. Un désaccord sur la personne responsable du DNS peut être résolu sans attendre que le changement de trafic soit engagé. Les sources ne permettent toutefois ni de chiffrer l'économie obtenue ni de promettre un délai standard.

Cette préparation doit survivre au certificat initial. Des modifications DNS ou une politique CAA restrictive peuvent compromettre son renouvellement. L'API des abonnements TLS distingue l'obtention, le renouvellement et les tentatives répétées de délivrance. Une procédure qui continue à réessayer n'allonge pas, à elle seule, la validité du certificat. Ce qui doit être transmis est aussi la responsabilité de maintenir les conditions nécessaires à la prochaine échéance.

La délégation ne se résume pas à changer de développeur

Fastly distingue les domaines sans version des domaines classiques, liés à une configuration de service et à ses versions. Pour ces derniers, modifier l'association à un service exige une nouvelle version. La documentation réserve cette fonctionnalité classique aux comptes créés avant le 16 septembre 2025. Lorsqu'un domaine classique est déjà utilisé dans un autre compte Fastly, sa délégation passe par l'assistance.

Les domaines sans version disposent, eux, d'un parcours de délégation en libre-service vers un autre compte ou client. La preuve peut prendre la forme d'un certificat géré par Fastly, obtenu au moyen d'une validation DNS, accompagné d'un jeton DNS ; une autre possibilité documentée repose sur un certificat valide émis par une autorité publique reconnue et sa clé privée correspondante. Ce sont des conditions du produit, pas une recommandation de partager des clés de production entre prestataires.

La différence commerciale tient au nombre d'intermédiaires dont dépend la démarche. Une passation admissible peut disposer d'une voie qui ne commence pas nécessairement par un ticket d'assistance. Mais le libre-service n'invente pas les droits du demandeur. Si le client a laissé l'ensemble des accès et des preuves à l'équipe sortante, il doit encore organiser leur prise en charge autorisée.

Le guide d'utilisation des domaines sans version ajoute une limite essentielle : les clients Platform TLS n'ont qu'un accès en lecture à Unified Domain Management et doivent contacter l'assistance pour gérer les domaines ou migrer. Présenter le libre-service comme une propriété universelle de Fastly ferait disparaître cette distinction de produit.

Avant de négocier une date de passation, il faut donc savoir quelle organisation existe réellement. Le nom commercial du fournisseur ne suffit pas à déduire le parcours applicable. Deux clients peuvent utiliser Fastly tout en dépendant de démarches différentes pour reprendre l'administration de leur adresse. Les documents publics ne donnent ni taux de réussite ni délai moyen permettant d'effacer cette incertitude.

Ce qu'une preuve technique ne transfère pas

L'API de gestion des domaines distingue le contrôle vérifié par certificat, l'existence d'au moins une activation TLS et les associations à un service ou à une configuration de routage. Ces deux dernières relations peuvent être vides. Ce découpage décrit des capacités opérationnelles différentes ; il ne constitue pas un titre de propriété.

Prouver le contrôle d'un domaine selon les règles du produit ne tranche pas un litige sur son enregistrement. Cela ne transfère ni une marque ni une société. De même, disposer d'une activation TLS ne démontre pas que toutes les fonctions commerciales du site aboutissent à la bonne application. Un contrat d'exploitation doit éviter de traiter ces objets différents comme une unique formalité intitulée « transfert du domaine ».

Le certificat autogéré paraît parfois plus facile à remettre puisqu'il existe sous forme de fichier. Pourtant, le guide correspondant exige, au-delà du certificat valide et de la clé correspondante, la configuration TLS, les activations et les réglages DNS appropriés. La présence de plusieurs noms dans un certificat ne signifie pas que chacun a automatiquement fait l'objet de l'activation explicite prévue.

Le renouvellement d'un certificat autogéré reste également à la charge du client. Recevoir les fichiers sans reprendre le suivi des échéances et les accès nécessaires reporte simplement la difficulté. Les prérequis TLS précisent encore des conditions de compte et d'autorisation. Une documentation transmise à la nouvelle équipe ne lui confère pas mécaniquement les permissions qu'elle décrit.

Il n'est pas nécessaire que le client réalise lui-même toutes ces tâches. C'est précisément l'intérêt de faire appel à un spécialiste. Il doit en revanche pouvoir identifier celui qui en répond, et organiser un remplacement sans découvrir à cette occasion que plusieurs responsabilités avaient été confondues.

Derrière une adresse, plusieurs périmètres de travail

La passation peut aussi concerner des règles qui ne résident pas dans l'application. Fastly permet de router les requêtes selon des chemins et des conditions vers différents services Fastly, sans écrire de VCL ou de code Compute pour cette couche de routage. Une même adresse peut ainsi rester stable alors que le travail est réparti derrière elle.

Dans un projet de refonte progressive, cette possibilité peut servir à distinguer plusieurs parties du site. C'est une utilisation illustrative de la fonction, pas un déploiement client observé. L'organisation gagne un moyen de répartir les demandes sans imposer un nouveau nom public à chaque service. Elle doit, en contrepartie, savoir quelle équipe administre cette répartition.

La documentation exige un domaine présent dans Domain Management, un certificat TLS valide et un service actif. Une règle par défaut est obligatoire. La configuration doit être déployée puis liée au domaine ; lorsqu'une configuration déjà déployée est liée, elle commence à diriger le trafic. L'autorité sur cette association ne se confond donc pas avec la capacité à livrer l'application destinataire.

Pour une entreprise qui répartit les responsabilités par dépôt de code, cette couche peut devenir un angle mort contractuel. La nouvelle équipe reçoit son service, mais une règle commune continue à décider quelles demandes lui parviennent. La bonne réponse n'est pas de supprimer cette souplesse. Elle consiste à faire correspondre le périmètre de la passation à celui des décisions qui touchent réellement l'adresse publique.

Une liberté interne n'est pas encore une sortie

Changer de service dans un compte, déléguer un domaine à un autre compte et quitter Fastly ne sont pas la même opération. Les deux premières réorganisent le travail dans la plateforme. La troisième demande un service d'accueil ailleurs, ses certificats et ses conditions applicatives, ainsi qu'un déplacement du trafic approprié. Quant à un changement de propriétaire juridique, il relève encore d'une autre question.

Le guide d'acheminement du trafic indique que Fastly ne fournit pas de DNS géré dans la configuration décrite. Le client choisit son prestataire DNS et installe les enregistrements fournis. Il existe donc un moyen d'administration extérieur au cycle applicatif. Reste à savoir si le client en conserve effectivement la maîtrise dans sa propre organisation.

Les enregistrements déjà mis en cache imposent aussi leurs contraintes de transition. Une signature de réception ne les fait pas disparaître. À l'inverse, une modification d'association entre domaine et service dans Fastly n'est pas nécessairement une migration DNS publique. Bien distinguer ces événements évite d'exagérer la facilité d'une sortie tout en sous-estimant la portée d'un changement interne.

Fastly a déclaré dans ses résultats du deuxième trimestre 2026 un chiffre d'affaires de 183,3 millions de dollars, dont 133,9 millions pour Network Services. Ces données publiées par l'entreprise situent l'échelle de son activité ; elles ne mesurent ni l'adoption des domaines sans version ni leur contribution aux économies des clients.

L'enjeu pour l'acheteur est plus précis qu'une indépendance absolue. Il s'agit de pouvoir changer l'équipe qui travaille derrière son adresse sans devoir reconstituer au préalable sa propre capacité à autoriser le changement. Fastly dissocie le nom d'une version. Au client et à ses prestataires de faire en sorte que leurs responsabilités soient tout aussi clairement dissociées.