Réponse en bref
La remise d'un site tient en cinq éléments : le domaine, le compte d'hébergement, le dépôt, un accès propriétaire à l'administration et les variables d'environnement avec leurs valeurs. Voici comment vérifier chacun avant le paiement final.
Ce que vous recevez à la remise : la réponse courte
À la remise vous recevez cinq choses : le contrôle du domaine, un compte sur la plateforme d'hébergement, le dépôt contenant le code source, un accès de niveau propriétaire à l'administration, et la liste des variables d'environnement avec une note sur le rôle de chacune. Tout le reste n'est que documentation enveloppant ces cinq éléments.
Un site web est un système qui tourne, pas un fichier. Il a une adresse par laquelle on le trouve, un endroit où il s'exécute, du code dont il est construit, un panneau où l'on modifie le contenu, et des réglages qui le relient à des services extérieurs.
Qu'il en manque un seul et vous possédez un site que vous pouvez regarder mais pas modifier. C'est une position commerciale, pas une note technique : cette liste décide si vous pouvez changer de prestataire sans repayer un travail déjà fait.
Ce qui suit prend chaque élément à son tour — à quoi il ressemble, quoi vérifier avant de valider, et où la remise se situe à l'intérieur des offres VITON13, dont le périmètre et les délais sont annoncés d'avance.
Le domaine : qui contrôle le compte chez le bureau d'enregistrement
Un domaine vit à l'intérieur d'un compte chez un bureau d'enregistrement. La propriété repose sur deux choses : qui se connecte à ce compte, et de qui sont les coordonnées inscrites dans les champs du titulaire.
L'arrangement qui fonctionne, c'est un domaine enregistré au nom de votre entreprise, le développeur recevant un accès délégué ou des droits sur les enregistrements DNS. Celui qui ne fonctionne pas, c'est un domaine enregistré au nom du développeur pour vous épargner la paperasse.
Vérifiez-le vous-même : connectez-vous au bureau d'enregistrement avec vos propres identifiants, confirmez que l'adresse du titulaire est une adresse que votre entreprise contrôle, vérifiez que le renouvellement automatique est actif, et ouvrez les enregistrements DNS pour constater qu'ils sont modifiables.
Un domaine est aussi un paiement récurrent. Le renouvellement est débité à celui qui détient le compte : l'accès et la responsabilité de la date de renouvellement et de la carte enregistrée voyagent ensemble.
L'hébergement et la plateforme où le site tourne réellement
L'hébergement est l'endroit d'où le site construit est servi : un serveur virtuel, une plateforme gérée, un environnement conteneurisé. Ce qui compte à la remise, c'est le compte, l'offre sur laquelle il se trouve et le moyen de paiement qui y est rattaché.
Demandez le fournisseur, le nom du projet, la région et votre niveau de droits. Les droits propriétaire ou administrateur sont la cible ; un lien invité qui ne montre que les journaux n'est pas un accès, c'est une vue.
Le DNS appartient à la même conversation : quels enregistrements pointent le domaine vers l'hébergement, où vivent les enregistrements de messagerie, comment le certificat est émis et renouvelé. Un simple fichier texte listant ces enregistrements est un livrable honnête.
Écrivez aussi le chemin de panne : quel journal ouvrir, comment revenir au déploiement précédent, qui a le droit de le faire. Ce n'est pas une promesse que rien ne cassera, c'est une route documentée pour le moment où quelque chose cassera.
Le dépôt : des sources, pas un dossier de fichiers
Un dépôt, c'est le code accompagné de son historique de changements. Une archive appelée site-final.zip n'est pas la source : elle n'a ni branches, ni historique, ni lien entre une modification et la raison qui l'a motivée.
Ce que vous voulez, c'est le dépôt sous votre propre organisation ou votre compte, avec le rôle propriétaire attaché à vous. Le développeur reste collaborateur tant que le travail continue et perd l'accès quand il s'arrête.
À l'intérieur, ce qui mérite vérification : un historique de commits lisible, une instruction de construction qu'un tiers peut suivre, une liste de dépendances aux versions figées, et aucune clé ni mot de passe versionné dans le code.
Le test est rapide. Un autre développeur clone le dépôt, suit le README et se retrouve avec une copie locale qui fonctionne. Si elle ne démarre pas, la remise n'est pas encore terminée.
L'administration : rôles, droits propriétaire et où vit le contenu
Là où existe un CMS ou un panneau sur mesure, il vous faut un compte propriétaire plutôt qu'un compte éditeur. Un propriétaire crée et révoque des utilisateurs ; un éditeur ne change que des textes et des images.
Demandez la liste de tous les comptes existant dans le système, avec leur rôle. Les comptes dont personne n'a besoin sont révoqués pendant l'acceptation, pas laissés pour un rangement qui ne sera jamais planifié.
Établissez ensuite où le contenu se trouve physiquement : la base de données, les fichiers téléversés, le stockage média. Et comment une copie est prise — un export manuel, une sauvegarde automatique, et l'endroit où ces copies sont conservées.
Il est utile de noter quels champs du panneau atteignent les pages publiques : titres, métadonnées, redirections. Un éditeur qui connaît la limite d'un champ est un éditeur qui ne casse pas une mise en page avec une image trop grande.
Les variables d'environnement : les réglages sans lesquels rien ne démarre
Les variables d'environnement sont les clés et les adresses par lesquelles un site parle aux services extérieurs — la base de données, l'envoi de courrier, les paiements, l'analytics, le stockage de fichiers. Elles ne vivent pas dans le code ; elles sont posées sur la plateforme.
La remise a besoin des deux moitiés : une liste des variables avec une ligne expliquant à quoi chacune sert, et les valeurs elles-mêmes, transmises par ce que votre entreprise utilise déjà pour conserver des secrets, par exemple un gestionnaire de mots de passe d'entreprise.
Une liste sans valeurs vous laisse une construction qui refuse de démarrer. Des valeurs sans liste vous laissent un tas de chaînes que personne ne saura interpréter six mois plus tard.
Certaines de ces clés appartiennent à des comptes tiers — un prestataire de paiement, un service de messagerie. Ces comptes doivent également être à votre nom, sinon une rotation de clé de routine de leur côté met votre site hors ligne.
Construction et déploiement : comment les sources deviennent un site en ligne
Entre le dépôt et le site publié se trouve une construction : les commandes qui transforment les sources en ce que le serveur remet à un navigateur. Ce processus doit être écrit et reproductible sur une autre machine.
Le minimum, c'est une version d'exécution, la commande qui installe les dépendances, la commande qui construit et la commande qui lance. Mieux encore : les mêmes étapes dans un fichier d'intégration continue, pour que la construction ne dépende pas d'un seul ordinateur portable.
Le déploiement se documente séparément : quelle branche atteint la production, ce qui se fait automatiquement, ce qui se fait à la main, qui a le droit de publier une version, et à quoi ressemble un retour arrière.
La valeur ici, c'est la répétabilité plutôt que l'élégance. Une construction qui ne réussit que sur la machine de son auteur est une dépendance cachée envers cet auteur, déguisée en dispositif technique.
Services tiers : analytics, messagerie, paiements, cartes
Un site vit rarement seul. Une propriété d'analytics, du courrier transactionnel, le traitement des formulaires, les paiements, les cartes, un widget de discussion — chacun a un compte derrière lui, une clé, et quelqu'un dont la carte est débitée.
Construisez un tableau à quatre colonnes : service, compte, propriétaire, endroit où la clé est rangée. Cette feuille fait gagner du temps le jour où l'un de ces services doit être remplacé, renégocié ou coupé.
Les paiements sont plus stricts. Le compte marchand appartient à l'entité juridique qui encaisse, et il ne peut pas être garé chez un développeur comme un détail technique. Les licences de paiement se situent hors du périmètre de Product Build.
L'analytics mérite sa propre vérification : confirmez que les données atterrissent dans votre propriété et que les droits d'administrateur sont les vôtres. Sinon, un changement de prestataire vous coûte l'historique contre lequel vous comptiez mesurer.
La documentation : courte, et pas facultative
La documentation de remise n'est pas un manuel de cent pages. C'est un README dans le dépôt plus une page de procédure : de quoi le site est fait, où il tourne, comment le construire, comment le déployer et qui appeler.
Ajoutez une liste de ce qui n'a pas été fait et pourquoi — travaux reportés, limites connues, compromis acceptés délibérément. Cette liste est plus honnête que le silence et épargne au prestataire suivant de redécouvrir chaque décision.
Consignez le matériel sur lequel vos vérifications de performance se sont appuyées. La section Performance de MDN Web Docs expose les métriques de chargement et le comportement du navigateur, et pointer vers elle tient mieux qu'un accord verbal sur le mot « rapide ».
L'accessibilité fonctionne pareil. La référence rapide du W3C pour WCAG 2.2 liste les critères de succès sous une forme vérifiable. Si des vérifications ont été menées, notez le niveau de conformité et les pages couvertes.
Pourquoi une remise sans accès revient à repartir de zéro
Sans accès, le prestataire suivant ne voit jamais les sources et reconstruit à partir de ce que révèle un navigateur. La mise en page peut être reproduite ; la logique, les intégrations et la configuration du panneau ne se lisent pas de l'extérieur.
Ses heures partent alors à recréer l'état que vous avez déjà, plutôt qu'à l'améliorer. Vous payez une deuxième fois un site qui est posé sur votre domaine et qui fonctionne.
L'exposition n'est pas seulement financière. Sans le compte du bureau d'enregistrement, un domaine peut expirer en silence ; sans accès à l'hébergement, un site ne peut pas être relevé après une panne ; sans la liste des variables, une rotation de clé de routine devient une interruption.
Une remise avec accès transforme le site en un actif que l'entreprise possède. Sans cela, le site reste un morceau de l'infrastructure du développeur, que vous louez à des conditions que personne n'a jamais écrites.
Où la remise se situe dans les offres VITON13
Site Fix Pack coûte 70 $ et dure 1-2 jours ouvrés : jusqu'à cinq corrections convenues, une vérification sur mobile et sur ordinateur, et une liste avant/après à la remise, avec 1 tour de révision. Les nouvelles pages, la refonte et les migrations ne sont pas comprises.
Launch Site coûte 380 $ sur 3-5 jours ouvrés : une construction adaptable, la connexion du CMS ou des données de base et la configuration du déploiement, avec 2 tours avant le lancement. Le contenu et les traductions sont fournis par le client — nous ne les rédigeons pas.
Product Build coûte 880 $ sur 2-3 semaines : livraison de fonctionnalités, logique d'états et de routes, tests et durcissement, avec 2 tours par fonctionnalité livrée. Les applications mobiles natives et les licences de paiement se situent hors de ce périmètre.
Ongoing Dev Support coûte 290 $/mois pour des mises à jour prioritaires, un rythme hebdomadaire de publication et la maintenance technique ; il fonctionne en cycle mensuel avec 30 jours de préavis pour l'arrêter, le volume de travail est convenu au début de chaque cycle, et une nouvelle construction ou une refonte se chiffre séparément. Launch Site Express coûte 520 $ sur 2 jours ouvrés : le périmètre de Launch Site en file prioritaire, avec des compilations quotidiennes, une liste de contrôle de lancement et un appel de remise, avec 1 tour après la première construction complète, tandis que le contenu, la photographie et le support continu ne sont pas compris.
Ce qu'il faut faire avant de valider
Menez les vérifications avant le paiement final plutôt qu'après. Demandez les accès, connectez-vous depuis votre propre appareil avec vos propres identifiants, et confirmez que vous atteignez les réglages et pas seulement les pages publiques.
Demandez ensuite une construction à partir d'un clone propre du dépôt et déployez-la sur un environnement de test. C'est ainsi que la liste des variables se vérifie : s'il en manque une, la construction elle-même le dira.
Faites entrer la liste dans le contrat : domaine, hébergement, dépôt, administration, variables d'environnement, comptes tiers, documentation. Une clause est opposable ; une compréhension partagée que tout sera remis ne l'est pas.
Le périmètre, les délais et le nombre de tours de révision de chaque offre sont exposés sur la page du service de développement VITON13. Partir de cette liste transforme la conversation sur la remise en un ensemble de points vérifiables plutôt qu'en un ensemble d'assurances.
Checklist pratique
- Connectez-vous au bureau d'enregistrement avec vos propres identifiants et vérifiez le contact du titulaire et le renouvellement automatique.
- Prenez les droits propriétaire ou administrateur sur le compte d'hébergement et demandez la carte des enregistrements DNS.
- Faites passer le dépôt sous votre compte et confirmez qu'il se construit depuis un clone propre.
- Demandez la liste des comptes d'administration avec leurs rôles et révoquez les inutiles pendant l'acceptation.
- Réunissez les variables d'environnement avec leurs valeurs et rangez-les dans le gestionnaire de mots de passe de l'entreprise.
- Inscrivez la liste des accès et de la documentation remis dans le contrat, avant le paiement final.
Questions et réponses
Que doit-on exactement transférer au client à la fin d'un projet ?
Le domaine, le compte d'hébergement, le dépôt contenant le code source, un accès propriétaire à l'administration et les variables d'environnement avec leurs valeurs. S'y ajoutent une liste des comptes tiers et une courte documentation couvrant la construction et le déploiement.
Combien coûte le travail de développement et qu'est-ce qui est remis avec ?
Site Fix Pack coûte 70 $ sur 1-2 jours ouvrés : jusqu'à cinq corrections convenues, avec une vérification sur mobile et sur ordinateur et une liste avant/après à la remise, et 1 tour de révision. Launch Site coûte 380 $ sur 3-5 jours ouvrés : une construction adaptable, la connexion du CMS ou des données de base et la configuration du déploiement, avec 2 tours avant le lancement.
Le domaine peut-il rester enregistré au nom du développeur ?
Techniquement oui, mais la date de renouvellement et les droits sur les enregistrements DNS échappent alors à votre contrôle. Enregistrez le domaine au nom de votre entreprise et donnez plutôt au développeur un accès délégué.
Un dossier de fichiers suffit-il à la place d'un dépôt ?
Non. Une archive ne porte ni historique des changements, ni branches, ni lien entre une modification et la tâche qui l'a motivée : le développeur suivant travaille à l'aveugle. Il vous faut le dépôt sous votre compte, avec le rôle propriétaire.
Une liste de noms de variables d'environnement suffit-elle sans les valeurs ?
Non : sans valeurs la construction ne démarre pas, et des valeurs sans explication sont impossibles à interpréter six mois plus tard. Remettez la liste avec l'usage de chaque variable, en même temps que les valeurs, via votre gestionnaire de mots de passe.