En bref
Flowsery a analysé 75 167 enregistrements de session d'adaptlypost.com en un mois et trouvé 3 338 échecs réels issus de 66 causes distinctes. Neuf de ces échecs sur dix n'ont levé aucune erreur console ni réseau, et les sessions qui portaient bien une erreur étaient un échec réel dans 2,8 % des cas. Quatre constats suivent, classés par ce qu'ils coûtent plutôt que par leur fréquence.
Entre le 13 juillet et le 13 août 2026, Flowsery a analysé 75 167 enregistrements de session d'adaptlypost.com et en a signalé 3 338 comme un échec réel pour le visiteur. Le regroupement par cause a ramené ce total à 66 bugs distincts : un critique, sept élevés, quinze moyens, quarante-trois faibles.
3 019 des 3 338 échecs ne portaient aucune erreur console ni erreur réseau. Neuf sur dix. Sur le même mois, 11 598 sessions portaient bien une erreur, et 319 d'entre elles étaient un échec réel. Un moniteur d'erreurs aurait alerté sur les mauvaises onze mille sessions et dormi pendant les trois mille qui comptaient.
Les quatre constats ci-dessous sont classés par ce qu'ils coûtent, pas par leur fréquence.
À propos d'AdaptlyPost
AdaptlyPost est un planificateur de réseaux sociaux vendu avec un essai de 7 jours. Il publie en cinq langues et a un blog dont Google indexe le glossaire. AdaptlyPost et Flowsery ont le même fondateur.
Comment l'étude s'est déroulée
L'enregistrement des sessions tournait sur le site depuis environ deux mois quand l'analyse IA a été activée, le 13 juillet 2026. Cette étude couvre exactement un mois à partir de cette date. Les 75 167 enregistrements sont cet arriéré plus tout ce que le trafic en direct a produit pendant que le pipeline tournait.
Un enregistrement compte comme un échec quand le visiteur a tenté de faire quelque chose que la page proposait et que la page ne l'a pas fourni. Un refus de carte n'est pas un échec, parce qu'une banque qui dit non n'est pas un bug. Un bouton de paiement qui ne fait rien au clic en est un. Chaque échec porte une sévérité, des étapes de reproduction et un lien vers l'enregistrement. Les échecs ayant la même cause sont regroupés, et c'est ainsi que 3 338 sont devenus 66.
Constat 1 : le paiement bloquait les règlements de cinq façons différentes
Sept sessions sur la fenêtre se sont terminées par un paiement bloqué par le site lui-même, de cinq façons distinctes.
Deux des cinq, les erreurs serveur, apparaîtraient dans un traqueur d'erreurs. La règle de facturation, c'est le système de paiement fonctionnant comme prévu, refusant un client qui veut payer davantage. Le bouton PayPal mort ne lève absolument rien. La page de changement d'offre manquante est un 404, et les 404 sont du bruit de fond sur n'importe quel site.
Le seul problème critique était sur la page de connexion française. Un visiteur a soumis le formulaire et la page a affiché "400: Bad Request", très probablement parce que le widget anti-bot ne s'est jamais chargé. Il est parti. Un formulaire de connexion devrait dire "E-mail ou mot de passe invalide", pas afficher un code HTTP.
Constat 2 : un seul contrôle avalait les clics sur 17 routes
48 sessions réparties sur 17 routes différentes montrent le même schéma. Un visiteur clique sur un sélecteur, rien de visible ne se passe, il reclique, et encore, puis il part.
C'est un seul composant, réutilisé sur chaque page qui demande au visiteur de choisir quelque chose.
- Sur l'éditeur de publication allemand, un client connecté ouvre les réglages Pinterest et clique "choose board" à répétition. Le menu déroulant ne s'ouvre jamais. Il clique "post now" quand même. La publication ne part jamais.
- Sur le générateur de publications IA, "Select Platform" ne produit aucune réponse malgré des clics répétés. Le visiteur renonce et clique sur le titre de la page.
- Sur le calculateur de tarifs d'influenceurs, le bouton de niveau d'engagement ignore six secondes de clics insistants avant d'enregistrer enfin.
- Sur le vérificateur de disponibilité de pseudo, trois clics sur la liste des plateformes ne font rien. Le visiteur n'atteint jamais "Check Availability".
Aucun ne lève d'exception. À chaque fois, un gestionnaire de clic tire dans un composant dont l'état visuel ne se met jamais à jour, si bien que le visiteur ne peut pas distinguer "ignoré" de "cassé". Les clics de rage sont le seul signal, et ce signal n'existe qu'à l'intérieur d'un enregistrement.
Constat 3 : les traductions qui ne se sont pas chargées
AdaptlyPost publie en cinq langues, et les coutures se voient. Neuf sessions sur la fenêtre, sur quatre routes, se sont terminées avec le visiteur devant quelque chose qui n'était jamais censé être du texte : une clé de traduction, une page d'erreur dans la mauvaise langue ou un texte de remplissage.
| Ce que le visiteur a vu | Sessions | Où | Signal d'erreur |
|---|---|---|---|
| Des clés de traduction en guise de texte | 5 | /en/media-kit | Aucun |
| Une page 500 après un changement de langue | 2 | Page d'accueil | HTTP 500 |
| Des fichiers JSON de langue en 404 | 2 | Analyseur de niveau de lecture, un article de blog | 404 en arrière-plan |
La page media kit est le cas le plus net. Cinq visiteurs y ont atterri et ont vu "brandFacts.mediaKit.title" et "brandFacts.mediaKit.description" à la place du titre et du texte. Aucun n'a cliqué. La page a renvoyé un 200 sans erreur console, donc rien ne l'a signalée.
brandFacts.mediaKit.eyebrow
brandFacts.mediaKit.title
brandFacts.mediaKit.description
brandFacts.mediaKit.assetsDescription
Passer en portugais a produit une page 500 affichant "Ocorreu um erro inesperado". Le bouton de réessai a chargé la page d'accueil portugaise, et 17 minutes plus tard le même 500 est revenu. Un autre visiteur a eu, sur la page d'accueil anglaise, un overlay 500 dont le bouton de réessai disait "Intentar otra vez", de l'espagnol sur une page anglaise.
Le sélecteur de langue demande aussi des fichiers de langue qui n'existent pas. Une session sur l'analyseur de niveau de lecture a enregistré 24 erreurs 404 en arrière-plan pour des fichiers comme /locales/fr/gdpr.json. Passer un article de blog en espagnol a fait la même chose.
Après la fermeture de la fenêtre, le 18 août, la version espagnole du guide des zones sûres est sortie avec le texte de remplissage "Original text" comme titre principal.
Rien de tout cela ne lève une erreur utile. Les clés brutes et le texte de remplissage sont une page qui affiche la mauvaise chaîne. Les 404 de langue sont des requêtes en arrière-plan que personne ne regarde. Seules les pages 500 alerteraient quelqu'un, et l'une d'elles a disparu d'elle-même au réessai.
Constat 4 : les URL de glossaire qui renvoient 404
Le plus gros constat en nombre de sessions, et le plus ennuyeux, ce qui explique qu'il ait duré aussi longtemps.
Les articles de glossaire d'AdaptlyPost vivent sous /blog/<slug>. À un moment, ils ont été publiés, puis indexés, sous /blog/glossary-<slug>. Le site n'a aucune route pour la forme préfixée.
- 382 URL
/blog/glossary-*distinctes sont apparues dans des échecs, sur 1 287 sessions - L'essentiel de ce trafic arrivait directement d'un résultat de recherche
- Dix slugs échantillonnés et confrontés au répertoire de contenu : huit des dix articles existent, à l'URL sans préfixe
Les articles existent et se positionnent. L'URL que Google a indexée ne pointe sur rien, et une seule règle de redirection corrigerait ça.
Ce que la supervision des erreurs a vu
Sur les 75 167 enregistrements analysés, 11 598 portaient une erreur console ou réseau. 319 d'entre eux étaient un échec réel, visible par le visiteur. Soit 2,8 % de précision. Ouvrez les replays filtrés sur "contient des erreurs" et 97 sur 100 seront un traqueur bloqué ou un fetch annulé.
L'autre sens est pire. Sur les 3 338 échecs réels, 3 019 ne portaient aucune erreur. L'essentiel de ce qui précède vit dans ces 90 % : le bouton PayPal mort, la règle de facturation, les clics avalés, la page media kit qui affiche ses clés de traduction.
D'un replay à un changement relisible
Le lendemain de la fermeture de la fenêtre, l'agent de Flowsery a repris le problème du sélecteur d'engagement du constat 2, lu l'enregistrement et ouvert une pull request sur le code d'AdaptlyPost.
Sa lecture du bug : taper une option mettait à jour un état que le visiteur ne pouvait pas voir, donc rien ne changeait à l'écran et l'enregistreur a capté dix clics sans réponse. Le changement recâble le contrôle pour qu'il se comporte comme les sélecteurs du site qui fonctionnent déjà. Un commit, un fichier.
Où en sont les choses
| Constat | Sessions sur la fenêtre | Signal d'erreur | Statut |
|---|---|---|---|
| Paiement bloqué, cinq façons | 7 | 2 modes sur 5 | Corrigé |
| 400 brut à la connexion | 1 | HTTP 400 | Corrigé |
| Sélecteur avalant les clics | 48, sur 17 routes | Aucun | Corrigé |
| Traductions non chargées | 9, sur 4 routes | 3 sur 9 | Corrigé |
| URL de glossaire renvoyant 404 | 1 287 | HTTP 404 | Corrigé |
Ce qui a changé en un mois, c'est la forme de l'arriéré. Avant le 13 juillet, c'était ce que quelqu'un remarquait par hasard. Après, c'est une liste classée où chaque entrée porte un nombre de sessions, une date de première apparition, une sévérité, des étapes de reproduction et un enregistrement à ouvrir.
"On devrait regarder le paiement" perd contre un élément de roadmap. "Sept personnes ont voulu payer et le paiement les a bloquées, de cinq façons différentes, et voici l'enregistrement de l'une d'elles" ne perd pas.
Ce qui se généralise
- Un 200 avec une page entièrement rendue
- Un 200 transportant un message d'erreur
- Un gestionnaire de clic qui s'est déclenché normalement
- 11 598 sessions marquées, 319 réellement en échec
- Un titre qui dit brandFacts.mediaKit.title
- Un client payant à qui on refuse un changement d'offre
- Dix clics sans réponse, puis le visiteur qui s'en va
- 3 338 échecs réels, 66 causes distinctes
Classez par coût, pas par volume. Les 404 du glossaire ont touché 1 287 sessions et ceux du paiement en ont touché sept, et ceux du paiement valent plus.
Traitez les contrôles silencieux comme des bugs sans télémétrie. Un menu déroulant mort ne lève rien, ne journalise rien et renvoie 200. La seule preuve de son existence, c'est une personne cliquant dix fois au même endroit, et cette preuve est dans l'enregistrement ou nulle part.
Lisez ce que la page affiche, pas ce que le serveur a renvoyé. Un titre qui dit brandFacts.mediaKit.title est un 200 sans erreur console, et une page espagnole dont le titre principal est "Original text" aussi. Ni l'un ni l'autre n'apparaît comme une chute d'entonnoir, parce que le visiteur n'y est jamais entré.