Création de site e-commerce à Paris

Le choix dépend du catalogue, des règles de prix, des intégrations, du volume attendu et de l’équipe qui exploitera la boutique. PrestaShop, Shopify ou un socle sur mesure ne répondent pas aux mêmes contraintes.

En pratique, trois critères tranchent. Le premier est la complexité du catalogue : au-delà de quelques milliers de références avec des déclinaisons et des attributs techniques, les solutions louées atteignent des limites de gestion. Le deuxième est la règle de prix : des tarifs négociés par client, des remises par quantité ou des calculs à partir de dimensions demandent soit un socle ouvert, soit du développement. Le troisième est l’équipe : une boutique confiée à une personne qui n’est pas technicienne se pilote mieux sur une solution hébergée.

Shopify convient à un catalogue clair, une équipe réduite et une mise en ligne rapide. PrestaShop convient quand le catalogue est riche et que l’on veut garder le code. Le sur-mesure ne se justifie que lorsque le cœur de l’activité est une règle qu’aucune solution ne sait tenir.

Nous recommandons par écrit, avec ce que chaque option interdit.

Oui lorsque des interfaces ou exports existent. Le cadrage définit les données échangées, la fréquence, la source de référence et le traitement des erreurs.

Les flux d’une boutique se ramènent à quatre : le catalogue et les prix qui descendent de l’ERP, les stocks qui descendent, les commandes qui montent, et les statuts d’expédition qui redescendent. Chacun se traite séparément, avec sa fréquence propre — un stock se rafraîchit toutes les quinze minutes, un catalogue une fois par nuit.

La source de référence se décide champ par champ, sinon les deux systèmes se corrigent mutuellement. Le cas typique : le prix vient de l’ERP, mais la description enrichie et les photos vivent dans la boutique, et l’import nocturne ne doit pas les écraser.

Le traitement des erreurs représente la moitié de la charge. Une commande qui n’a pas pu monter dans l’ERP ne doit pas disparaître : elle est mise en file, réessayée, et une alerte part au bout de trois échecs. Sans ce dispositif, on découvre le problème par un client qui appelle.

Par un travail sur la structure : catégories, attributs, déclinaisons, filtres, règles de prix et contenus. Cette organisation conditionne la navigation, la recherche et le référencement.

L’erreur la plus coûteuse se prend ici : confondre catégorie et attribut. Une catégorie est un rayon dans lequel on entre ; un attribut est un critère par lequel on filtre. Une couleur, une matière, une dimension sont des attributs — en faire des catégories produit des dizaines de pages qui se ressemblent et se font concurrence. L’inverse existe aussi : des rayons transformés en filtres, et plus aucune page sur laquelle se positionner.

Le travail commence donc par un tableau : pour chaque niveau, ce qu’il contient, combien de références, et la requête à laquelle il répond. Les niveaux qui n’ont ni volume ni requête sont fusionnés.

Vient ensuite la qualité des données : une référence sans poids ne peut pas être livrée correctement, sans dimension ne peut pas être configurée, sans attribut ne peut pas être filtrée. Nous mesurons le taux de complétude avant l’import et il est rarement au-dessus de soixante-dix pour cent.

Oui. La structure des catégories, les URL, les données structurées, la performance, la gestion des filtres et les contenus font partie du périmètre de conception.

Le point qui distingue le référencement d’une boutique de celui d’un site éditorial est la gestion des filtres. Une page de rayon avec six filtres combinables génère des milliers d’adresses différentes pour le même contenu. Sans règle, les moteurs explorent ces combinaisons au détriment des pages utiles, et le budget d’exploration se dilue. Nous décidons donc, filtre par filtre, ce qui produit une page indexable et ce qui reste un paramètre.

Les données structurées produit sont posées avec le prix, la disponibilité et les avis quand ils existent réellement — jamais des notes inventées, qui exposent à une sanction.

La performance compte davantage ici qu’ailleurs, parce qu’une page de rayon charge des dizaines d’images. Le format, les dimensions servies et le chargement différé sous la ligne de flottaison sont traités à l’intégration, pas après.

Ce qui n’est pas dans le périmètre : la rédaction de milliers de descriptions produit, qui se chiffre séparément.

Par des solutions de paiement conformes, sans stockage de données bancaires sur le site, avec des contrôles techniques et un suivi des tentatives anormales.

Le principe est simple et non négociable : les données de carte ne transitent jamais par votre serveur. Elles sont saisies dans un cadre hébergé par la passerelle ou une page redirigée, ce qui sort votre site du périmètre le plus lourd de la norme PCI DSS. Une intégration qui ferait passer le numéro par votre boutique vous imposerait une certification annuelle et un audit que personne ne souhaite financer.

Le reste relève de l’hygiène : protocole chiffré sur tout le site, authentification forte du client selon la directive européenne, journalisation des tentatives de paiement, et limitation des essais répétés qui sont le signe d’un test de cartes volées.

Nous configurons aussi les règles de l’antifraude de la passerelle, et nous vous prévenons de leur effet secondaire : un réglage trop strict refuse des commandes légitimes. Le bon niveau se trouve après quelques semaines d’observation, pas au premier jour.

Les contenus peuvent venir de vos équipes, de vos fournisseurs ou être produits dans le cadre d’une prestation dédiée, avec des gabarits éditoriaux pour rester cohérents.

C’est le poste qui décale le plus de mises en ligne, et il est presque toujours sous-estimé. Une fiche produit complète — titre, description courte, description longue, attributs, deux à cinq photos — demande de vingt à quarante minutes quand les informations existent. Sur cinq cents références, cela représente de trois à six semaines à temps plein.

Trois voies existent. Reprendre les données fournisseur, qui sont souvent incomplètes et identiques chez tous vos concurrents — cela fonctionne pour les attributs, mal pour le texte. Produire en interne, ce qui demande un référent et un calendrier. Ou nous confier la rédaction, facturée à la fiche ou au jour.

La décision se prend au cadrage, parce qu’elle détermine la date de mise en ligne. Une boutique complète techniquement et vide de contenus reste en préproduction, et c’est une situation que nous voyons régulièrement.

Les parcours d’achat, les moyens de paiement, les frais de livraison, les e-mails transactionnels, les stocks et les cas d’erreur sont contrôlés sur un environnement de préparation.

La recette d’une boutique se distingue par les cas non nominaux, qui sont ceux qui coûtent de l’argent. On teste le paiement refusé, l’abandon en cours de paiement puis le retour, la commande d’un produit passé en rupture entre la mise au panier et la validation, le code promotionnel expiré, la livraison dans une zone non desservie, et la double soumission du formulaire.

Les courriels transactionnels demandent une vérification à part : confirmation de commande, expédition, annulation, réinitialisation de mot de passe. Il faut les lire sur un téléphone et vérifier qu’ils n’arrivent pas en indésirables — ce qui dépend de la configuration d’authentification du domaine expéditeur, souvent oubliée.

Comptez deux à quatre jours de recette répartis sur deux semaines, avec au moins une commande réelle payée puis remboursée. Une boutique recettée uniquement en mode test réserve des surprises.

Suivi des performances, corrections, ajustements des parcours, maintenance technique et évolutions décidées à partir des données observées.

Les deux premières semaines servent à corriger ce que la recette n’a pas vu, et il y a toujours quelque chose : un frais de port mal calculé sur une zone, un attribut absent sur une famille de produits, un courriel qui part deux fois. Nous surveillons les erreurs applicatives, les paniers abandonnés au moment du paiement et les recherches internes sans résultat, qui sont les trois signaux les plus informatifs.

À un mois, un premier point chiffré : taux de transformation par source de trafic, panier moyen, produits consultés sans être achetés, et étapes du tunnel où l’on perd. Ce point sert à décider la suite plutôt qu’à se rassurer.

Ensuite, le rythme utile est trimestriel : une boutique qui n’évolue pas pendant un an perd du terrain sur des concurrents qui ajustent. Les évolutions sont chiffrées séparément de la maintenance, qui remet en état ce qui existe.