MMatt Senter
maintenantprojetsà proposcontactblog

← Blog

Un échec, une réussite

18 septembre 2026 · Matt Senter

Un échec, une réussite : une fenêtre de navigateur affichant une erreur 404 Page Not Found, une flèche, puis l’icône de l’application Premail avec une notification de briefing matinal indiquant Customer feedback needs your attention.

Un utilisateur m’a envoyé un retour à propos de Premail : il obtenait une erreur 404 en essayant de passer à la caisse. C’était immédiatement embarrassant. Je ne devrais rien mettre en ligne qui renvoie une 404 là où une page fonctionnelle devrait se trouver, et surtout pas au moment précis où quelqu’un essaie de me donner de l’argent.

J’ai des tests. J’ai des alertes. J’ai des alarmes d’infrastructure. Aucun d’entre eux ne l’a détecté. La personne qui se tenait de l’autre côté de mon paiement cassé, si.

Ce qui a rendu cet incident intéressant, au-delà de la frustration de le découvrir, c’est la façon dont je l’ai réellement appris. Une fonctionnalité que j’avais ajoutée à Premail quelques jours plus tôt a fait remonter le retour que tout le reste n’avait pas réussi à porter à mon attention. Mon produit a connu une défaillance, puis mon produit m’a aidé à y faire face.

Le client n’aurait pas dû être l’alarme

Il y a quelque chose de particulièrement douloureux dans un échec au moment du paiement. Quelqu’un a déjà fait le travail de trouver votre produit, de comprendre ce qu’il fait et de décider qu’il vaut la peine de payer. Et vous lui mettez une impasse devant les yeux.

Il aurait été tout à fait raisonnable que cette personne ferme l’onglet et passe à autre chose. Elle ne me devait ni rapport de bug, ni capture d’écran, ni explication sur les raisons pour lesquelles je n’obtenais pas sa commande. Elle essayait d’acheter quelque chose, pas de se porter volontaire pour l’assurance qualité.

Au lieu de cela, elle a pris le temps d’envoyer un retour. J’ai vraiment apprécié, et je lui ai offert 50 % de réduction en guise de remerciement. Elle m’a donné l’occasion de corriger un problème dont je n’aurais peut-être jamais eu connaissance autrement.

C’est aussi la partie inconfortable. Je connais la personne qui me l’a signalé. Je ne sais pas si quelqu’un d’autre a rencontré le même problème et est parti sans rien dire. Un paiement échoué peut ressembler à s’y méprendre à une personne qui a simplement décidé de ne pas acheter, à moins que vous ne détectiez réellement l’échec.

Le mien n’était pas détecté. Quelle que soit la confiance que j’avais dans mes tests et ma supervision, c’était une démonstration assez claire qu’ils avaient manqué quelque chose d’important.

L’e-mail que je devais remarquer

Mon formulaire de retour m’envoie une brève notification par e-mail m’indiquant qu’il y a un retour à examiner. C’est un petit résumé, pas le retour complet. Pour savoir ce que quelqu’un a écrit, je dois remarquer cet e-mail et aller vérifier.

Je l’avais négligé. Mais cette notification est apparue dans mon briefing matinal Premail, et j’ai immédiatement vu qu’il y avait un retour sur lequel je devais agir. Je suis allé le lire, j’ai appris le problème de paiement et je me suis mis au travail.

C’est une distinction qui mérite d’être faite : Premail n’a pas détecté la 404. Il n’a pas inspecté mon paiement, diagnostiqué le bug ni remplacé d’une manière ou d’une autre la supervision qui aurait dû le détecter. C’est le client qui a trouvé le problème. Premail a fait remonter la notification qui m’a poussé à aller lire ce qu’il avait signalé.

C’était exactement le genre de chose que je voulais que les briefings fassent, et cela s’est produit alors que je m’habituais encore moi-même à les utiliser.

Utiliser ce que je viens de construire

J’ai ajouté les briefings à Premail il y a seulement quelques jours. J’essaie de m’entraîner à ne plus ouvrir par défaut mon client de messagerie et à utiliser plutôt mes briefings comme un résumé de ce qui demande mon attention. Pour moi, c’est un changement d’habitude, pas seulement la sortie d’une fonctionnalité.

Ouvrir une boîte de réception et déterminer ce qui compte sont deux activités différentes. Je peux regarder mes e-mails sans remarquer le message précis qui devrait changer ce que je fais ensuite. Dans ce cas, une petite notification à propos d’un retour devait devenir une véritable tâche : va lire ceci et réponds.

Le briefing matinal a fait ce lien pour moi. J’ai vu quelque chose que j’avais négligé, j’ai compris que je devais agir, et j’ai agi immédiatement. Il n’y avait pas beaucoup d’ambiguïté quant à son utilité.

C’est une chose de construire une fonctionnalité parce que vous croyez qu’elle aidera les gens. C’en est une autre de la voir extraire quelque chose d’important de votre propre messagerie et changer le cours de votre matinée. J’aurais préféré un exemple moins embarrassant, mais celui-ci était plutôt convaincant.

Réparer plus que le paiement

Le problème de paiement est maintenant corrigé. J’ai aussi corrigé les alertes, les alarmes d’infrastructure et les tests qui n’ont pas réussi à le détecter. Remettre la page en état était nécessaire, mais m’arrêter là m’aurait laissé dépendre du prochain client serviable pour m’avertir quand quelque chose ne va pas.

Je ne vais pas déclarer que rien de tel ne pourra jamais se reproduire. J’ai fait des efforts pour l’empêcher la première fois, et c’est quand même arrivé. L’objectif de ces changements est d’éviter une récidive et, si elle se produit, de m’en rendre compte avant qu’un client ait à la signaler ou qu’un client potentiel abandonne en silence.

La leçon n’est certainement pas qu’un briefing matinal est un substitut acceptable aux tests et à la supervision. « Attendre que quelqu’un se plaigne, puis résumer la notification » serait une stratégie de fiabilité désastreuse. Je devais corriger les systèmes qui ont laissé le problème atteindre un client en premier lieu.

Mais j’ai aussi pu voir Premail faire quelque chose de vraiment utile après la défaillance de ces systèmes. Il a porté à mon attention un message négligé, et ce message a mené directement à un correctif.

L’échec du paiement ne devient pas moins embarrassant parce que ma propre application m’a aidé à le découvrir. Les deux choses sont vraies : j’ai laissé un client tomber sur un paiement cassé, et une fonctionnalité que je venais de construire m’a aidé à réagir. Je suis reconnaissant que le client ait pris la peine de me le dire, et content que mon briefing matinal ait fait en sorte que je le remarque.

Matt Senter

Matt Senter

Founder, entrepreneur, and CEO based in Durham, NC, with 30 years building software and 11 companies founded. Currently Founder & CEO of Senternet and Co-Founder, COO, and CTO of BeeReady, and the builder behind Orgabot, Highwire, StockCar, Premail, Comoji, and Burly. More about Matt.

© 2026 Matt Senter · Créé par Matt Senter de SenternetConçu avec OrgabotDurham, Caroline du NordConçu pour celles et ceux qui créentà proposblogOutilsConfidentialitéConditions