WooCommerce ou un bloc personnalisé : la question s’est posée dès les premiers échanges avec une petite association qui souhaitait ajouter un bouton de don sur son site, construit en éditeur de site via le plugin Gutenberg, encore expérimental sur ce projet livré avant la sortie officielle de la version 5.9 du cœur WordPress.
Installer WooCommerce pour vendre un seul « produit » — un don à montant libre — aurait été disproportionné : tables supplémentaires en base de données, pages de panier et de commande à personnaliser, extensions de paiement à configurer, et une charge de maintenance permanente pour une fonctionnalité somme toute simple. L’alternative retenue a été de développer un bloc dynamique dédié, enregistré côté PHP, insérable directement dans n’importe quel template du Site Editor.
Comparer les deux approches sur ce projet précis
| Critère | WooCommerce | Bloc Stripe dédié |
|---|---|---|
| Temps d’installation | Plusieurs heures (configuration, pages panier/commande) | Moins d’une heure |
| Poids sur le site | Tables et requêtes supplémentaires en continu | Un seul appel API à la soumission |
| Maintenance long terme | Mises à jour régulières de l’extension et des modules de paiement | Un seul fichier PHP à surveiller |
| Évolutivité vers un catalogue | Excellente, pensée pour ça | Faible, non prévue pour ce cas |
Ce que fait réellement le bloc dynamique
Le bloc, nommé wpm/bouton-don, s’enregistre côté PHP via register_block_type(), avec un rendu dynamique généré par une fonction de callback plutôt qu’un modèle statique. Depuis l’éditeur, il se présente comme un simple bouton configurable (libellé, montant par défaut), directement insérable dans n’importe quel template part du Site Editor, au même titre qu’un bloc Paragraphe ou Bouton natif.
register_block_type( 'wpm/bouton-don', array(
'attributes' => array(
'libelle' => array( 'type' => 'string', 'default' => 'Faire un don' ),
'montant' => array( 'type' => 'number', 'default' => 20 ),
),
'render_callback' => function ( $attributs ) {
return sprintf(
'<button class="wpm-bouton-don" data-montant="%d">%s</button>',
absint( $attributs['montant'] ),
esc_html( $attributs['libelle'] )
);
},
) );
Pourquoi Stripe Checkout plutôt que Stripe Elements
Deux approches Stripe étaient possibles : Stripe Elements, qui permet de construire un formulaire de paiement personnalisé directement intégré à la page, ou Stripe Checkout, qui redirige le visiteur vers une page hébergée par Stripe. Pour ce projet, Checkout a été retenu sans hésitation : la conformité PCI DSS reste entièrement gérée par Stripe, aucune donnée bancaire ne transite par le serveur de l’association, et le développement reste réduit à sa plus simple expression.
Un appel serveur, une redirection
Au clic sur le bouton, une requête est envoyée à une route REST WordPress qui crée une session Stripe Checkout avec le montant sélectionné, avant de rediriger immédiatement le navigateur vers l’URL de paiement retournée par Stripe.
- Un bloc dynamique, léger, sans dépendance à une extension e-commerce.
- Une route REST qui crée la session Stripe côté serveur, jamais côté client.
- Une redirection immédiate vers la page hébergée par Stripe, sans formulaire maison à sécuriser.
Ce que cette approche ne traite pas
Ce choix ne convient pas à tous les contextes : ce billet ne couvre pas la génération de reçus fiscaux, qui suppose une intégration avec un outil comptable dédié, ni la comptabilité associative dans son ensemble. Pour une structure qui vendrait réellement plusieurs produits, avec gestion de stock et de livraison, WooCommerce resterait le choix le plus raisonnable : ce comparatif ne vaut que pour un cas d’usage précis, celui d’un don à montant libre, sans catalogue.
La question à se poser n’est jamais « quel est l’outil le plus connu », mais « quel est le poids réel de cet outil face au besoin exact du client » : ici, un bloc de quarante lignes fait le travail qu’une extension de plusieurs mégaoctets aurait fait, avec une fraction de la surface de maintenance.
Notre verdict
Pour un don unique sans catalogue, un bloc dynamique dédié couplé à Stripe Checkout reste la solution la plus raisonnable : plus légère à installer, plus simple à maintenir, et parfaitement intégrée à l’éditeur de site dès sa phase encore expérimentale. WooCommerce garde évidemment sa place dès qu’un vrai catalogue de produits entre en jeu, mais l’imposer ici aurait ajouté du poids sans bénéfice réel pour ce client.
