Qu’est-ce que la relecture de site web ? Notre cauchemar de validation, résolu

Post is also avalible in:

Dernière mise à jour : juillet 2026

Le marketing n’est pas fait pour les âmes sensibles. Surtout s’il s’agit de marketing digital et que vous devez entretenir votre propre site web. On disait autrefois qu’Internet n’oubliait jamais, mais pour les petites entreprises, ce n’était pas vraiment un problème. À moins de devenir viral, presque personne ne remarquait votre passage.

Cependant, au cours de l’année écoulée, alors que l’IA remplace peu à peu les moteurs de recherche traditionnels (quelle que soit la résistance de certains), cette formule a un peu changé. L’IA aussi n’oublie jamais ; pire, elle vous sanctionne pour des erreurs d’une manière que vous n’auriez jamais imaginée. Et cela ajoute considérablement à la complexité du marketing digital. Pourquoi est-ce que je vous parle de ça ? Eh bien, parce qu’aujourd’hui, mes amis, je vais vous raconter l’histoire des hauts et des bas de la création de sites web, et de mon expérience personnelle en la matière.

Le projet qui a révélé le problème

Le lancement d’une seule page fonctionnalité nous a montré à quel point notre processus de relecture de site web était défaillant. Écoutez, quel est le pire qui puisse arriver après la mise en ligne d’un site avec une erreur ? Un collègue (ou plusieurs) le signale ? Un utilisateur bienveillant le signale ? Un utilisateur moins bienveillant se plaint d’informations trompeuses ? Un aperçu IA le reprend et le traite comme une vérité ? Choisissez votre poison. 

Bien sûr, ce sont des erreurs bien différentes, et vous êtes certainement convaincu que cela ne pourrait jamais vous arriver. Je pensais la même chose… Jusqu’au jour où tout a changé. 

Vous savez, en tant que professionnel du marketing, il vous arrive de devoir expliquer des notions dans lesquelles vous êtes vous-même très moyen. Néanmoins, vous devez prendre ce sujet, le décomposer en ces concepts « sympas » fondamentaux, et les présenter. Le problème, c’est que vous ne comprenez toujours pas de quoi il s’agit vraiment. Et pour notre équipe, il s’agissait d’une fonctionnalité destinée aux développeurs qui a complètement changé notre façon de valider nos sites web. 

La mission consistait à créer une page fonctionnalité pour cette formidable nouveauté que les développeurs adoreraient, car elle facilite leur travail ; ils n’ont presque rien à configurer, mais le résultat a l’air d’une tâche très professionnelle et presque impossible, accomplie en un claquement de doigts. Le bruit de ce claquement de doigts venait en réalité de mon bureau, tandis que j’essayais de faire toutes les corrections en une heure et de la faire approuver par trois personnes différentes qui n’ont pas accès à l’environnement de développement. Deux fois.

Le coût de tout cela 

S’il reste le moindre doute sur ce qui s’est passé, laissez-moi vous le dire clairement : nous avons dû refaire l’intégralité de la page fonctionnalité deux fois, bien après sa publication. Oui, vous avez bien entendu. Nous avons relu et publié la même page à trois reprises. Et c’est uniquement parce que nous avons eu la chance d’avoir des relecteurs qui ont donné leur avis dès la première occasion que tout le processus n’a duré qu’un mois. À peine 31 jours pour finaliser une page composée de 4 blocs statiques et 1 bloc interactif, ce n’est vraiment pas grand-chose…  Pour référence, nous pouvons désormais en faire 3 à 4 dans le même laps de temps.

Maintenant, imaginez que vous n’ayez pas cette chance avec vos relecteurs. Chaque étape du processus prend 3 à 4 jours à approuver, et vous vous retrouvez ensuite avec une montagne de corrections à effectuer avant la fin de la semaine pour démarrer le nouveau cycle d’approbation le lundi. 

Ce que nous (et vous) avons probablement fait de travers

Il y a une raison pour laquelle certains processus de relecture de site web durent plus longtemps que d’autres, et chez nous, il y avait quatre erreurs très importantes et évidentes :

Nous ne relisions jamais réellement le site web

Le principal problème avec la relecture de site web pour nous, c’est que nous ne relisions jamais réellement un site web. Parfois, il s’agissait d’une capture d’écran d’un fragment de bloc avec une ligne rouge autour d’un élément erroné. 

Parfois, c’était un instantané de la page, enregistré en PDF. Ce n’est pas si mal, pourriez-vous penser ; au moins, Adobe permet d’annoter. Faux ! 10 % de la page n’était pas là à cause de la coupure naturelle entre les pages du PDF, si bien que nous perdions des lignes de texte ou voyions un élément coupé en deux simplement parce qu’il tombait sur un saut de page. 

La troisième option était la meilleure ; il suffisait d’exporter le site web en JPEG et de le mettre dans un outil de relecture en ligne, en priant pour que la qualité soit suffisante pour que tout le monde puisse lire le texte. Puis de passer les 3 jours ouvrés suivants à zoomer pour que cela ressemble à une page de site web. Mais au moins, il n’y avait pas de parties manquantes ni de retours tronqués.

Nous ne pouvions jamais approuver les éléments interactifs

Autre problème : nous n’étions jamais en mesure d’approuver les éléments interactifs, les boutons et les différents résultats. Une capture d’écran ne montre pas ce qui se passe lorsque vous survolez une carte, à quoi ressemble un menu déroulant ouvert plutôt que fermé, ni si un formulaire s’envoie réellement au lieu de rester simplement là, joli. Tout ressemblait à un visuel, pas à une page. Nous approuvions l’apparence figée d’un site web, pas ce qu’il faisait réellement une fois que quelqu’un interagissait avec.

Et comme rien de tout cela ne pouvait être jugé à partir d’un export statique, une autre personne devait passer en revue tous les boutons, animations et résultats séparément, à la main, en cliquant sur chaque élément du site en ligne pour confirmer qu’il fonctionnait réellement. Une tâche peu agréable, et pas rapide non plus. Le fait que cela se produise toujours après l’approbation « officielle » n’aidait pas, si bien que cela ressemblait moins à de l’assurance qualité qu’à découvrir, au pire moment possible, que ce que tout le monde venait de valider était en réalité discrètement cassé. Et quelque chose ne fonctionnait jamais. Alors, une semaine sur deux, je passais une demi-heure à rédiger un e-mail contrit expliquant pourquoi le lancement était de nouveau retardé.

Les retours vivaient dans trois endroits différents à la fois

Chaque format que nous utilisions pour la relecture de site web devenait son propre canal de retours indépendant. Vous voyez, avoir trois « formats » de site web différents signifiait aussi avoir automatiquement trois sources de retours différentes. Nous avions des annotations dans l’outil, un peu plus dans le PDF, puis encore davantage dans des messages privés et certains dans des groupes. 

Alors, ce que nous finissions généralement par faire, c’était que je prenais une capture d’écran de chaque retour reçu, puis je la mettais dans un document Google sous forme de liste de contrôle. Et à chaque modification effectuée, je revenais à ce document et cochais un élément supplémentaire. Assez pratique, mais un cauchemar à organiser et à peine fonctionnel. Comme cet ordinateur portable qui défie les lois de la physique depuis plusieurs années en continuant simplement de fonctionner.

Les relecteurs ne pouvaient pas suivre ce qui avait déjà changé

Nous n’avions également aucun moyen de montrer aux relecteurs ce qui avait changé depuis leur dernière série de remarques. Et mon passage préféré de tout le processus, c’est le « Oh, avez-vous vraiment changé ce que je vous avais demandé il y a deux itérations ? » Je sais que ce n’est pas fait méchamment, et je comprends que le changement était minime et presque invisible, mais j’y ai passé deux heures, et pour moi, c’est très visible.

Mais c’est ce qui finit toujours par arriver lorsque vous recevez des approbations de personnes qui ont elles-mêmes énormément de travail, et qu’il n’existe aucun rappel de l’apparence antérieure de la page. Et envoyer les deux versions n’est pas non plus une option, à moins d’apposer un gros tampon « obsolète » sur toute la page, comme un triste filigrane.

Pourquoi nous avons finalement décidé de régler ce problème

Avant l’incident de la page fonctionnalité, tout ce processus n’était qu’une gêne. Certains voulaient simplement avancer et ne prêtaient pas vraiment attention au contenu de la page. D’autres n’avaient pas les accès nécessaires, alors ils demandaient soit une version statique, soit ne regardaient tout simplement pas la page une fois mise en ligne. 

Cependant, après l’incident de la page fonctionnalité, des informations incorrectes sont restées affichées en ligne pendant un moment, et l’IA les a reprises presque immédiatement ; un consensus s’est alors dégagé pour dire qu’il fallait agir. Dans un premier temps, nous avons cherché à l’extérieur des plugins, des outils supplémentaires ou des ponts API permettant de charger le site web dans un outil de relecture. 

Mais ensuite (assez rapidement en réalité), nous avons compris que la réponse était juste sous nos yeux. Nous disposions déjà d’un outil de relecture, de plusieurs clients qui en avaient besoin dans leur flux de travail, et de notre propre motivation interne à disposer d’un moyen de relire nos sites web. Alors, nous avons décidé que plutôt que de le chercher ailleurs, nous devions le construire. 

Qu’est-ce que la relecture de site web ?

La relecture de site web consiste à examiner un site web en ligne ou en préproduction sur ordinateur, tablette et mobile avant sa mise en public, avec des commentaires épinglés à l’endroit exact de la page. Elle remplace les captures d’écran, les PDF et les fils d’e-mails par un seul endroit où voir, naviguer et approuver le site tel qu’il fonctionnera réellement.

Un outil qui fait cela s’appelle un outil de relecture (ou de révision) de site web. C’est une plateforme centralisée qui vous permet de relire et d’annoter des sites web ou des pages spécifiques de manière interactive. Cela signifie que vous pouvez cliquer sur des boutons, visionner des animations et naviguer sur le site tout en pouvant laisser des commentaires épinglés. 

Alors, maintenant, au lieu de passer par toute la procédure d’exportation et d’envoi d’un site web statique, il me suffit de saisir son URL, d’ajouter les adresses e-mail de toutes les personnes qui doivent l’approuver, et de cliquer sur envoyer. Ou, encore plus simple, je copie simplement le lien et l’envoie dans le groupe de discussion, et désormais tout le monde peut donner son avis sur une page sur laquelle j’ai passé deux jours ! 

Il existe déjà quelques outils de relecture de site web sur le marché, certains conçus spécifiquement pour les sites web (BugHerd, Pastel), et d’autres outils de relecture en ligne plus généraux avec la relecture de site web en plus, comme PageProof. Mais aucun d’entre eux n’existait au sein de notre propre flux de travail au moment où nous en avions le plus besoin. Nous avons donc décidé de prendre la voie la plus simple et d’en construire un nous-mêmes.

Comment la relecture de site web a résolu chacun de ces problèmes

Et cet outil de relecture de site web a très bien résolu bon nombre de nos déconvenues internes, alors nous avons décidé qu’il fonctionnait suffisamment bien pour vous le présenter. Et pour ne faire aucune affirmation infondée, laissez-moi vous montrer en quoi un outil de relecture de site web nous a grandement facilité la vie. 

Si tout cela vous semble familier, c’est parce qu’il s’agit d’une version à plus fort enjeu d’un problème dont nous avons déjà parlé : pourquoi la méthode traditionnelle vous fait perdre du temps. Les captures d’écran et les fils d’e-mails sont lents, peu importe ce que vous approuvez.

Ce qu’un outil de relecture de site web devrait avoir

Après avoir vécu les différentes variantes de la « relecture de site web », j’ai mon avis sur ce qui distingue un véritable outil de relecture d’une solution de contournement déguisée en outil de relecture. Pour moi, tout s’est toujours résumé à la rapidité avec laquelle on peut l’envoyer en relecture et à la facilité avec laquelle les autres peuvent y accéder. Alors, voici ce que je considère comme non négociable, de la part de quelqu’un qui a testé toutes les mauvaises façons de procéder en premier :

• Charge la véritable page en ligne ou en préproduction, et non une capture d’écran, un PDF ou un export JPEG de celle-ci
• Vous permet de basculer entre les vues ordinateur, tablette et mobile sans ouvrir trois onglets séparés
• Vous permet de cliquer sur des boutons, de déclencher des animations et de naviguer vers des pages liées
• Épingle les commentaires à l’endroit exact de la page au lieu de les disperser
• Suit les versions, afin que personne ne signale à nouveau quelque chose que vous avez déjà corrigé deux tours plus tôt
• Fonctionne à partir d’un seul lien partageable, afin que n’importe qui puisse donner son avis, qu’il ait des accès de développement ou non
• Produit un rapport final de ce qui a été approuvé, et par qui, afin qu’il existe une véritable trace écrite en cas de question

Si un outil ne coche pas la plupart de ces cases, vous êtes honnêtement en train de relire une rumeur de site web. Et ce n’est pas une bonne position dans laquelle se trouver. 

Qui a vraiment besoin d’un outil de relecture de site web

Mais tout le monde n’en a pas besoin. Si vous êtes un développeur solo qui met en ligne son propre portfolio, bon courage, vous n’avez probablement pas besoin que votre mère épingle des commentaires sur votre section héro. Mais si plus d’une personne doit valider une page avant sa mise en ligne, et surtout si certaines de ces personnes n’ont pas la patience d’un développeur pour les environnements de préproduction, alors ceci est fait pour vous. Alors, si vous êtes :

• Une équipe marketing et/ou créative qui lance ou actualise un site
• Quelqu’un à qui on a déjà demandé « avez-vous fait ces changements depuis novembre ? » par un relecteur n’ayant aucun souvenir de l’apparence de la page
• Des équipes où le service juridique, un manager, ou un autre département doit valider avant toute mise en ligne, sans pouvoir accéder à un environnement de développement
• Des agences qui remettent un site terminé à un client souhaitant un enregistrement propre et exportable de ce qui a réellement été approuvé
• Des équipes de développement lassées d’être les seules personnes pouvant ouvrir le lien de préproduction, et qui aimeraient beaucoup arrêter de recevoir des retours sur leurs blocs interactifs une fois en production

Si vous avez lu cette liste et hoché la tête à plus d’un élément, vous savez déjà pourquoi nous avons construit cela.

En résumé

Bon, vous vous demandez peut-être pourquoi j’ai passé autant de temps et de mots sur mes propres cauchemars d’approbation. C’est une question légitime. La réponse courte, c’est que c’est l’histoire d’Approval Studio, pas une histoire hypothétique. Nous n’avons pas étudié ce problème de l’extérieur. Nous l’avons vécu de l’intérieur, avons refait la même page trois fois, gardé un Google Doc comme source de vérité parce que rien d’autre n’était assez fiable, et on nous a demandé « au fait, vous avez fait le changement ? » plus de fois que je ne suis prêt à l’admettre par écrit.

Alors nous avons construit notre propre fonctionnalité de relecture de site web pour régler ce problème, nous l’avons testée en interne sur nos propres lancements jusqu’à ce que nous lui fassions vraiment confiance (pas seulement en espérant qu’elle fonctionne), et maintenant nous sommes prêts à la proposer à davantage de personnes. Si vous préférez ne pas écrire votre propre version de cette histoire, inscrivez-vous sur la liste d’attente. Nous vous préviendrons dès sa mise en ligne, et vous n’aurez plus jamais à expliquer un bouton cassé à votre manager après un lancement.