Le site est-il prêt à être mis en ligne ? Une checklist de recette pour l'entreprise

« Le site est-il prêt ? » reçoit en général une réponse subjective : ça a l'air d'aller. La recette sert à remplacer cette impression par une liste de tests effectués, chacun avec un résultat et un responsable, et par une distinction nette entre les défauts qui empêchent la publication et ceux qui se corrigent après. Elle sert autant à l'entreprise qu'au prestataire, car elle clôt le projet sans files interminables de signalements.

Ce n'est pas une revue graphique. On ne discute pas si la couleur plaît : on vérifie que les parcours fonctionnent, que les contenus disent le vrai et que les demandes arrivent à destination.

Testez des parcours, pas des pages

Ouvrir toutes les pages une par une donne une fausse sécurité : les pages se voient, les parcours se cassent. Un parcours est une séquence qu'un visiteur réel accomplit vraiment.

• Je cherche votre nom, j'arrive sur l'accueil, je cherche un service, je lis la fiche, je demande des informations.
• J'arrive sur une page interne via un lien reçu, sans passer par l'accueil : est-ce que je comprends où je suis et comment continuer ?
• Je veux le numéro de téléphone depuis un smartphone : combien de touchers faut-il pour le trouver et le composer ?
• Je suis un client et je cherche l'assistance ou l'espace client.

Chaque parcours doit être testé sur au moins un vrai téléphone et sur un ordinateur, pas seulement en rétrécissant la fenêtre du navigateur. Le téléphone a un clavier qui couvre la moitié de l'écran, un doigt large comme dix pixels et un réseau parfois absent : trois choses qui ne se voient pas sur un écran de bureau. Testez aussi avec une connexion lente et avec le téléphone tourné.

Le procès-verbal de recette

Un outil simple et suffisant : un tableau avec une ligne par test. Il évite la discussion la plus fréquente en fin de projet, « on l'avait dit » contre « ce n'était pas dans le périmètre ». Quelques lignes d'exemple.

Les colonnes qui comptent sont les deux dernières. Une recette sans un nom en face de chaque ligne n'est pas faite : elle est remise à plus tard jusqu'à ce que quelqu'un décide de publier quand même.

Contenus, liens et destinations des demandes

La partie la moins technique est celle qui génère le plus de faux pas, car elle concerne ce que l'entreprise déclare sur elle-même.

• Textes de test restés sur la page, images génériques à la place des vôtres, noms de personnes qui ne travaillent plus avec vous.
• Coordonnées, horaires et données de l'entreprise : ils doivent être relus par quelqu'un qui les connaît, pas par celui qui a mis en page.
• Documents téléchargeables : vérifier qu'il s'agit de la dernière version et qu'ils ne contiennent pas de tarifs ou de données que vous ne voulez pas rendre publics.
• Liens internes et externes : ceux qui pointent vers des sites tiers doivent être retestés, car un site externe peut avoir changé d'adresse pendant que vous travailliez.
• Destinations des demandes : chaque formulaire peut écrire à une boîte différente. Testez-les tous, un par un, en vérifiant aussi les courriers indésirables.
• Textes légaux et mentions d'information : ce ne sont pas du contenu de remplissage et ils ne se copient pas d'un autre site.

Les clés de la maison : accès, sauvegardes, restauration

Avant la publication, mieux vaut clarifier qui possède quoi. Maintenant, cela coûte peu ; dans trois ans, avec un prestataire différent, cela peut bloquer tout un projet.

• Le domaine enregistré au nom de l'entreprise, avec l'accès au panneau de gestion entre vos mains.
• Les accès au site, à l'espace d'hébergement et aux outils de mesure, existant aussi au nom d'une personne interne et pas seulement du prestataire.
• Si des sauvegardes sont prévues : où elles se trouvent, à quelle fréquence elles sont faites, jusqu'où en arrière elles remontent et — la question que personne ne pose — qui en a déjà testé une restauration.

Une sauvegarde jamais restaurée est une hypothèse, pas une garantie. Le test se fait une fois, sur une copie de travail, avant d'en avoir besoin.

Bloquant ou différable

Tous les défauts n'empêchent pas la publication, et les traiter tous comme urgents fait glisser la date sans raison. Trois niveaux suffisent.

1. Bloquant : le site dit du faux, une demande n'arrive pas, une page importante ne s'ouvre pas, une donnée confidentielle est visible, un parcours de contact ou d'achat s'interrompt. On ne publie pas.
2. À corriger juste après : des défauts visibles qui n'empêchent pas d'utiliser le site, comme une légende erronée, une image de mauvaise qualité, un espacement décalé sur un modèle de téléphone.
3. À évaluer : des demandes apparues pendant la recette qui sont en réalité des contenus ou des fonctions nouvelles. Elles doivent être écrites et discutées, pas glissées dans le lancement.

Le troisième point est celui qui sauve le projet. La plupart des retards naissent de demandes nouvelles présentées comme des défauts.

Quand ne pas publier, et quand publier quand même

Ce que ce guide ne couvre pas

Il est ici question de l'acceptation d'un site avant sa publication. La recette d'un système de gestion — données migrées, permissions, procédures qui remplacent une façon de travailler — suit des règles différentes et exige des tests sur des données réelles, pas sur un environnement de test. Les contrôles d'accessibilité et le recueil des besoins avant de démarrer sont eux aussi traités ailleurs.