Aller au contenu

01 / 04 En production depuis le 4 septembre 2026

Plumes Jumelles

Site d'abonnement et boutique en ligne pour Plumes Jumelles, un duo de créatrices réunies autour d'une communauté Instagram consacrée aux livres. En production sur plumes-jumelles.fr depuis le 4 septembre 2026. C'est ma première référence client livrée.

Coupe du parcours d'une abonnée, d'Instagram à la boîte aux lettres L'audience vient d'Instagram vers le site Laravel, qui gère comptes, abonnements et boutique. Le paiement passe par Stripe Checkout, dont les webhooks mettent à jour l'état local. Les créatrices pilotent commandes et abonnées dans un back-office dont elles exportent les adresses pour l'envoi postal. Les mails transactionnels partent par le SMTP de Brevo depuis un domaine authentifié DKIM. « Expédiée » Instagram audience non possédée 1 plumes-jumelles.fr · Laravel 13 abonnement, boutique, comptes 1 Back-office commandes, stock,univers, abonnées 4 Stripe Checkout prix de référencewebhooks 3 Export CSV adresses 4 SMTP Brevo domaine signéDKIM 2 Courrier goodies + histoire 4 Boîte de l'abonnée confirmation,expédition 2 Coupe · Plumes Jumelles Laravel 13
Coupe du parcours d'une abonnée, d'Instagram à la boîte aux lettres. Les numéros renvoient aux passages du texte. Trait tireté : système externe ; hachures : contrainte.

Le problème

Avant ce site, Plumes Jumelles n'avait pas de site, seulement une page Instagram. La communauté s'y était formée, mais sur une plateforme qui n'appartient pas aux créatrices : pas de liste d'abonnées à elles, pas d'adresses postales, pas de paiement récurrent.

Or le produit qu'elles voulaient lancer en dépendait entièrement. C'est un abonnement : chaque mois, une histoire inédite qu'elles écrivent, envoyée par courrier avec des goodies et, selon la formule, un objet fait main. À côté, une boutique de papeterie artisanale prolonge l'univers. Il leur fallait un canal à elles : des comptes, des adresses, des prélèvements, un moyen fiable de prévenir chaque abonnée. Et deux personnes qui ne sont pas techniciennes devaient pouvoir le faire tourner seules.

Ce qui rendait la solution évidente inutilisable

Une plateforme hébergée aurait convenu à une boutique. Mais le projet n'était pas une boutique au départ, et ne l'est devenu qu'en partie, en grossissant avec les demandes des clientes : l'abonnement, l'univers du mois réservé aux abonnées, des fichiers délivrés selon les mois effectivement payés. Sur une plateforme, chaque demande de ce genre se négocie contre les limites de l'outil et de ses extensions tierces ; en développement spécifique, elle se code. Le coût est assumé : aucun filet. Tout ce qu'une plateforme donne d'office a dû être construit, du back-office aux frais de port en passant par les rétractations.

Même chose pour les mails : la configuration par défaut, qui laisse l'application envoyer avec l'adresse du domaine sans plus, était inutilisable. Pour un produit par abonnement, les mails font partie du produit : confirmation de souscription, changement de formule, expédition d'une commande, accusé de rétractation. Sans domaine authentifié, ces mails finissent dans les spams ou n'arrivent pas du tout.

Les mails partent donc par le SMTP de Brevo, depuis un domaine signé DKIM, avec la configuration DNS qui va avec. Une commande de diagnostic (pj:mail-test) vérifie l'envoi et renvoie vers les journaux de Brevo quand un message ne part pas. La délivrabilité n'est pas un détail d'infrastructure ici : c'est la condition pour que l'abonnement fonctionne.

Ce qui a été choisi, et ce que ça a coûté

La première version était écrite en AdonisJS et Nuxt (premier commit le 22 mars 2026). Elle a été entièrement réécrite en Laravel 13 et Inertia le 28 mai, pour une raison de maintenance : c'est la stack que je maîtrise le mieux, sur un projet client que je suivrai dans la durée. L'ancienne version est archivée sur une branche. Le prix : une réécriture complète en cours de projet.

Stripe est la référence des prix : le catalogue est synchronisé depuis Stripe, et le paiement passe par Stripe Checkout, la page de paiement hébergée par Stripe. L'état local suit les webhooks : souscription créée, modifiée, résiliée, facture payée. Chaque formule existe en deux offres. Sans engagement, elle est prélevée chaque mois ; avec engagement, elle est payée en une fois sur un tarif annuel. Un garde-fou refuse un abonnement dont la périodicité du tarif ne correspond pas à la durée d'engagement. Les abonnements offerts s'arrêtent seuls grâce à une date de fin posée côté Stripe.

Le back-office est écrit pour ce site, en Inertia et Vue. Les créatrices y gèrent les produits et le stock, les formules, l'univers du mois et ses fichiers réservés aux abonnées, les commandes, les remboursements via Stripe, les rétractations, les avis, la grille de frais de port et les pages légales. Passer une commande à « Expédiée » envoie le mail d'expédition. Les adresses des abonnées s'exportent en CSV pour l'envoi postal.

Pas de rendu côté serveur, et c'est voulu. Il aurait imposé un démon Node sur Forge, plus un audit de chaque page, dont le panier qui vit dans le localStorage, pour un gain nul : les balises utiles au référencement sont rendues par Blade.

La rétractation est acceptée jusqu'à 30 jours après le paiement d'une commande, au lieu des 14 jours légaux à compter de la réception. Le site ne suit pas la date de réception, et plutôt que de construire ce suivi, la fenêtre a été élargie. Elle couvre le délai légal tant que la livraison prend moins de seize jours. Pour un abonnement, la rétractation reste ouverte 14 jours après la souscription.

La livraison est limitée à la France métropolitaine, à la demande des clientes : la grille de frais de port ne couvre ni l'outre-mer ni Monaco, et les codes postaux correspondants sont refusés à la commande.

Vérifiable

En production
plumes-jumelles.fr

Chiffres déclarés, dépôt privé :

Tests
109 tests PHPUnit suite Feature, au 28 septembre 2026