Que se passe-t-il quand Stripe, ton email ou ton API IA tombe en panne ?

Mik Bry · 2026-08-25 · lecture ~9 min · KB · Prêt à lancer

Ton app ne fait sans doute pas tout elle-même. Quelque chose d'autre encaisse le paiement. Quelque chose d'autre envoie l'email de confirmation. Quelque chose d'autre vérifie le mot de passe, ou répond au prompt IA. Ton agent a peut-être branché plusieurs de ces services en cours de route, sans que tu voies toujours à quel point ton app en dépend. La plupart des fondateurs non-tech à qui je parle sont incapables de les nommer.

La plupart du temps, c'est sans conséquence. Ça cesse de l'être dès qu'un service ralentit, renvoie une erreur ou tombe en panne, et que ton app doit décider ce qu'elle montre à une vraie personne, à ce moment précis. Je vois souvent que personne n'a vraiment décidé comment l'app doit se comporter en cas de panne. Elle n'est simplement pas encore tombée sur ce cas-là.

01 — C'est quoi, concrètement ?

Un service externe, c'est tout ce que ton app demande à l'ordinateur d'une autre entreprise de faire à sa place. Voici l'image la plus claire que j'aie trouvée : imagine ton app comme un client au restaurant, et le service externe comme la cuisine. Ton app ne cuisine pas le plat elle-même — elle confie une commande à un serveur (l'API), le serveur porte la commande vers une cuisine qu'elle ne contrôle pas, et une assiette finit par revenir, ou pas.

Quatre types de services reviennent très souvent :

• Le paiement — souvent Stripe, parfois Paddle ou un processeur équivalent. Il traite le paiement et indique à ton app ce qui s'est passé.
• L'email — un service d'envoi comme Postmark, Resend ou SendGrid. Il livre la confirmation, le reçu, la réinitialisation de mot de passe.
• L'authentification — un fournisseur de connexion, ou un bout de cette brique, qui gère les mots de passe, les sessions, ou le « se connecter avec Google ».
• L'IA — l'API du modèle que ton produit appelle lui-même, à distinguer de l'outil d'IA que tu as utilisé pour construire l'app.

Tu n'as pas besoin de comprendre comment chacun est branché. Tu as besoin de savoir qu'ils existent, et qu'un serveur peut faire tomber une assiette, se tromper de commande, ou en apporter deux fois.

02 — Pourquoi s'en soucier si tu ne codes pas ?

Parce que quand la cuisine est fermée, ton utilisateur ne s'en prend pas à la cuisine. Il s'en prend au restaurant. Peu importe que le problème vienne de Stripe plutôt que de ton code : pour la personne qui clique sur « payer maintenant », c'est ton produit qui ne marche pas. Ce n'est pas de ta faute, et ça reste ton problème — devant ton client, c'est ton produit qu'on regarde, pas Stripe.

Le cas le plus piégeux — celui que ton app a le moins de chances de voir venir — ce n'est pas « le paiement a échoué ». C'est le paiement qui réussit alors que ton app pense qu'il a échoué.

Voici comment ça arrive. Stripe n'encaisse pas seulement le paiement — il envoie séparément à ton app une notification (un « webhook ») confirmant que la transaction est passée, et c'est généralement cette notification, pas le paiement lui-même, que ton app utilise pour mettre à jour ses propres données. Si cette notification est perdue ou retardée, les deux versions peuvent se contredire : Stripe a l'argent, ton app affiche toujours la commande en échec. Si l'app gère mal un événement dupliqué, elle peut traiter deux fois en interne le même paiement pourtant réussi.

Source : la documentation de Stripe sur les webhooks couvre exactement ce cas — les événements dupliqués et les tentatives de livraison répétées sont un comportement attendu, pas un cas limite (Stripe — gérer les événements de webhook dupliqués).

Un agent qui vise surtout à faire marcher le chemin nominal n'a aucune raison de distinguer l'échec de la notification de celui du paiement : depuis la conversation avec ton agent où tout semble avoir marché, les deux se confondent. Ce ne sont pourtant pas le même événement, et c'est exactement dans cet écart qu'un client finit facturé sans commande, ou pire.

03 — À quoi ressemble un projet bien structuré ?

Pas besoin, à ce stade, de mise en place technique compliquée pour gérer les pannes. Un projet bien structuré, c'est beaucoup plus modeste : pour chaque service externe que ton app appelle, toi ou ton agent devez pouvoir répondre à voix haute à cette question : « que se passe-t-il si celui-ci tombe en panne maintenant ? » Même si la réponse honnête est « rien — ça casse et l'utilisateur voit une erreur », c'est une vraie réponse, sur laquelle tu peux agir. « Je ne sais pas » est la seule mauvaise réponse.

Une forme utile pour cette réponse : continuer à fonctionner, même en mode dégradé. La page hors-ligne de Chrome te laisse quand même jouer au petit jeu du dinosaure au lieu d'afficher une erreur vide — le navigateur reste utile même quand le réseau ne l'est plus. Consulter ses emails en mode avion fonctionne pareil : ton client mail affiche la dernière boîte de réception synchronisée et met en file d'attente ce que tu rédiges, plutôt que de prétendre que tu n'as aucun email. Aucun des deux exemples ne cache la panne. Les deux laissent la personne devant l'écran faire quelque chose de sensé, plutôt que de fixer une impasse.

Source : Stripe présente la même idée spécifiquement pour les paiements — prévoir que la passerelle soit injoignable plutôt que supposer que ça n'arrive jamais (Stripe — que faire quand votre passerelle de paiement est en panne).

Le monitoring, c'est l'autre moitié. Un cas que je rencontre encore souvent : la première alerte vient d'un email de client mécontent. Rien ne surveillait la production. La solution n'est pas une pile d'observabilité complète — pas besoin de comparer Sentry, Datadog et Better Stack avant de lancer. Le minimum est beaucoup plus simple : une seule alerte, dans ta boîte mail, quand quelque chose casse en production. Vois ça comme un voyant moteur, pas un diagnostic complet chez un garagiste — ou comme une boîte noire d'avion, un journal de ce qui a mal tourné et quand, pour que « ça a cassé » ait un horodatage et une cause plutôt que le seul souvenir d'un client mécontent.

Source : la distinction pratique entre le logging (l'enregistrement) et l'alerting (ce qui te prévient réellement) est bien posée dans le guide de Better Stack, en anglais (Better Stack — observability vs. monitoring) ; les recommandations d'OWASP restent la référence de base, en anglais également, pour savoir quoi journaliser et comment gérer les erreurs sans risque (OWASP — Logging Cheat Sheet, OWASP — Error Handling Cheat Sheet).

Une dernière chose à vérifier : un agent peut ajouter un outil de monitoring sans jamais confirmer qu'il se déclenche vraiment. L'installer et le configurer pour te joindre, ce n'est pas pareil — vérifier ce second point fait partie du minimum.

04 — Que peux-tu demander sans risque à ton agent IA ?

Ce sont volontairement deux questions de diagnostic différentes, et je préfère que tu les poses séparément plutôt que de les fondre en une seule. La première porte sur ce que ton app fait quand quelque chose dont elle dépend tombe en panne. La seconde porte sur autre chose : est-ce que quelqu'un le saurait ? Un agent peut répondre honnêtement à chacune sans toucher une seule ligne de code — et une recherche qui ne trouve rien n'affirme pas la même chose que « il n'y a rien ici ». Si ton agent ne trouve pas de solution de repli, ou pas de monitoring, la réponse honnête est « je n'en ai pas trouvé », jamais « il n'y en a pas ».

Lis la réponse avant de passer au deuxième prompt. Une courte liste, avec pour chaque entrée un comportement clairement énoncé — même un honnête « aucune gestion trouvée » — c'est exactement ce que la section 3 appelle une vraie réponse.

Lis les deux réponses, n'agis sur aucune tout de suite. Ensemble, elles te disent où tu en es vraiment, pas ce qui « devrait » être là — et c'est le point de départ honnête avant de décider ce qui doit changer.

Cet article fait partie de la série Launch Readiness KB : un concept à la fois pour comprendre ce que le Trust Report vérifie avant de lancer ton app, d'embaucher ou de lever des fonds. Chaque article se termine par quelque chose que tu peux demander à ton agent sans modifier le code.