Abonnements SaaS : aller au-delà des plugins existants

Il y a quelques mois, un client arrive dans nos bureaux avec un brief simple en apparence. Il souhaite lancer une plateforme d’échange et de rencontre basée sur un modèle d’abonnement récurrent. Un mois d’accès gratuit pour tester, puis 9,99 euros par mois, résiliation possible à tout moment. Pas de catalogue de produits, pas de panier avec plusieurs produits, pas de stockage. Juste des abonnements numériques, purs et simples.

La première réaction était presque automatique :

WooCommerce avec l’extension Subscriptions, ça doit faire l’affaire .

Après tout, c’est la solution qu’on recommande à 99% des clients PME. Mais quand on a commencé à creuser les spécificités du projet, quelque chose clochait. Les outils que nous avions sous la main étaient pensés pour des besoins bien différents.

Ce qui suit est l’histoire de pourquoi nous avons choisi de ne pas utiliser les plugins existants, et comment nous avons construit une solution allégée, flexible et directement adaptée au besoin réel.

Le piège des solutions génériques

Commençons par le prix. WooCommerce Subscriptions coûte 266 euros par an. C’est un coût modéré pour un site e-commerce classique, certes. Mais quand vous n’avez besoin que d’une partie des fonctionnalités (les abonnements) et que vous jetez à la poubelle tout le reste (le panier, les catégories de produits, les variations, les frais d’expédition), le rapport valeur-prix devient problématique. C’est un peu comme écraser une mouche avec un marteau.

MemberPress, qui cible davantage les communautés en ligne, offre une interface plus intuitive pour les abonnements. Son prix démarre à 99 dollars par an pour la version de base. Mais là encore, vous héritez d’une tonne de fonctionnalités pensées pour des sites de contenu : accès à des pages protégées, limites de téléchargements, droits d’accès granulaires. Si vous n’en avez besoin que de 20%, les 80% restants ne font que ralentir votre plateforme et compliquer la maintenance.

Paid Memberships Pro suit une logique similaire. C’est un bon produit, stable et bien supporté. Mais encore une fois, vous naviguez dans une forêt de règles, de conditions d’accès et de systèmes de niveaux pensés pour des modèles de monétisation complexes. Pour notre plateforme simple, c’était du surequipement.

Easy Digital Downloads (EDD) se positionne sur le téléchargement de fichiers numériques. C’est utile si vous vendez des ebooks, des templates ou des logiciels. Mais une plateforme de rencontre n’est pas un magasin de fichiers. Les possibilités d’EDD ne correspondent simplement pas au besoin.

Le dénominateur commun à tous ces outils ? Ils ont été conçus pour répondre à des cas d’usage larges. Ce qui les rend flexibles les rend aussi lourds. Chaque fonctionnalité supplémentaire, même inactive, ajoute de la complexité dans la base de données, ralentit les migrations, crée des vecteurs de sécurité potentiels.

Pourquoi les plugins existants ne suffisaient pas

Quand on a vraiment creusé le besoin client, trois points se sont cristallisés.

D’abord, la simplicité radicale du modèle. Pas de variations tarifaires, pas de niveaux multiples, pas de promotion courte durée qui nécessiterait un système de coupons. Un abonnement simple, un prix unique, résiliable à tout moment. Les plugins génériques supportent tout cela, bien sûr, mais ils supportent aussi mille autres choses dont vous n’aurez jamais besoin.

Ensuite, le contrôle sur le flux de paiement. Avec WooCommerce Subscriptions, vous êtes lié à l’écosystème WooCommerce : WooCommerce Payments, Stripe Gateway, Square, etc. Vous pouvez le configurer, mais vous êtes toujours dans un cadre imposé. Or pour cette plateforme, nous voulions une intégration fine avec Stripe. Pas juste pour traiter les paiements, mais pour exploiter toute la richesse des webhooks Stripe : savoir exactement quand un paiement échoue, quand une facture est créée, quand un client doit être averti que son renouvellement est dans sept jours. Les plugins existants rende tout cela abstrait. C’est parfois un avantage, mais ici, c’était une limitation.

Enfin, la performance. Une plateforme de rencontre doit être rapide. Chaque requête compte. Les plugins génériques ajoutent des tables à la base de données, des hooks partout dans le code, des requêtes en cascade. Notre solution custom permettait un parcours utilisateur fluide, sans les ralentissements inhérents à une architecture multi-objectifs.

L’alternative : une architecture légère

Nous avons décidé de construire une solution sur-mesure, entièrement basée sur WordPress et ses APIs, couplée à Stripe pour le traitement des paiements.

L’architecture repose sur trois piliers. D’abord, une extension WordPress légère qui gère les abonnements via des Custom Post Types et des métadonnées. Chaque abonnement client est stocké comme un post de type « subscription », avec des champs attachés contenant l’ID du client Stripe, l’ID de la subscription Stripe, la date du prochain renouvellement, et le statut. Ensuite, une intégration native avec Stripe via la librairie stripe-php, installée par Composer. Enfin, un système de webhooks qui écoute les événements Stripe et met à jour automatiquement l’état des abonnements côté WordPress.

C’est simple, c’est efficace, c’est maintenable.

Installation de stripe-php et intégration de base

Pour commencer, vous installez la librairie officielle de Stripe-PHP via Composer. Dans le répertoire de votre plugin :

composer require stripe/stripe-php

Composer crée un dossier vendor avec tout ce qu’il faut. Dans votre plugin WordPress, vous l’incluez ainsi :

require_once plugin_dir_path(__FILE__) . 'vendor/autoload.php';

$stripe = new \Stripe\StripeClient('sk_live_votre_clé_secrète');

// Créer un customer Stripe
$customer = $stripe->customers->create([
    'email' => $user->user_email,
    'metadata' => ['wordpress_user_id' => $user_id]
]);

// Créer une subscription
$subscription = $stripe->subscriptions->create([
    'customer' => $customer->id,
    'items' => [['price' => 'price_xxxxx']]
]);

Quelques lignes, et vous avez une subscription Stripe parfaitement liée à votre utilisateur WordPress. Aucun formulaire de configuration complexe, aucune dépendance à un plugin gateway, juste du code.

Les webhooks : le cœur du système

Où ça devient intéressant, c’est avec les webhooks. Stripe peut vous envoyer des événements en temps réel : quand un paiement réussit, quand il échoue, quand une facture est créée, quand un abonnement est annulé. Vous créez un endpoint dans WordPress :

add_action('wp_ajax_nopriv_stripe_webhook', 'handle_stripe_webhook');

function handle_stripe_webhook() {
    $body = file_get_contents('php://input');
    $sig_header = $_SERVER['HTTP_STRIPE_SIGNATURE'];

    $event = \Stripe\Webhook::constructEvent(
        $body,
        $sig_header,
        'whsec_votre_secret'
    );

    if ($event->type == 'invoice.paid') {
        // Mettre à jour le statut de l'abonnement
        update_user_meta($user_id, 'subscription_status', 'active');
        $user->add_role('paid_member');
    }
}

Et voilà. Chaque événement Stripe déclenche une action WordPress. Paiement réussi ? L’utilisateur devient « paid_member ». Paiement échoué ? On le retire du rôle et on lui envoie une alerte.

Pourquoi Stripe plutôt qu’une autre solution

Nous avons retenu Stripe pour plusieurs raisons. D’abord, la stabilité. Stripe existe depuis 2010, traite des centaines de milliards de dollars par an, et dispose d’une équipe de sécurité impressionnante. Pour une plateforme de rencontre qui gère des données sensibles et de l’argent, c’est non-négociable.

Ensuite, les webhooks. C’est l’épine dorsale de notre approche. Stripe envoie des événements granulaires et prévisibles. Vous savez exactement quand intervenir, et avec quelles données. D’autres acteurs (PayPal, Square) proposent aussi des webhooks, mais Stripe est le plus transparent et le plus détaillé sur ce point.

Enfin, les frais. Stripe facture environ 2,9% + 0,30 euros par transaction en Europe. C’est compétitif. Mais surtout, il n’y a pas de frais cachés, pas d’abonnement mensuel à la plateforme elle-même. Vous payez ce que vous facturez, rien de plus.

Un cas concret : du premier paiement à la facturation récurrente

Suivons le parcours utilisateur de bout en bout.

L’utilisateur arrive sur la plateforme, clique sur « S’abonner ». Côté frontend, Stripe.js charge une interface de paiement sécurisée. L’utilisateur entre ses données de carte. Aucune donnée de carte n’arrive jamais sur vos serveurs : c’est une méthode de paiement Stripe, chacun est dans son rôle, tout est bien compartimenté.

Quand le formulaire est soumis, votre code backend crée une subscription Stripe. Stripe désactive la facturation immédiate (billing_cycle_anchor) pour offrir le premier mois gratuit. La subscription sera rechargée dans 30 jours.

L’utilisateur reçoit un email de confirmation : « Votre abonnement a commencé. Premier mois gratuit. Renouvellement le 17 janvier. »

30 jours plus tard, Stripe crée automatiquement une facture, la paie via le Payment Method stocké, et envoie un webhook invoice.paid à votre endpoint. Votre code reçoit cet événement, met à jour la métadonnée WordPress de l’utilisateur, envoie un email de confirmation avec le montant exact débité.

Si le paiement échoue pour une raison quelconque (carte expirée, solde insuffisant), Stripe envoie un webhook invoice.payment_failed. Vous retirez l’utilisateur du rôle « paid_member » (que nous avions préalablement ajouté dans WordPress) et lui envoyez une alerte pour qu’il mette à jour sa carte.

Tout cela sans que vous ayez à coder un seul cron job pour « vérifier les abonnements qui doivent être renouvelés ». C’est Stripe qui gère la facturation, vous qui réagissez aux événements.

L’architecture en pratique

La structure du code est presque triviale comparée à ce qu’un plugin tout-en-un vous impose.

Un fichier « bb-abo.php » gère l’enregistrement du Custom Post Type subscription, la page d’abonnement frontend, et les handlers AJAX pour la création/annulation.

Un fichier « bb-abo-webhook.php » est dédié aux webhooks Stripe. Chaque type d’événement a sa fonction propre : handle_invoice_paid(), handle_payment_failed(), etc.

Un fichier de configuration WordPress stocke les clés Stripe (publique en frontend, secrète en backend), le secret de signature des webhooks, le mode test ou production.

1200 lignes de code. C’est beaucoup et c’est aussi peu.

A titre de comparaison, les deux plugins que nous n’utiliserons pas c’est :

WooCommerce Core 

• 150,000-250,000 lignes de code
• 1,500-2,500 fichiers PHP

WooCommerce Subscriptions 

• 50,000-80,000 lignes de code
• 150-250 fichiers PHP

Avec notre plugin, pas de dépendances complexes, pas de tables cachées, pas de configurations à passer par une interface graphique pour découvrir après que vous n’aviez pas compris les défauts par défaut.

Des anecdotes qui rassurent

Nous avons un client, gérant d’une salle de sport en ligne, qui avait été attiré par MemberPress. Six mois après le lancement, il s’est rendu compte que les vidéos de ses cours se chargeaient lentement quand il y avait plus de 100 membres connectés simultanément. Enquête menée : MemberPress ajoutait 40 requêtes SQL supplémentaires par page vue. Après migration vers une solution custom, ce nombre est tombé à 5. La performance a explosé. Son taux de retention aussi.

Autre exemple : un client e-learning avait WooCommerce Subscriptions depuis deux ans. Quand il voulait intégrer un système de points de fidélité pour récompenser les abonnements de longue durée, il s’est heurté aux limitations du système. Il aurait fallu un plugin tiers, puis un autre (zapier) pour faire communiquer les deux. Avec une solution custom, c’était quelques lignes de code dans la même codebase.

Ce qu’on gagne vraiment

En optant pour une solution custom avec Stripe et WordPress, plusieurs bénéfices émergent naturellement.

La flexibilité d’abord. Vous voulez ajouter un système de réduction pour les abonnements annuels ? Une facturation à la fin du mois plutôt qu’au jour anniversaire ? Une possibilité de suspendre sans résilier ? Tout cela se code rapidement, sans modifier la structure d’un plugin qui fait mille choses.

La performance. Votre plateforme est rapide par conception, pas entravée par des features inutiles qui ralentissent les requêtes.

Le coût. Pas de 266 euros de WooCommerce Subscriptions, pas de 99 dollars de MemberPress. Juste Stripe, à 2,9% du montant traité.

La maintenabilité. Quand vous ou un collègue retouchez le code dans deux ans, il sera clair et facile à comprendre.

La sécurité. Vous contrôlez exactement ce qui se passe avec les données de paiement. Aucune donnée de carte ne transite par votre serveur, c’est Stripe qui le gère. Vous réduisez votre surface d’attaque.

Quand les plugins restent judicieux

Cela dit, nous ne disons pas qu’il faut fuir les plugins. Pour un site e-commerce classique avec produits physiques, panier, commandes, WooCommerce Subscriptions reste une bonne option. Pour un site de contenu avec abonnements à des articles ou des vidéos, MemberPress ou Paid Memberships Pro peuvent être justifiés.

Mais sitôt que votre cas d’usage devient spécifique, sitôt que vous avez besoin de contrôle fin, la balance bascule. C’est là qu’une solution custom, aussi simple soit-elle, gagne.

La vraie compétence : savoir dire non

Au final, la vraie expertise d’une agence web ne se mesure pas à sa capacité à implémenter WooCommerce de mille façons différentes. Elle se mesure à sa capacité à analyser un besoin, à identifier quand un outil générique est trop lourd, et à proposer quelque chose de proportionné.

Trop souvent, les agences recommandent le plugin qu’elles connaissent. « On sera plus rapides à mettre en place WooCommerce Subscriptions ». Le client paie moins pour le développement, mais souffre plus tard d’une plateforme moins performante, moins flexible, plus coûteuse à maintenir.

Nous préférons la conversation inverse. Nous analysons le besoin. Si un plugin s’ajuste parfaitement, on le recommande. Si ce n’est pas le cas, on propose une alternative plus légère, même si elle prend un peu plus de temps à développer initialement. À moyen et long terme, le client y gagne.

C’est un choix philosophique. Mais pour une agence spécialisée en solutions sur mesure, c’est le bon choix.

---

Vous avez un projet SaaS ou d’abonnement en ligne ? Vous vous demandez quel outil choisir ? Parlons-en. Nous analysons votre besoin sans parti pris, et vous recommandons honnêtement ce qui est proportionné.

---