Livrer un site web à un client : domaine, comptes, code et fin de mission

Le site s’ouvre et le client l’a approuvé. Il reste à vérifier autre chose : pourra-t-il le conserver, le payer, le renouveler et commander des modifications quand vous cesserez de l’administrer ? Livrer une URL ne remet pas automatiquement le domaine, les comptes ou les fichiers nécessaires à une nouvelle publication.

Une question originale de développeur en espagnol décrit précisément ce cas : un site statique sans API ni backend, dont le développeur souhaite que le client contrôle le domaine sans rester lui-même responsable de son compte. Ce guide propose une procédure de livraison documentée. Il ne présume pas comment le site a été créé et ne transforme pas les réponses du forum en instructions du fournisseur.

Nous utiliserons un modèle original MIT fixé à un commit. C’est un registre de responsabilités et de vérifications, ni un contrat ni une fonction automatique du panneau. Il ne démontre pas de transfert natif chez Hostbrid.

Notez ce que vous livrez et ce qui est exclu

Complétez une ligne par service : domaine, DNS, hébergement, dépôt, courrier, formulaires et mesure d’audience. Ajoutez serveur et base de données lorsqu’ils existent ; indiquez « sans objet » dans les autres cas. Notez une référence sans secrets, le titulaire, le responsable du paiement et du renouvellement, les accès techniques disponibles et leur procédure de retrait.

Avant de choisir un produit, distinguez les fichiers statiques d’un processus serveur. Commencez par l’hébergement d’un site créé avec une IA et l’inventaire du dépôt. Incluez les dépendances externes, même sans backend propre.

Un cas illustratif : le site statique d’une menuiserie

Imaginez un site sur ejemplo.invalid, domaine réservé à cet exemple, sans API, authentification ni formulaires. Après vérification du projet, les lignes serveur, base de données et paiements des clients peuvent être marquées « sans objet ». Domaine, dépôt, compte d’hébergement, paiement du service et renouvellement restent associés à des responsables. Client et technicien consigneraient les fichiers à remettre et les accès à retirer. Ils devraient ensuite effectuer les vérifications de pages, rechargement et images décrites plus bas. C’est une illustration, ni un client réel ni une livraison testée.

Séparez contrôle du domaine et publication

Identifiez le compte du registraire, le titulaire déclaré, le destinataire des avis et la personne pouvant récupérer l’accès. Si le client en sera responsable, confirmez avec lui ces informations et les exigences du registraire. Pointer le domaine vers votre serveur ne remet pas le compte.

Déplacer les DNS, changer d’hébergement et transférer un domaine entre registraires sont des opérations différentes. Avant de changer les serveurs DNS, inventoriez les enregistrements nécessaires au site et au courrier. Le guide pour changer les DNS sans perdre le courrier traite cette opération précise ; il ne remplace pas la remise du compte du registraire. Ne résiliez pas l’ancien service avant de vérifier ce qui en dépend encore.

Utilisez des identités individuelles et décrivez les permissions réelles

Le client doit pouvoir se connecter avec sa propre identité et récupérer son compte. Si le service permet une délégation, utilisez une identité distincte pour l’agence et les permissions réellement disponibles. N’échangez pas de mots de passe et ne consignez ni tokens ni clés privées dans le modèle.

Vérifiez, opération par opération, qui peut consulter les données, publier, modifier les DNS, acheter ou résilier. Ne déduisez pas ces capacités d’étiquettes comme « lecteur » ou « administrateur ». Sans accès délégué, documentez la limitation et convenez d’une alternative avec le fournisseur avant de fonder la livraison dessus.

Hostbrid peut être une destination candidate selon l’architecture du projet et les services et offres publiés. Avant d’acheter, confirmez les conditions d’accès nécessaires. Cette checklist ne démontre ni parcours d’invitation, ni permissions de lecteur universelles, ni transfert automatique de comptes chez Hostbrid ; elle n’a pas besoin de supposer ces fonctions pour enregistrer responsables et tâches en attente.

Remettez les fichiers et vérifiez dans le contexte du client

Consignez la révision du code, les instructions de construction et les fichiers autorisés à être remis. Conservez le lockfile nécessaire et expliquez comment modifier textes et images. Séparez configuration partageable et secrets ; convenez par écrit des droits et conditions du matériel. Administrer un compte ne détermine pas à lui seul sa titularité juridique.

Consignez chaque vérification dans les colonnes attendu, observé, preuve et date du modèle. Testez accueil, URL intérieure directe, rechargement, images et routes inexistantes. Vérifiez que la page attendue apparaît : un HTTP200 peut être un accueil de fallback. S’il existe un formulaire, le test doit atteindre une destination propre autorisée, pas des tiers. Une sauvegarde téléchargée ne prouve pas sa restauration ; consignez ce que vous avez réellement récupéré dans un environnement isolé.

Finalisez paiements, support et retrait des accès

Notez dates de renouvellement, responsable du paiement, avis et services externes qui resteront actifs. Distinguez vente du site, maintenance ultérieure et tâches exclues. Le modèle ne fixe pas d’obligations juridiques et ne garantit pas que vous puissiez vous retirer unilatéralement.

Convenez du matériel remis, du responsable d’un transfert futur et de la durée de disponibilité du service pendant cette transition. Après confirmation de l’accès du client et de la continuité, le responsable autorisé peut retirer les identités de l’agence et renouveler les identifiants concernés via le service approprié, selon la procédure convenue. N’intervenez pas sur des ressources de tiers ni en production sans autorisation spécifique. Vérifiez que le retrait ne supprime pas le compte et n’interrompt pas la publication. Tout élément non vérifié doit rester en attente, avec un responsable, plutôt que d’être marqué « livré ».