Site e-commerce et future boutique de produits numériques
Ma vitrine et ma future boutique de produits numériques ont été réalisées en deux versions techniques à partir du même contenu, pour comparer objectivement une solution WordPress et une solution sur mesure.
État : la boutique est en cours de publication. Aucun prix ni date n’est annoncé, et aucun lien n’est proposé tant qu’elle n’est pas en ligne.
Contexte et problème résolu
Il fallait un site professionnel bilingue (français et anglais), rapide, bien référencé, doté d’une boutique de produits numériques (applications, scripts et compléments Excel), que je puisse faire évoluer sans dépendre d’un prestataire.
Plutôt que de trancher d’avance, j’ai construit deux déclinaisons du même site et je les compare sur des mesures. Cette démarche rejoint l’article WordPress ou site sur mesure : comment choisir ?
Deux déclinaisons techniques
WordPress et WooCommerce
WordPress structuré avec Bedrock (dépendances gérées par Composer), thème léger écrit pour le projet, WooCommerce pour la boutique, Polylang pour le français et l’anglais (boutique en français).
Pile Docker avec reverse proxy Caddy (TLS, HTTP/3), cache de pages, limites de mémoire, sondes de santé, script de déploiement avec sauvegarde, test de fumée et retour arrière.
Astro et serveur Node
Pages HTML générées à l’avance avec Astro : aucun PHP ni base de données sur le chemin des visiteurs. Un petit serveur Node ne gère que le dynamique : formulaire de contact, achat et téléchargement, back office.
Contenus en JSON validés par des schémas, versionnés dans git ; la publication reconstruit le site dans un dossier neuf puis bascule d’un coup, sans page à moitié construite.
Choix techniques et architecture
- Contenu : dans la version Astro, des blocs typés et validés avant chaque construction ; dans la version WordPress, un chargement de contenu rejouable (pages, menus, formulaires, produits, référencement).
- Sécurité : en-têtes de sécurité et politique de contenu stricte ; dans la version Astro, un back office maison (rôles administrateur et éditeur, mots de passe hachés, double authentification facultative, protection contre les requêtes inter-sites, blocage progressif des essais, journal d’audit) ; paiement délégué à un prestataire spécialisé, sans donnée de carte sur le site ; liens de téléchargement signés, limités dans le temps et en nombre.
- Performance : budgets chiffrés vérifiés par des tests (poids de la page, un seul fichier CSS et un seul script maison, polices hébergées sur le site, aucune requête tierce avant consentement).
- Déploiement par conteneurs : Docker Compose dans les deux cas, derrière un proxy commun, avec limites de ressources et sauvegardes.
- Tests : version WordPress, analyse statique PHP (niveau 6), règles de sécurité WordPress, tests PHP, puis 699 tests navigateur verts (affichage mobile et tablette, référencement, accessibilité en thèmes clair et sombre, bilinguisme, téléchargement, performance). Version Astro : 21 tests unitaires, 1 402 contrôles du HTML généré et 186 tests navigateur.
Difficultés et enseignements
- Des miniatures absentes : sur la version WordPress, PHP avait été compilé sans prise en charge du JPEG, donc aucune miniature n’était générée et les images arrivaient en pleine taille. Après correction, la page d’accueil est passée de 271 Ko et 20 requêtes à 89 Ko et 10 requêtes.
- Des scripts chargés partout : les scripts des émojis et de la boutique étaient chargés sur toutes les pages ; ils ont été retirés là où ils ne servent pas.
- Un décalage de mise en page : le texte se déplaçait à l’arrivée des polices (décalage de 0,15 sur la liste des produits) ; des polices de secours ajustées en largeur l’ont ramené à 0.
- Ce que les tests ont révélé : sur la version Astro, ils ont fait apparaître des liens de type « javascript: » acceptés par le moteur de balisage et des tableaux non accessibles au clavier, corrigés. Le test qui échoue révèle un défaut du site, pas du test.
- Mesurer au bon endroit : les mesures de rapidité faites en local ne reflètent pas la production ; les chiffres de poids et de requêtes sont fiables, les temps de réponse doivent être mesurés sur l’hébergement final.
- Des choix de parcours : achat d’un seul produit à la fois, sans panier, pour simplifier.
État d’avancement honnête
À ce jour, les deux déclinaisons sont réalisées et testées en local. Mesures de la version Astro, en local : page d’accueil d’environ 4 Ko de HTML compressé, affichage du contenu principal en 50 ms environ, aucun décalage de mise en page, site complet de 128 pages construit en environ 0,5 s.
Ce qui reste à faire : la mise en ligne de la boutique (en cours de publication), le parcours de paiement réel à valider avec des clés de test, les mesures finales sur l’hébergement, la validation par un professionnel des conditions de vente et des mentions (droit de rétractation pour les contenus numériques, TVA, résiliation) et la relecture de l’éditeur de contenus par une personne non technique.
Ce que ça montre de mon travail
- Comparer deux approches sur des mesures plutôt que sur des préférences.
- Livrer un site rapide, accessible et sécurisé, vérifié par des tests automatisés avant chaque mise en ligne.
- Donner de l’autonomie : un back office pensé pour une personne peu technique.
- Connaître les limites de chaque solution (WordPress comme sur mesure) et les expliquer honnêtement.
Le présent site est lui-même une variante statique, sans boutique, de la version Astro.
Un site ou une boutique à construire ?
Décrivez votre projet en quelques lignes : je vous dis quelle approche me semble adaptée.