690 retours sur un site : comment je les traite, et comment bien faire relire le vôtre

Retours client sur un site web : ce que j'appelle un ticket

Un ticket, c'est une demande, une seule, qu'on peut cocher quand elle est faite.

• « Remplacer ce paragraphe par celui-ci » : un ticket.
• « Revoir la FAQ » : autant de tickets que de questions dans la FAQ.
• « Le bouton du bas, on le garde » : un ticket aussi. Il ne demande rien, mais il tranche, et je dois le savoir.

Pourquoi compter ? Parce qu'un retour qui n'est pas compté est un retour qu'on oublie. Sur 690, en oublier 2 %, c'est 14 corrections que le client retrouvera en ligne, et il aura raison d'être agacé. Le chiffre ne sert donc pas à me plaindre. Il sert à tout retrouver.

Le client, lui, n'a pas besoin du mot. Il a besoin de savoir que chaque phrase de ses mails a été lue et qu'elle a une réponse : faite, en attente, ou à discuter.

Ce que contenaient les 690 retours

Avant de toucher au site, j'ai tout mis dans un tableau : une ligne par demande, avec la page, le bloc concerné, le texte actuel et le texte voulu. Puis j'ai trié par nature.

Les 690 retours, par nature

Zéro bug. Pas un lien cassé, pas un formulaire en panne. Le site marchait.

82 % des retours portaient sur le texte. Et c'est normal. Les textes de départ, c'est moi qui les avais écrits, à partir de ce que je savais de son métier. Lui connaît son métier mieux que moi, ses clients aussi. Qu'il réécrive, c'est exactement le but d'une relecture. Un client qui renvoie 566 textes réécrits est un client qui a lu son site. Le cas qui m'inquiète, au contraire, c'est l'inverse : celui qui valide tout en dix minutes et découvre ses textes six mois plus tard, en ligne, devant un prospect.

Trier avant de toucher à quoi que ce soit

Les retours n'appellent pas tous le même geste. Avant la première modification, chaque ticket reçoit une étiquette.

1. Une correction (un texte, un chiffre, une faute) : je la pose, mot pour mot. Je ne réécris pas le texte du client, même quand je l'aurais tourné autrement. C'est son site, c'est sa voix.
2. Un changement de structure (supprimer, ajouter, déplacer un bloc) : je le pose si le bloc existe dans la maquette validée. Retirer une section, oui. Inventer un nouveau type de bloc, c'est autre chose (point 4).
3. Une question : je ne tranche pas à sa place. Le ticket reste en l'état, noté « en attente », et la question part dans le mail de retour.
4. Une nouvelle fonctionnalité : elle sort du lot. Ici, il y en avait une, un module externe fourni par un partenaire du client, à intégrer dans une page. Je la chiffre avant de la faire, et je la pose après son accord écrit.
5. Un bug : je le répare, toujours, sans discuter ni facturer. Ici, la case est restée vide.

Ce qui n'est pas cité ne bouge pas

Une règle m'a servi plus que toutes les autres, et c'est le client qui l'a écrite dans sa synthèse : « Si je ne parle pas d'un paragraphe, c'est qu'il est validé. »

Donc je ne touche à rien qui n'est pas cité. Même quand un texte non cité contredit une demande voisine. Un cas vécu : il retirait une promesse d'un paragraphe, mais la même promesse restait dans la description de la page pour Google, qu'il n'avait pas relue. Je ne l'ai pas corrigée en douce. Je lui ai envoyé la liste de ces textes non cités, avec une réécriture proposée pour chacun. Il valide, je pose. Sinon, ça reste comme c'est.

Ça paraît rigide. Pourtant, c'est ce qui évite le « je n'ai jamais demandé ça » trois semaines plus tard.

Le forfait, dit avant et pas après

Le devis comprenait une série de retouches par page. Cette relecture, c'était cette série.

Ce qui en sort, je l'avais écrit au client avant qu'il relise. Une deuxième passe complète sur une page, ou un bloc qui n'existe pas dans la maquette, je le dis avant de le faire, avec le prix. Jamais après. Une facture surprise en fin de projet, c'est la meilleure façon de perdre un client content.

Sur les 690 retours, 4 seulement sortaient du simple contenu. Le reste était dans le forfait, et je l'ai posé sans discuter. Le prix de l'heure hors forfait est affiché sur la grille des tarifs, pas caché dans un coin du devis.

Comment je les ai posés, en moins de 24 heures

Mails reçus le mardi soir. Le mercredi soir, les 24 pages étaient en ligne avec 594 retours posés mot pour mot. Le reste attend une réponse ou un accord : les questions, la fonctionnalité nouvelle, les textes non cités.

L'ordre :

1. Une sauvegarde complète du site, puis un export de chaque page avant modification. Si une page sort de travers, je la remets dans l'état de la veille en une commande. C'est la première étape de tout chantier, je l'explique dans le guide de la sauvegarde d'un site web.
2. Les changements communs à toutes les pages d'abord, une seule fois : un bloc retiré partout, une règle de couleur des fonds. Puis un contrôle que les pages non concernées n'ont pas bougé.
3. Une page pilote, faite et vérifiée à la main. Elle sert de modèle aux 23 autres.
4. Les pages par groupe, chaque ticket coché un par un dans le tableau.
5. La mise en ligne page par page, pas tout d'un bloc.
6. La recette : chaque ticket comparé à la page en ligne, sur ordinateur et sur téléphone.

Je me fais aider par des agents IA pour la lecture des 25 mails, le tri et la recette. C'est pour ça que 690 lignes restent tenables en une journée. Mais les textes du client sont posés tels qu'il les a écrits, jamais réécrits par la machine. Et les arbitrages (ce qui entre dans le forfait, ce qu'on demande au client) restent les miens.

Au fil du tri, j'avais noté 57 questions. Comme beaucoup se répétaient d'une page à l'autre, il en reste 20 dans le mail de retour, regroupées, chacune avec une proposition. Personne n'a envie de répondre à 57 questions un jeudi.

Ce que ça coûte en machine

Des agents IA, ça ne tourne pas à l'air. Ça se compte en tokens, les morceaux de texte que le modèle lit et écrit. J'ai relu les journaux de Claude Code sur mon PC, un fichier par session, chaque réponse comptée une seule fois, sous-agents compris.

La relecture des 690 retours, c'est une session de trois heures, le mercredi en fin de journée :

• 110,6 millions de tokens ;
• 415 appels au modèle, dont 185 faits par des sous-agents (lecture, pose et recette, un par groupe de pages) ;
• 96,8 % de ce volume, c'est du contexte relu à chaque tour ;
• ce que la machine a écrit elle-même : 0,7 million de tokens.

Le mail de retour, la nuit suivante, en ajoute 9,1 millions. Et ce client, sur tout son projet depuis mi-septembre : 2,02 milliards de tokens, en 69 sessions.

Le compteur du studio

Pour l'échelle, tout le studio depuis le 10 juin 2026 : 21,8 milliards de tokens, en 857 sessions et 82 687 appels au modèle.

Octobre va environ deux fois plus vite que septembre. Neuf tokens sur dix passent par deux modèles, Opus 5 et Opus 5.5.

Le détail qui compte : 97,5 % du total, ce sont des lectures de cache. Le modèle relit tout le contexte de la conversation à chaque tour, et une lecture de cache est facturée un dixième d'une entrée normale. Ce que Claude a écrit lui-même sur ces quatre mois tient en 85,8 millions de tokens, moins de 0,4 % du compteur. Je ne le traduis pas en euros : ça dépend de la formule d'abonnement, et je préfère publier un chiffre mesuré qu'un prix estimé.

Ce que ces chiffres ne couvrent pas : les conversations sur claude.ai (web et mobile), les sessions dans le cloud, mes autres machines, et les journaux que Claude Code a déjà purgés. Juin ne compte que 127 appels, ce qui ressemble plus à une purge qu'à un mois calme.

Pourquoi ça vous concerne ? Parce que le gros de la facture, c'est le contexte relu à chaque tour. Une demande floue, c'est un tour de plus pour la comprendre, puis un autre pour vérifier. Un mail par page, avec le texte actuel et le texte voulu, c'est moins d'allers-retours, pour moi comme pour la machine.

Et après

Les questions sont parties chez le client, avec la liste des textes non cités et le chiffrage de la fonctionnalité nouvelle. Ses réponses arrivent, je pose, on vérifie ensemble, et on met en production. Sans faute, c'est la promesse que je lui ai faite le soir où il ne comprenait pas mes tickets.

690 retours, c'est beaucoup. Mais un client qui relit chaque ligne de son site, c'est un site qu'il défendra devant ses propres clients. Je préfère ça à un « c'est parfait » envoyé sans avoir lu.

C'est la phase de relecture qui fait partie de chaque création ou refonte de site. Une fois le site en ligne, le même tableau continue de tourner dans le contrat d'assistance et de maintenance : une demande, une ligne, une case cochée. C'est comme ça que je tiens le site de Tour'n'sol Prod depuis la rentrée.