À l'issue de la livraison d'un site web, votre entreprise doit pouvoir accéder aux bons comptes, retrouver les fichiers convenus, comprendre comment les modifications arrivent sur le site en ligne et savoir qui gère les problèmes. Demandez un inventaire écrit, vérifiez-le avec vos propres accès autorisés et consignez les points encore en suspens avant de clôturer le projet.
Cette checklist s'adresse aux entreprises qui réceptionnent un nouveau site web ou changent d'équipe de maintenance. Elle porte sur la maîtrise pratique du site et la continuité de son fonctionnement. Les éléments, autorisations et services que vous pouvez recevoir dépendent de votre accord ; une invitation à un compte ou un dossier de fichiers ne règle pas, à lui seul, les questions de propriété intellectuelle.
1. Convenir du contenu de la livraison
Partez de la proposition commerciale et du périmètre définitivement convenu. Listez les pages, langues, intégrations et documents modifiables à livrer. Distinguez le site en ligne de ses fichiers sources, fichiers de design, exports de contenu et services tiers. Un site créé dans un éditeur hébergé peut avoir une procédure d'export différente de celle d'un développement sur mesure. Demandez donc ce dont un autre prestataire autorisé aurait besoin pour assurer la maintenance de ce site précis.
Notez la date de livraison, la version exacte soumise à validation et la personne responsable de chaque élément. Si le travail se poursuit après la mise en ligne, indiquez la version décrite par la documentation. Un enregistrement d'un ancien éditeur ou une archive antérieure à la dernière correction peut induire en erreur, même si tous les dossiers attendus sont présents.
Utilisez trois statuts simples : reçu et vérifié, reçu mais non vérifié, et en attente. « Envoyé par e-mail » ne signifie pas « utilisable par l'équipe qui prend le relais ». Ajoutez une note de validation décrivant le contrôle effectué, par exemple l'ouverture du fichier de design dans l'application convenue ou la connexion au compte d'hébergement avec le rôle prévu.
Choisir le format de livraison en amont
Conservez un inventaire succinct dans un espace partagé que l'entreprise pourra garder. Rangez les fichiers complémentaires dans des dossiers clairement nommés, avec une version ou une date lorsque cela compte. Ne transformez pas cet inventaire en liste de mots de passe. Indiquez où sont gérés les identifiants et qui peut accorder les accès, tout en conservant les données secrètes dans un système sécurisé adapté.
2. Vérifier les comptes, le domaine et la facturation
Identifiez le bureau d'enregistrement du domaine, le fournisseur DNS, l'hébergeur, l'éditeur du site ou le dépôt de code, ainsi que les services de formulaire, de réservation ou de messagerie dont le site dépend. Il peut s'agir de comptes distincts. Pouvoir modifier une page ne permet pas forcément de renouveler le domaine, de changer le contact de facturation ou de restaurer le site.
Pour chaque compte, notez l'organisation responsable, l'utilisateur invité, le niveau d'autorisation, la personne chargée du renouvellement ou de l'abonnement et le contact de récupération du compte. Utilisez des invitations individuelles lorsque la plateforme le permet. Vérifiez que les personnes concernées peuvent se connecter avec leur propre compte et accomplir les tâches associées à leur rôle. Suivez les procédures du fournisseur pour l'authentification multifacteur et la récupération des accès ; évitez de faire circuler un mot de passe administrateur commun.
Demandez à l'équipe actuelle d'expliquer quels enregistrements DNS servent au site, à la messagerie ou à d'autres services. Conservez un relevé daté de la configuration avant toute modification convenue. Cloudflare documente l'import et l'export des enregistrements DNS ; les autres fournisseurs proposent leurs propres outils. Une liste exportée constitue une trace utile, mais pas une sauvegarde complète de tous les services rattachés au domaine.
Une passation n'impose pas de changer tous les fournisseurs. Si un transfert est nécessaire, convenez d'abord du compte destinataire, des dépendances, du calendrier et des vérifications. Ne résiliez pas le service existant simplement parce qu'une nouvelle invitation est arrivée. Confirmez qui paiera le prochain renouvellement et où seront envoyées les notifications importantes, surtout si le contact initial quitte le projet.
3. Construire un inventaire réellement vérifiable
Le tableau suivant constitue un point de départ. Remplacez les exemples par vos systèmes réels et les livrables convenus. Attribuez une personne responsable et un statut à chaque ligne. Lorsqu'un élément sort du périmètre du projet, indiquez-le explicitement avec la prochaine action, au lieu de le considérer implicitement comme livré.
| Élément à consigner | Justificatifs à demander | Contrôle par l'équipe qui prend le relais |
|---|---|---|
| Domaine, DNS et hébergement | Emplacement des comptes, rôles, contact de renouvellement et relevé de configuration | Les personnes autorisées trouvent les services et consultent les paramètres nécessaires |
| Code source ou éditeur du site | Dépôt ou espace de travail, version validée et instructions de publication | L'équipe ouvre le projet et identifie la version en ligne |
| Contenus et éléments de design | Fichiers modifiables convenus, exports, liste des ressources et références des licences | Les fichiers s'ouvrent correctement et les limites d'utilisation ou de modification sont documentées |
| Formulaires et intégrations | Destinations, comptes responsables, dépendances et procédure de test sûre | Un test convenu montre le parcours prévu sans contacter de vrais clients |
| Sauvegardes et restauration | Emplacement, périmètre et date des sauvegardes, instructions de restauration | Une démonstration de restauration en toute sécurité couvre les parties pertinentes du site |
| Assistance et travaux en attente | Canal de contact, périmètre, période de couverture et liste des problèmes | Chaque point non résolu a une prochaine action convenue et une personne responsable |
Demandez des justificatifs que vous pourrez consulter après l'appel. Un court enregistrement peut expliquer une modification courante de contenu ; une commande écrite ou une séquence de publication peut aider la personne chargée de la maintenance technique. Aucun de ces supports ne doit révéler de clés secrètes. L'inventaire doit renvoyer vers ces documents et préciser qui les actualise lorsque le site évolue.
Vérifier séparément l'accès au code source et les droits de publication
Un dépôt de code et un compte d'hébergement remplissent des fonctions différentes. Si le transfert d'un dépôt est convenu, revérifiez ensuite ses intégrations et ses autorisations. GitHub précise que les webhooks, les secrets et les clés de déploiement restent associés au dépôt transféré. Un transfert ne remplace donc pas l'examen des personnes et des systèmes qui peuvent encore agir sur le projet.
4. Rendre les fichiers et les consignes de restauration utilisables
Demandez les éléments mentionnés dans votre accord dans un format utilisable par l'équipe qui prend le relais. Il peut s'agir de contenus de pages modifiables, d'images originales, de fichiers de logo approuvés, de documents de design et de code source. Répertoriez les polices externes, images de banques d'images, extensions et autres dépendances avec les informations de compte ou de licence nécessaires pour clarifier leur utilisation future. Ne présumez pas que chaque ressource tierce peut être transférée ou réutilisée sans restriction.
Pour un développement sur mesure, demandez l'environnement d'exécution pris en charge, les instructions d'installation des dépendances, la commande de compilation, les noms des variables de configuration et la procédure de prévisualisation et de publication d'une modification. Excluez les valeurs secrètes réelles de la documentation générale. Une personne compétente chargée de la maintenance doit pouvoir distinguer les paramètres de l'environnement de test de ceux qui se connectent aux services en production.
Définissez le contenu d'une sauvegarde. La documentation WordPress explique qu'une restauration WordPress classique nécessite à la fois la base de données et les fichiers. Pour une autre plateforme, demandez au prestataire d'en décrire les dépendances équivalentes. Une capture d'écran, une archive du code source ou un export des textes peuvent être utiles, mais aucun ne doit être présenté comme un plan de restauration complet sans en expliquer les limites.
Convenez de la personne qui effectue les sauvegardes, de leur emplacement, de leur durée de conservation et de la manière de vérifier la restauration. Demandez une démonstration dans un environnement sûr, avec un traitement approprié des données clients. Notez ce qui a été restauré et ce qui n'a pas été inclus dans l'exercice. N'utilisez pas le site en ligne pour un test de restauration improvisé et ne supposez pas qu'une archive non testée résoudra toutes les pannes.
5. Effectuer un court parcours de validation
Utilisez les propres comptes autorisés de l'équipe qui prend le relais. Retrouvez la version du site soumise à validation, ouvrez l'éditeur ou le projet, localisez les consignes d'assistance et montrez une modification courante dans un environnement de prévisualisation ou de test. L'objectif est de vérifier si la prochaine personne peut exploiter le site à partir des éléments livrés, sans dépendre d'explications qui n'existent que dans la mémoire du prestataire.
Passez en revue quelques parcours clients réels : lire une prestation, naviguer sur un téléphone, accéder au moyen de contact et examiner les confirmations et erreurs convenues. Prévoyez des conditions de test sûres pour les formulaires, réservations et paiements. Convenez à l'avance des adresses et destinations de test afin que l'exercice n'envoie pas de messages à de vrais clients et ne crée pas de commandes involontaires.
Vérifiez également les accès aux comptes de recherche et de mesure, lorsqu'ils sont inclus. Google Search Console distingue les propriétaires, les utilisateurs avec accès complet et les utilisateurs avec accès limité, et explique l'effet des jetons de validation sur la propriété validée. L'examen des autorisations Search Console est distinct de l'accès au site lui-même. Consignez la propriété et le rôle concernés sans considérer cet accès comme la preuve que Google a indexé toutes les pages.
Un exemple hypothétique de passation pour un cabinet de conseil
Imaginez un cabinet de conseil qui réceptionne un site de cinq pages. Sa responsable peut modifier les textes, mais les avis de renouvellement sont toujours envoyés à un ancien prestataire et la destination du formulaire n'est pas documentée. L'équipe consigne ces deux lacunes, confirme le contact de facturation selon la procédure du fournisseur et documente le parcours du formulaire à l'aide d'un test convenu. La responsable reproduit ensuite une modification en prévisualisation à partir des instructions livrées. Cet exemple illustre la méthode ; il ne rapporte pas le résultat d'un projet client.
6. Définir l'assistance et revoir les accès restants
Écrivez ce qui se passe après la validation. Qui traite une panne, un formulaire défaillant, une modification de contenu ou un renouvellement d'abonnement ? Distinguez la correction des défauts de livraison convenus des nouvelles fonctionnalités et de la maintenance courante. Précisez le mode de contact convenu, la période de couverture, les frais éventuels et les engagements de réponse. L'existence d'une adresse e-mail d'assistance ne permet pas de déduire une surveillance permanente.
Tenez une courte liste des travaux en attente avec le problème, son impact, la prochaine action, la personne responsable et la date de réexamen. Décidez quels problèmes empêchent la validation et lesquels peuvent être traités ensuite dans le cadre d'un accord explicite. Si une intégration de réservation reste indisponible, par exemple, consignez le parcours de remplacement pour les clients et la personne qui décidera quand l'intégration définitive sera prête.
Revoyez les accès des collaborateurs qui quittent le projet, les invitations, les jetons d'intégration et les contacts de récupération une fois que l'équipe qui prend le relais a vérifié la continuité du fonctionnement. Ne conservez que les accès utiles au travail continu convenu. Coordonnez les suppressions ou les renouvellements d'identifiants avec la personne responsable de la technique pour que ce nettoyage n'interrompe pas soudainement la publication, les formulaires ou un autre service dépendant. Gardez une trace des décisions sans y stocker de valeurs secrètes.
7. Intégrer la passation au brief du site web
Le moment le plus simple pour convenir d'une passation utile est avant le début du travail. Ajoutez au brief du projet de site web les personnes qui modifieront les contenus, les compétences techniques internes, les fichiers nécessaires, l'organisation des comptes et les besoins d'assistance. Pour un site existant qui change de prestataire, associez cet inventaire à une revue avant refonte afin de garder visibles les responsabilités liées aux services existants.
Avant de clôturer le projet, confirmez que l'inventaire correspond à l'accord, que les accès nécessaires fonctionnent, que les fichiers livrés s'ouvrent, que le parcours de vérification en toute sécurité est documenté et que chaque travail en suspens a un responsable. Conservez ensemble la version validée et les notes de passation. La prochaine personne chargée de la maintenance disposera ainsi d'un point de départ pratique lorsqu'une modification ou un problème surviendra.
La prestation de création de site web de Digital Studio commence à 2 190 EUR pour une création ponctuelle de cinq pages maximum à partir de contenus fournis, avec un design responsive, les bases du SEO, un formulaire de collecte de prospects et une mise en ligne sur votre domaine. Les éléments précis de livraison, les transferts, la formation et l'assistance continue doivent être convenus par écrit pour votre projet ; cette checklist ne les ajoute pas à l'offre publiée. Décrivez votre site web et vos besoins de passation pour discuter du périmètre avant le début du travail.
