Checklist de fin de projet web : garder le contrôle

Une remise de site ne devrait pas dépendre de la mémoire d’un fournisseur. Cette checklist aide une PME québécoise à vérifier ce qu’elle contrôle réellement et à conserver des preuves utilisables après la fin du projet.

Une vérification de contrôle, pas seulement une liste de fichiers

Recevoir un site fonctionnel ne confirme pas que l’entreprise peut le faire évoluer, renouveler ses services ou réagir à un incident. La question utile est opérationnelle : si la personne qui a réalisé le projet est indisponible, l’équipe peut-elle identifier les fournisseurs, ouvrir les comptes, retrouver les sources et comprendre les prochaines échéances?

Auteur : Alexis Boulet. Éditeur : 27PM. Révision : 9 octobre 2026. Méthode : cette ressource regroupe huit zones de contrôle observables à la fin d’une création ou d’une refonte. Pour chacune, elle distingue ce qu’il faut vérifier de la preuve à conserver. Une capture d’écran seule ne remplace pas un accès testé, un export lisible ou une responsabilité confirmée.

Faites la vérification avec une personne responsable côté entreprise. Inscrivez les écarts, le nom de la personne qui doit les corriger et une date de suivi dans le fichier CSV modifiable.

1. Domaine et DNS

À vérifier : l’entreprise est titulaire du nom de domaine et contrôle le compte du registraire; les coordonnées administratives, le renouvellement, le verrouillage et l’authentification sont compris. Une personne autorisée sait où sont gérés les DNS et peut reconnaître les entrées qui soutiennent le site, les courriels et les services connexes.

Preuves à conserver : nom du registraire, identifiant organisationnel, contacts autorisés, date de renouvellement, facture récente et export ou relevé daté de la zone DNS. Les mots de passe et codes de récupération vont dans un gestionnaire de secrets approuvé, pas dans la checklist.

2. Hébergement et facturation

À vérifier : l’équipe peut ouvrir le compte d’hébergement, identifier le projet en production, la région utilisée, le forfait, le moyen de paiement et la personne qui reçoit les avis de panne ou de renouvellement. Les coûts récurrents et les limites connues sont attribués à un budget.

Preuves à conserver : fournisseur, propriétaire du compte, numéro de projet ou d’abonnement, dernière facture, cycle de facturation, coordonnées de soutien et procédure pour modifier le paiement. Conservez aussi la date de fin de tout crédit ou tarif promotionnel applicable.

3. Code source et déploiement

À vérifier : l’entreprise possède un accès approprié au dépôt de code source et sait quelle branche ou version correspond au site publié. La procédure de déploiement, les environnements, les variables de configuration et les approbations nécessaires sont expliqués sans exposer les secrets.

Preuves à conserver : adresse du dépôt, organisation propriétaire, liste des administrateurs, référence de la version livrée, instructions de construction et de déploiement, inventaire des environnements et résultat daté du dernier déploiement vérifié. Les clés privées demeurent dans leur coffre prévu.

4. Contenus, médias et licences

À vérifier : les textes, images, vidéos, polices, icônes et autres contenus livrés ont une source connue et des droits compatibles avec l’usage prévu. L’équipe sait où modifier le contenu et quels éléments nécessitent une attribution, une licence renouvelable ou une autorisation distincte.

Preuves à conserver : export des contenus lorsque pertinent, fichiers sources convenus, registre des médias, licences, factures, autorisations écrites, crédits exigés et date d’expiration. Pour une image illustrative ou un concept indépendant, gardez aussi le libellé qui empêche de l’interpréter comme un mandat client.

5. Comptes, accès et 2FA

À vérifier : chaque service important possède au moins un administrateur interne identifié; les comptes individuels remplacent les identifiants partagés lorsque le service le permet; les anciens accès sont retirés; l’authentification à deux facteurs, ou 2FA, est activée selon le risque et peut être récupérée sans dépendre d’une seule personne.

Preuves à conserver : inventaire des comptes, rôles, propriétaires, méthodes 2FA, emplacement contrôlé des codes de récupération et journal de la revue des accès. Ne placez ni mot de passe, ni jeton, ni code de récupération dans un document partagé en clair.

6. Formulaires, données et confidentialité

À vérifier : chaque formulaire envoie les renseignements à la bonne destination, affiche un état clair en cas de succès ou d’erreur et ne recueille que les données prévues. Les responsables connaissent les lieux de stockage, les destinataires, les durées de conservation, les suppressions possibles et le texte de confidentialité présenté aux visiteurs.

Preuves à conserver : copie des champs et consentements visibles, schéma des destinations, fournisseurs et sous-traitants connus, règles de rétention, procédure d’accès ou de suppression, résultat d’un envoi de test et personne responsable du suivi. Supprimez les données d’essai une fois la vérification terminée.

7. Analytique, Search Console et intégrations

À vérifier : les propriétés d’analytique et de Search Console appartiennent à un compte contrôlé par l’entreprise; les personnes autorisées ont le bon rôle; la mesure respecte les choix de consentement prévus. Pour chaque intégration, l’équipe connaît la source, la destination, le compte de service, les limites et le comportement attendu en cas d’échec. Une automatisation avec IA doit aussi identifier les données autorisées, la validation humaine et la procédure de reprise manuelle.

Preuves à conserver : identifiants des propriétés, liste des propriétaires, configuration de consentement, événements ou conversions retenus, inventaire des intégrations, documentation des dépendances et capture datée d’un contrôle réel. Une acceptation par un fournisseur ne prouve pas à elle seule que les données sont complètes ou exactes.

8. Sauvegardes, continuité et support

À vérifier : les éléments sauvegardés, la fréquence, la durée de conservation et la personne responsable sont explicités. Une restauration peut être demandée ou essayée dans un environnement isolé de la production. L’entreprise sait qui contacter pour le soutien, ce qui est inclus après la livraison et comment reprendre l’exploitation avec une autre ressource.

Preuves à conserver : politique ou configuration de sauvegarde, date et résultat du dernier test de restauration, copie distincte des instructions de reprise, coordonnées de soutien, heures ou délais contractuels, exclusions, fin de garantie et inventaire des tâches d’entretien récurrentes.

Un contrôle de reprise en six actions

Choisissez un moment ordinaire, avec la personne qui héritera réellement du site. Sans demander au fournisseur d’agir à votre place, vérifiez les six actions suivantes avec des données de test et sans modifier la production inutilement :

  1. Ouvrir le compte du registraire, repérer le domaine et confirmer la prochaine date de renouvellement.
  2. Ouvrir l’hébergement, identifier le projet publié et retrouver la dernière facture.
  3. Accéder au dépôt de code, repérer la version livrée et suivre les instructions jusqu’au point précédant un déploiement réel.
  4. Envoyer un formulaire avec une mention de test, confirmer sa destination puis supprimer l’entrée d’essai selon la procédure prévue.
  5. Ouvrir Search Console ou l’outil d’analytique autorisé, confirmer la propriété consultée et nommer la personne qui en est propriétaire.
  6. Retrouver une sauvegarde récente et expliquer, documents en main, comment demander ou effectuer une restauration sans toucher au site public.

Pour chaque action, notez « vérifié », « à corriger » ou « non applicable », la date et la preuve observée. Si une action repose encore sur une seule personne externe, transformez ce constat en tâche avec un responsable et une échéance.

Utiliser la version CSV dans votre projet

Le CSV de la checklist de fin de projet web contient une ligne par zone de contrôle et des colonnes pour le responsable, l’emplacement de la preuve, la date, le statut et les notes. Importez-le dans votre tableur, remplacez les indications génériques par les systèmes réels et ajoutez des lignes si votre contexte comporte plusieurs domaines, établissements ou plateformes.

Intégrité du fichier publié : 2700 octets · SHA-256 : c6728c446cd840f499546b375e360af7626c52c45c5c2ff4e68e337852c033f3. Ces valeurs permettent de vérifier que le fichier téléchargé correspond à la version décrite sur cette page.

Évitez d’y copier des secrets. Inscrivez plutôt le nom du coffre ou du système autorisé où ils se trouvent. Une fois la remise acceptée, rangez la checklist avec le contrat, les factures, les instructions et les décisions de projet afin qu’elle reste accessible à l’entreprise.

Limites et prochaine étape

Cette checklist fournit un cadre opérationnel général. Elle ne remplace pas un avis juridique ni une évaluation de sécurité, de confidentialité ou de conformité. Il faut adapter cette liste à votre contexte, à la sensibilité des données, aux contrats applicables, aux obligations de votre secteur et aux politiques internes de votre organisation.

27PM peut intégrer ces contrôles au périmètre d’une création de site web ou d’une refonte, puis définir avec votre équipe les preuves et responsabilités attendues avant la réception.

Parler à 27PM de votre projet et de sa remise