Comment je mettrais le support client d'un store d'abonnements en pilote automatique

Après les deux derniers articles, tu as compris que j’aime partir d’un problème concret.

Cette fois, je ne pars pas d’une question ratée en entretien. Je pars d’un chantier que je prendrais demain matin.

Imagine un store d’abonnements. Des milliers de clients qui paient chaque mois. Et une boîte de support qui déborde.

La plupart des gens répondent à ça par « on recrute deux agents de plus ». Moi, je regarde la ligne de facture.

Parce qu’un support d’abonnements, c’est 80% de tickets qui reviennent tous les jours. « Comment j’annule ? » « Mon paiement a échoué. » « Où en est ma commande ? » Ces tickets-là ne demandent pas de l’intelligence. Ils demandent de la constance. Et la constance, c’est exactement ce qu’un agent IA bien encadré fait mieux qu’un humain fatigué à 18h.

Voici comment je m’y prendrais. Pas en théorie. En opérateur.

Semaine 1 : apprendre le terrain avant de coder

La première erreur, ce serait d’ouvrir un éditeur lundi matin.

Pendant une semaine, je ne code rien. Je tague les vrais tickets.

Chaque ticket qui rentre, je lui colle une étiquette : intent, canal, temps de résolution, escalade ou pas. À la main s’il le faut. C’est chiant. C’est le meilleur investissement du projet.

Parce qu’au bout de sept jours, tu ne regardes plus un mur de tickets. Tu regardes une distribution.

Et cette distribution dit toujours la même chose : 5 à 7 intents font 80% du volume.

Sur un store d’abonnements, ces intents sont presque toujours :

annulation d’abonnement
paiement échoué
statut de commande / livraison
demande de remboursement
changement de plan ou de fréquence
« où sont mes accès / mon contenu ? »
mise à jour du moyen de paiement

Sept intents. Voilà ta cible.

Je ne construis pas un agent qui « répond à tout ». Je construis un agent qui écrase ces sept intents-là, parfaitement, et qui passe la main pour le reste.

C’est la première décision d’opérateur : tu ne veux pas 100% de couverture, tu veux 80% du volume absorbé sans erreur.

Tagger d’abord, coder ensuite. Sinon tu automatises ton intuition, pas ton trafic réel.

L’architecture : trois couches de données, une policy dans le code

Un agent de support qui ne connaît que la FAQ est inutile. Il répond « voici notre politique de remboursement » quand le client veut savoir où en est son remboursement à lui.

La différence entre un chatbot et un agent utile, c’est l’accès aux données. À trois couches de données.

Couche 1 — statique

La FAQ, les conditions, les politiques, les délais de livraison standard. Ça ne bouge pas d’un client à l’autre. Ça peut vivre dans un index de recherche ou un simple contexte injecté.

C’est la couche la plus facile. C’est aussi la moins utile seule.

Couche 2 — dynamique

Le statut réel. La commande #4821 est expédiée. L’abonnement est actif jusqu’au 3 août. Le dernier paiement a échoué hier.

Cette couche, l’agent ne la « sait » pas. Il va la chercher via des tools, au moment où il en a besoin.

Couche 3 — privée

Le compte client. Identité, historique, moyens de paiement, droits. La couche sensible. Celle où une erreur coûte cher.

L’agent n’y touche jamais en accès libre. Il passe par des tools typés, avec des règles en dur.

Et c’est là qu’arrive la décision d’architecture la plus importante.

La policy dans le code, pas dans le prompt

Beaucoup de gens écrivent leurs règles métier dans le prompt système. « Ne rembourse pas au-delà de 30 jours. » « N’annule pas sans confirmer. »

C’est une erreur.

Un prompt, c’est une suggestion. Un modèle peut la contourner, l’oublier, mal l’interpréter sous la bonne formulation d’un client énervé.

Une règle en dur dans le code, c’est une garantie.

Alors je ne mets pas la policy dans le prompt. Je la mets dans le tool.

// La règle métier vit ICI, dans le code.
// Le modèle ne peut que "demander" — il ne décide pas seul.
async function cancelSubscription(customerId: string, reason: string) {
  const sub = await billing.getSubscription(customerId);

  if (!sub || sub.status !== "active") {
    return { ok: false, message: "Aucun abonnement actif à annuler." };
  }

  // Policy en dur : on propose TOUJOURS une save offer d'abord.
  // Le modèle ne peut pas sauter cette étape, même si le client insiste.
  if (!sub.saveOfferShown) {
    await billing.flagSaveOfferShown(customerId);
    return { ok: false, requiresSaveOffer: true, offer: pickSaveOffer(sub) };
  }

  await billing.scheduleCancellation(customerId, reason);
  return { ok: true, effectiveDate: sub.currentPeriodEnd };
}

Regarde ce que fait ce tool.

Le modèle demande une annulation. Le code décide. Pas d’abonnement actif ? Refus propre. Save offer pas encore montrée ? Le tool refuse et renvoie l’offre à présenter. Le modèle ne peut pas court-circuiter la règle métier, même si le client écrit « annule tout, tout de suite, je m’en fiche ».

C’est ça, la policy as code : les décisions à risque ne dépendent pas de l’humeur d’un modèle. Elles dépendent d’une fonction que tu as écrite, testée, et que tu peux prouver.

Le prompt gère le ton et la conversation. Le code gère l’argent et les droits.

Cette séparation, c’est la colonne vertébrale de tout le système.

Les plays spécifiques aux abonnements

Un support d’abonnements, ce n’est pas un support générique. Il y a trois moments où l’argent se joue. Je les traite comme des flows dédiés.

Le flow d’annulation avec save offers

L’annulation, ce n’est pas une fin. C’est une conversation.

Quand un client veut annuler, l’agent ne dit pas « c’est fait, au revoir ». Il écoute la raison. Trop cher ? Pas assez utilisé ? Une pause suffirait ?

Et selon la raison, il propose la bonne save offer :

un mois offert pour le client qui trouve ça cher
une pause de 2 mois pour celui qui part en déplacement
un downgrade vers un plan moins cher pour celui qui sur-consomme un abonnement premium

Chaque save offer réussie, c’est du MRR conservé. Un client à 15€/mois qu’on garde 6 mois de plus, c’est 90€ qui restent. Sur des milliers de clients, ça devient la ligne la plus rentable du système.

La règle « toujours proposer une offre avant d’annuler » est dans le code, pas dans le prompt. Le modèle choisit comment le dire. Le code garantit que c’est dit.

Le recovery de paiements échoués (dunning)

Un paiement échoué, ce n’est presque jamais un client qui part. C’est une carte expirée. Un plafond atteint. Un virement en attente.

Sans système, ce client churne pour rien.

L’agent gère le dunning proactivement :

il détecte l’échec via la couche dynamique
il contacte le client avec le bon message, au bon moment
il propose de mettre à jour le moyen de paiement via un tool sécurisé
il relance selon une cadence — pas de spam, pas d’abandon

Le paiement échoué récupéré, c’est de l’argent que tu avais déjà gagné et que tu allais laisser filer. C’est souvent le play avec le meilleur ROI immédiat, parce que tu ne convaincs personne : tu répares une friction.

La refund policy as code

Le remboursement, c’est le tool le plus dangereux. Donc le plus verrouillé.

Fenêtre de 30 jours, montant proratisé, plafond, cas éligibles : tout est dans la fonction. L’agent ne « décide » jamais un remboursement. Il vérifie l’éligibilité via le code, et le code répond oui ou non.

Un client hors fenêtre qui insiste ? Le tool refuse, et le cas part en escalade humaine. L’agent ne peut pas être manipulé pour donner de l’argent, parce qu’il n’a pas ce pouvoir. Le code l’a.

Mesurer comme un opérateur

Un système sans métrique, c’est une croyance. Je pilote ce genre de projet avec quatre chiffres. Pas plus.

1. Deflection rate. Le pourcentage de tickets résolus sans humain. C’est la métrique reine. C’est elle qui devient une économie.

2. Save rate. Sur les demandes d’annulation, le pourcentage de clients retenus par une save offer. C’est du MRR défendu, ticket par ticket.

3. Time-to-resolution. Le temps entre l’ouverture et la résolution. Un agent qui répond en 20 secondes, à 3h du matin, change l’expérience — et le CSAT.

4. CSAT. La satisfaction. Le garde-fou. Si la déflection monte mais que le CSAT chute, tu n’automatises pas, tu abîmes.

Et voici le calcul qui transforme tout ça en argument business.

Prends un support qui traite 8 000 tickets par mois. Un ticket humain coûte, disons, 5€ (temps agent, outillage, encadrement). Ça fait 40 000€ par mois de coût de support.

Si l’agent en défléchit 70%, tu n’automatises pas « du texte ». Tu retires 5 600 tickets de la file humaine.

5 600 tickets × 5€ = 28 000€ de facture évitée. Par mois.

Et je n’ai même pas encore compté le save rate. Si l’agent retient ne serait-ce que 200 abonnements par mois à 15€, c’est 3 000€ de MRR défendu, tous les mois, qui se cumule.

C’est ça, penser en opérateur. Tu ne vends pas « un chatbot ». Tu montres une ligne de facture qui baisse et une ligne de MRR qui tient.

Le rollout : shadow mode, puis pilote automatique progressif

Je ne branche jamais un agent en autonomie totale le jour 1. Ce serait de l’orgueil, pas de l’ingénierie.

Le déploiement se fait en trois temps.

Étape 1 — shadow mode

L’agent tourne sur les vrais tickets, mais il ne parle à personne. Il propose ses réponses. Un humain compare. On mesure l’écart.

Pendant cette phase, chaque réponse que l’agent aurait ratée devient un cas de test. Tu ne débogues pas dans le vide. Tu construis une suite de tests à partir du terrain réel.

Étape 2 — autopilot supervisé

L’agent répond pour de vrai, mais sur les intents les plus sûrs d’abord. Statut de commande. FAQ. Mise à jour de moyen de paiement. L’humain garde la main sur les remboursements et les cas limites.

À chaque escalade, même question : est-ce un vrai cas humain, ou un trou dans mes tools ? Si c’est un trou, je le comble, et l’escalade devient un test de plus.

Étape 3 — pilote automatique élargi

Intent par intent, à mesure que les métriques tiennent, j’ouvre le périmètre. L’agent absorbe de plus en plus de volume. L’humain se concentre sur ce qui mérite vraiment un humain : les cas rares, sensibles, émotionnels.

C’est le point qui compte le plus, et je le répète parce qu’on l’oublie toujours :

L’IA est un accélérateur, pas un remplaçant.

L’agent ne vire personne. Il libère les humains du volume répétitif pour qu’ils gèrent les 20% de tickets qui demandent vraiment du jugement. Le client difficile, le cas de conscience, la réclamation limite : ça reste humain. Le « comment j’annule ? » à la 400e occurrence de la semaine : ça, c’est pour l’agent.

Chaque escalade qui remonte n’est pas un échec. C’est une donnée. Elle devient un cas de test, le système se resserre, et le périmètre s’élargit encore.

Ce que je retiens

Mettre un support d’abonnements en pilote automatique, ce n’est pas un projet d’IA. C’est un projet d’opérateur qui utilise l’IA.

La partie IA est la plus simple. Le vrai travail, c’est :

tagger le terrain avant de coder
trouver les 5-7 intents qui font 80% du volume
séparer les trois couches de données
mettre la policy dans le code, pas dans le prompt
traiter annulation, dunning et remboursement comme des flows dédiés
mesurer en deflection, save rate, résolution, CSAT
déployer en shadow puis en autopilot progressif

Et surtout : garder l’humain là où il crée de la valeur, et lui rendre le temps volé par la répétition.

Le modèle fait la conversation. Le code fait les règles. Toi, tu fais l’économie.

Ce genre de chantier — un agent branché sur du vrai code, pensé en ligne de facture — c’est exactement ce que je fais en mission freelance. Si ton équipe a un support qui déborde, on peut regarder ça ensemble en 30 minutes : calendly.com/yelkamel/30min.