Vendre en ligne depuis Paris ne change pas la technique. Cela change la logistique, la promesse et la concurrence. C’est la distinction que ce guide essaie de tenir : d’un côté ce que la ville impose réellement à une boutique — le mètre carré de stockage, la livraison en zone dense, le retrait en magasin, la recherche de proximité — de l’autre les trois décisions techniques qui décident si votre catalogue reste utilisable quand il grossit, et qui sont les mêmes à Paris qu’ailleurs.
La seconde partie s’appuie sur une mesure faite ici, sur un catalogue de cent mille références, qui donne un écart de soixante-quinze fois sur le temps de réponse d’un filtre selon une seule décision — l’ordre des colonnes d’un index. C’est la cause la plus fréquente des pages de catégorie qui mettent plusieurs secondes à répondre, et elle ne coûte rien à corriger si elle est prise à temps.
Ce que Paris change vraiment
Quatre contraintes, et elles pèsent plus lourd sur le modèle que sur le site.
Le mètre carré. Un commerçant parisien n’a pas de réserve. Cela conditionne le catalogue avant de conditionner le site : nombre de références tenables en stock propre, part du catalogue en commande fournisseur, délai affiché selon les deux cas. Les boutiques parisiennes qui fonctionnent affichent cette différence honnêtement — « en stock, expédié aujourd’hui » et « sous cinq jours » sont deux promesses distinctes, et le site doit savoir les distinguer produit par produit. C’est une contrainte de modèle de données, pas de design : un champ de disponibilité réelle par référence, alimenté par votre gestion.
La livraison en zone dense. Le point de retrait est souvent préféré à la livraison à domicile en ville, parce que personne n’est chez soi à quatorze heures. Proposer le retrait en point relais et, s’il existe, le retrait dans votre magasin, n’est pas une option secondaire : c’est fréquemment le mode le plus choisi. Techniquement, cela suppose une carte, un service tiers pour la liste des points, et la gestion des indisponibilités — comptez une journée de développement, pas une case à cocher.
Le retrait en magasin, qui n’est pas une livraison. C’est un parcours différent : pas de frais de port, un créneau à annoncer, une notification quand le colis est prêt, et une gestion de ce qui se passe si le client ne vient pas. C’est aussi le seul mode où vous récupérez un contact physique, donc le plus rentable — et celui que les boutiques traitent le plus mal, en le proposant sans dire quand le retrait sera possible.
La recherche de proximité. Une part des recherches d’achat porte sur la disponibilité immédiate près de soi. Pour un commerce parisien, cela signifie que la fiche d’établissement et le site doivent dire la même chose : horaires, adresse, et si possible l’état du stock. C’est un travail de cohérence entre deux surfaces, et il n’a rien à voir avec le référencement d’une boutique nationale.
Ce que Paris ne change pas, en revanche : la fiscalité, les obligations d’information du consommateur, la performance attendue, la qualité du catalogue. Un devis qui justifie un surcoût par « le marché parisien » sans nommer l’une des quatre contraintes ci-dessus justifie mal.
La promesse : le seul vrai avantage d’une boutique parisienne
Une boutique parisienne ne gagnera pas la bataille du prix contre un vendeur national qui achète dix fois plus. Elle peut gagner celle de l’immédiateté, et c’est le seul terrain où la position géographique est un actif.
| Promesse | Ce qu’elle exige | Ce qu’elle vous protège de |
|---|---|---|
| « Retrait aujourd’hui en magasin » | un état de stock fiable au magasin, mis à jour au moins toutes les heures | de la comparaison de prix pure : on ne compare pas un prix avec un délai de quatre jours |
| « Livré demain dans Paris » | une coupure horaire claire, un transporteur urbain, et le respect du délai neuf fois sur dix | de l’abandon au moment des frais de port |
| « Conseil avant achat, par téléphone ou en boutique » | un numéro visible, quelqu’un qui répond, et des fiches produits qui admettent leurs limites | des retours, qui coûtent plus cher que la vente perdue |
Chacune de ces trois promesses se vérifie par le visiteur en quelques secondes, et chacune est détruite par une seule exception non annoncée. Une boutique qui promet le retrait aujourd’hui et fait attendre le client deux jours perd plus qu’une boutique qui n’avait rien promis.
Mesure — les trois décisions techniques qui décident de la suite
Passons à ce qui est identique partout, et qui se mesure. Un catalogue de cent mille références a été monté ici, avec catégorie, marque, prix, disponibilité, stock, taille et couleur. La requête testée est celle d’une page de catégorie ordinaire : une catégorie, les articles actifs, une fourchette de prix, une couleur, triés par prix, vingt-quatre résultats. Médiane de quinze exécutions.
| Index en place | Durée | Ce que fait le moteur |
|---|---|---|
| Aucun | 6,03 ms | il lit les cent mille lignes, puis trie dans une table temporaire |
Un index sur prix seul | 9,14 ms | il s’en sert pour la fourchette de prix — et devient plus lent que sans index |
Un index sur (couleur, actif) | 5,86 ms | il filtre sur le mauvais critère : la couleur laisse encore des milliers de lignes |
Un index sur (catégorie, actif, prix) | 0,08 ms | tout est dans l’index, le tri compris : rien à relire, rien à trier |
Les mêmes colonnes, ordre inversé : (prix, actif, catégorie) | 6,00 ms | l’optimiseur ne s’en sert pas du tout et retombe sur un autre index |
Trois enseignements, et ils valent pour toute boutique qui dépassera quelques milliers de références.
Un index peut rendre une requête plus lente. Neuf virgule quatorze millisecondes avec l’index sur le prix, contre six virgule zéro trois sans aucun index. Ce n’est pas une anomalie : l’optimiseur a choisi d’attaquer par la fourchette de prix, ce qui lui a fait perdre la possibilité d’écarter les lignes à bon compte. Ajouter des index « au cas où » est une pratique répandue et nuisible ; chaque index se justifie par une requête précise, et se vérifie en lisant le plan d’exécution.
L’ordre des colonnes décide de tout. Les mêmes trois colonnes, dans le bon ordre, donnent 0,08 milliseconde ; dans l’ordre inverse, 6,00 — soixante-quinze fois plus. La règle est mécanique : d’abord les colonnes comparées à une valeur exacte, ensuite celles utilisées en fourchette, enfin celles servant au tri. Inverser cet ordre revient à ne pas avoir d’index, tout en payant son coût d’écriture et de disque.
Le plan d’exécution est la seule source de vérité. Une ligne de commande suffit à savoir si l’index sert :
EXPLAIN QUERY PLAN
SELECT id FROM produit
WHERE categorie = ? AND actif = 1 AND prix BETWEEN ? AND ? AND couleur = ?
ORDER BY prix LIMIT 24;
-- « SEARCH … USING INDEX i_bon (categorie=? AND actif=? AND prix>? AND prix<?) » : l'index sert
-- « SCAN produit | USE TEMP B-TREE FOR ORDER BY » : il ne sert pas, et le tri se fait à partLa mention d’un tri dans une table temporaire est le signal à chercher : elle signifie que le moteur a dû relire et réordonner, ce qui coûte d’autant plus cher que le catalogue grossit. Sur les boutiques que nous reprenons, c’est la cause numéro un des pages de catégorie lentes — avant les images, avant les modules, avant l’hébergement.
Le reste du décompte technique
Les deux autres décisions qui comptent à la création, et qui coûtent une réécriture si elles sont prises après.
Les déclinaisons. Un produit en trois tailles et quatre couleurs n’est pas douze produits : c’est un produit avec douze combinaisons, chacune ayant son stock, son code article, éventuellement son prix et son poids. Modéliser cela comme douze fiches indépendantes est la décision qui rend impossible, plus tard, d’afficher « disponible en bleu, plus en rouge » — et qui multiplie par douze le travail de saisie. Cette décision se prend avant le premier import.
Les images. Une chaîne de traitement qui produit les dérivés à l’import, en plusieurs largeurs et dans un format moderne. L’écart mesuré sur une page de vingt-quatre produits est de cent soixante-treize fois en poids et de trente-quatre fois en délai d’affichage : le détail des mesures est dans notre article sur le prix d’une boutique, avec le constat que l’attribut de chargement différé, seul, ne change rien.
Mesure — le stock partagé entre la boutique et le site
C’est le problème parisien par excellence : un magasin, un site, un seul stock, et des pièces souvent tenues à l’unité. La question posée est toujours la même — à quelle fréquence faut-il synchroniser ? Elle se simule.
Modèle : un article tenu en une unité, dix heures d’ouverture, environ quatre ventes par jour au comptoir et trois commandes en ligne, quatre mille journées simulées. Le site ne connaît le stock qu’à la dernière synchronisation ; une survente est une commande acceptée en ligne alors que la pièce est déjà partie en boutique.
| Synchronisation | Commandes en ligne | Surventes | Part des commandes à annuler |
|---|---|---|---|
| Toutes les 5 minutes | 1 700 | 24 | 1,4 % |
| Toutes les 15 minutes | 1 818 | 104 | 5,7 % |
| Toutes les heures | 2 104 | 389 | 18,5 % |
| Toutes les 4 heures | 3 131 | 1 386 | 44,3 % |
| Une fois par jour | 3 941 | 2 205 | 56,0 % |
Une synchronisation quotidienne — le réglage par défaut de beaucoup d’installations — conduit à annuler plus d’une commande en ligne sur deux sur un article tenu à l’unité. C’est le mécanisme derrière la plainte que nous entendons régulièrement : « on annule trop de commandes, les clients sont furieux ». Ce n’est pas un problème de commercial, c’est un intervalle de synchronisation.
Notez la colonne des commandes en ligne, qui augmente quand l’intervalle s’allonge : plus le site affiche du stock fantôme, plus il encaisse de commandes — qu’il faudra annuler. Un chiffre de ventes en hausse peut donc masquer une dégradation, et c’est une bonne raison de suivre le taux d’annulation autant que le chiffre.
Trois montages possibles, selon vos moyens :
| Montage | Ce qu’il demande | Surventes attendues |
|---|---|---|
| Aucun partage : un stock dédié au site | réserver physiquement quelques pièces au web | nulles, mais vous vendez moins |
| Synchronisation périodique depuis la caisse | un export toutes les cinq à quinze minutes | 1 à 6 % — acceptable |
| Vérification à la commande | le site interroge la caisse au moment de valider le panier | quasi nulles, et c’est le seul montage qui tienne sur des pièces uniques |
Le troisième montage est le bon choix dès que vous vendez des pièces uniques — antiquités, seconde main, créations. Il coûte un à deux jours de développement de plus, à condition que votre logiciel de caisse expose une interface interrogeable. C’est une question à poser à votre éditeur avant de choisir la plateforme, pas après : le montage dépend entièrement de cette réponse. Le sujet plus général du lien entre le site et le logiciel de gestion est traité dans notre article sur le fait de connecter un site et un ERP.
Le choix de la plateforme, posé sans dogme
| Voie | Quand elle convient | Ce qu’elle coûte à long terme |
|---|---|---|
| Plateforme en abonnement | catalogue simple, pas de règle de tarification propre, équipe sans compétence technique | l’abonnement plus une commission sur les ventes, et la limite du modèle de la plateforme |
| Solution installée que vous hébergez | catalogue avec déclinaisons, besoin d’interfacer une gestion, volonté de maîtriser les données | la maintenance, les montées de version, la compatibilité des modules |
| Développement sur mesure | une règle métier propre : tarification par client, configurateur, place de marché | tout le développement, et la maintenance — mais rien d’inutile |
Le critère qui tranche n’est ni le prix ni le nombre de produits, mais celui-ci : votre façon de vendre est-elle standard ? Si votre prix dépend du client, si votre stock vit dans un logiciel de gestion, si votre produit se configure, aucune plateforme d’abonnement ne vous contiendra sans contorsions. Si vous vendez des articles au prix affiché avec un stock tenu à la main, la plateforme est le bon choix et le sur-mesure serait une dépense inutile. La comparaison détaillée entre les deux solutions installées les plus répandues est dans notre article PrestaShop ou Shopify.
Le parcours d’achat : ce qui se vérifie avant la mise en ligne
Une boutique se recette par des parcours joués en entier, pas par une revue de pages. Cinq parcours, et aucun n’est facultatif.
- Commander et payer. Avec une vraie carte de test, jusqu’à la confirmation, et en vérifiant que la commande apparaît bien dans votre gestion.
- Payer et échouer. Carte refusée, abandon au moment du paiement, retour en arrière du navigateur. La question à trancher : la commande reste-t-elle en attente, et le stock est-il réservé ou libéré ?
- Annuler. Par le client, par vous, avant et après expédition. Qui est notifié, et le stock revient-il ?
- Rembourser, partiellement. Un article sur trois dans une commande. C’est le parcours le plus souvent oublié, et celui qui produit les pires appels.
- Retourner. L’étiquette, le délai légal de rétractation, l’état du remboursement visible par le client.
Ces cinq parcours représentent un à trois jours de recette. Ils sont la première ligne qu’on retire d’un devis trop cher, et la première cause de perte de confiance dans les semaines suivant l’ouverture.
Les courriels, que personne ne teste
Une confirmation de commande qui arrive dans les indésirables coûte un appel par commande, et donne au client l’impression que sa commande n’est pas passée. La cause est presque toujours la même : les enregistrements qui prouvent que vos courriels viennent bien de votre domaine n’ont pas été posés, ou n’ont pas été repris quand l’hébergement a changé.
Trois vérifications avant l’ouverture, qui prennent dix minutes : envoyer une confirmation réelle vers trois messageries différentes, vérifier qu’elle arrive dans la boîte de réception et non ailleurs, et lire l’en-tête du message reçu pour confirmer que l’authentification est validée. Si l’une des trois échoue, la boutique n’est pas prête à ouvrir, quel que soit l’état du reste.
Dans quel ordre nous prenons un projet de boutique
- Le modèle de données : déclinaisons, disponibilité réelle, tarification. Irréversible.
- L’import du catalogue depuis la source existante, avec rejeu possible.
- La chaîne de traitement des images, avant de charger les photos, pas après.
- Les index et les pages de catégorie, vérifiés au plan d’exécution sur un catalogue de taille réelle — pas sur les douze produits de démonstration.
- Les modes de livraison, dont le retrait, avec leurs promesses de délai.
- Le paiement et ses cas d’échec.
- Les cinq parcours de recette, joués en entier.
- Les courriels, testés vers trois messageries.
Le point 4 mérite une insistance : une boutique se teste avec un catalogue de taille réelle. Une page de catégorie qui répond en cinquante millisecondes sur douze produits de démonstration peut répondre en quatre secondes sur vos huit mille références, et ce n’est pas un problème d’hébergement — c’est celui que mesure cet article.
Ce chantier fait partie de ce que nous traitons en création de site e-commerce, depuis nos deux adresses franciliennes ; la présentation de notre agence web à Paris précise l’équipe et le périmètre.
Ce qu’il faut retenir
Paris change la logistique et la promesse, pas la technique. Ce qui se joue localement, c’est le mètre carré de stockage — donc l’affichage honnête de deux délais selon la disponibilité —, le retrait comme mode principal plutôt que secondaire, et la cohérence entre votre fiche d’établissement et votre site. Le seul avantage que la position géographique procure est l’immédiateté, et elle se détruit par une seule promesse non tenue.
Le reste est identique partout, et se mesure. Sur cent mille références, le même filtre de catégorie répond en 0,08 milliseconde avec un index composite dans le bon ordre, et en 6,00 millisecondes avec les mêmes colonnes dans l’ordre inverse — soixante-quinze fois plus lent, pour le même coût de disque. Un index sur le prix seul fait même passer la requête de 6,03 à 9,14 millisecondes : un index mal choisi est pire que pas d’index.
Ces décisions se prennent avant l’import du premier produit. Après, elles coûtent une reprise du modèle de données, c’est-à-dire le double du projet initial.
