Prix de création et coût total ne répondent pas à la même question
Le prix de création couvre la mise en place : cadrage, design, configuration, développement, contenus et migration. Le coût total de possession, ou TCO, mesure ce que l’architecture consomme pendant son exploitation.
Les résultats français sur « prix site e-commerce » proposent surtout des fourchettes de création, des simulateurs et des offres d’agences. Ces estimations peuvent servir de repère commercial, mais elles deviennent peu comparables lorsque le périmètre, le volume et la période diffèrent.
Le TCO répond à une question plus utile : combien ce scénario coûtera-t-il pour vendre, maintenir et faire évoluer l’activité pendant trois ans ?
Définir le périmètre avant de calculer
Deux budgets ne peuvent être comparés que s’ils couvrent les mêmes fonctions. Écrivez d’abord ce que la stack doit prendre en charge :
- vitrine et contenu ;
- catalogue, prix et promotions ;
- panier et checkout ;
- paiement et fraude ;
- commandes, stock et logistique ;
- service client et CRM ;
- analytics et reporting ;
- intégrations, automatisations et supervision.
Notre guide Stack e-commerce permet de cartographier ces capacités et leurs propriétaires.
Fixez ensuite les hypothèses communes : trois ans d’exploitation, nombre de boutiques, pays, utilisateurs, commandes, chiffre d’affaires, références produit, entrepôts et canaux. Sans ces hypothèses, un tarif par commande ou un coût d’application ne peut pas être projeté.
1. Les coûts initiaux
Les coûts initiaux rendent la boutique exploitable. Ils ne doivent pas être limités à la facture de l’agence.
Cadrage et architecture
Cette phase couvre les ateliers métier, le cahier de flux, le choix des solutions, la gouvernance des données et les critères d’acceptation. La réduire peut déplacer le coût vers les corrections après lancement.
UX, design et thème
Distinguez l’achat d’un thème, son adaptation et la création de composants spécifiques. Ajoutez les tests mobile, accessibilité, performance et checkout.
Configuration et développement
Incluez le paramétrage natif, les développements, les applications ou modules, les règles promotionnelles, les taxes, les transporteurs et les moyens de paiement.
Données et contenus
La migration concerne les produits, variantes, médias, clients, commandes, pages, redirections et historiques nécessaires. Le nettoyage et la mise en correspondance prennent souvent plus de temps que l’import lui-même.
Intégrations
Chaque connexion au PIM, ERP, OMS, WMS, CRM, support ou outil financier a un coût de conception, de développement et de test. Un connecteur « prêt à l’emploi » doit tout de même être configuré et réconcilié.
Recette et lancement
Prévoyez les tests fonctionnels, la charge, la sécurité, la formation, le plan de bascule et le support renforcé des premiers jours.
2. Les coûts logiciels récurrents
Regroupez les dépenses par capacité plutôt que par fournisseur. Cette présentation rend les doublons visibles.
| Capacité | Dépenses possibles |
|---|---|
| Commerce | Abonnement de plateforme ou licence, boutiques supplémentaires, utilisateurs |
| Contenu et catalogue | CMS, PIM, DAM, recherche |
| Conversion | Personnalisation, avis, merchandising, tests |
| Paiement | Services de paiement, lutte contre la fraude, réconciliation |
| Relation client | CRM, emailing, support, fidélité |
| Données | Analytics, tag management, entrepôt de données, BI |
| Opérations | OMS, ERP, WMS, expédition, retours |
| Intégration | iPaaS, automatisation, files, supervision |
Pour chaque ligne, notez le mode de tarification : fixe, par utilisateur, contact, commande, requête, boutique, pays ou volume de données. Ajoutez une hypothèse d’évolution si l’activité change de palier.
Les conditions varient rapidement. Vérifiez les prix sur les pages officielles au moment du chiffrage, par exemple les tarifs Shopify ou les offres PrestaShop, plutôt que de reprendre une grille ancienne dans un comparatif.
3. Hébergement, infrastructure et sécurité
Une plateforme SaaS inclut une partie de l’infrastructure dans son prix. Une solution hébergée par l’entreprise fait apparaître davantage de lignes : serveurs, base de données, CDN, sauvegardes, supervision, environnements et interventions.
Dans les deux modèles, certains coûts restent possibles :
- hébergement de services personnalisés ou d’applications ;
- stockage et traitement des médias ;
- observabilité des intégrations ;
- protection, audits et tests de sécurité ;
- environnement de préproduction ;
- nom de domaine, DNS et certificats spécialisés ;
- plan de reprise et conservation des sauvegardes.
Ne comparez pas « hébergement inclus » à un serveur seul. Comparez le niveau de service, les responsabilités et les mécanismes de reprise.
4. Applications, modules et extensions
Une boutique démarre souvent avec peu d’extensions puis en ajoute pour les avis, le search, les promotions, les abonnements, le support ou l’international.
Créez un registre avec :
- fonction couverte ;
- coût actuel et unité de facturation ;
- propriétaire métier ;
- données accessibles ;
- solution de remplacement ;
- coût de désinstallation ou migration.
Une extension gratuite peut avoir un coût élevé si elle ralentit le site, casse une mise à jour ou exige des opérations manuelles. Une extension payante peut réduire le TCO si elle remplace un développement fragile.
5. Paiement et autres coûts variables
Les paiements peuvent combiner une part fixe, un pourcentage, des frais liés au moyen de paiement, au change, aux litiges ou à des services de fraude. Certains modèles de plateforme ajoutent leurs propres conditions selon le prestataire choisi.
Projetez plusieurs volumes : prudent, central et haut. Le comparatif des solutions de paiement e-commerce détaille les critères à vérifier.
D’autres coûts peuvent varier avec l’activité :
- commandes traitées par un OMS ;
- contacts dans un CRM ou une plateforme d’emailing ;
- recherches internes ;
- appels d’API ;
- stockage de données ;
- boutiques, marchés ou utilisateurs supplémentaires.
Gardez les dépenses marketing hors du TCO technique si vous comparez l’architecture. Ajoutez-les dans un budget d’exploitation global séparé pour ne pas mélanger acquisition et technologie.
6. Maintenance et évolution
Une stack doit être corrigée, testée et adaptée. Budgétez au minimum :
- mises à jour du thème, du cœur et des extensions ;
- correction des incidents ;
- tests de non-régression ;
- optimisation des performances ;
- suivi de sécurité ;
- adaptation aux changements d’API ;
- petites évolutions métier ;
- documentation et transfert de connaissances.
Une enveloppe « maintenance » sans contenu n’est pas suffisante. Précisez le nombre de jours, le délai d’intervention, les horaires couverts et ce qui relève d’un nouveau devis.
7. Le temps des équipes internes
Le temps interne est le coût le plus souvent absent des comparaisons. Il peut pourtant inverser le résultat.
Pour chaque tâche récurrente, estimez :
coût annuel = heures par mois × 12 × coût horaire chargé.
Les tâches à observer comprennent les imports, la correction des commandes, la réconciliation des paiements, la mise à jour des promotions, le support des intégrations, les exports manuels et la production des rapports.
Ne valorisez pas uniquement le temps des développeurs. Le temps du marketing, de la finance, du support et de la logistique appartient aussi au TCO lorsqu’il compense une limite de la stack.
8. Le risque, la dette et le coût de sortie
Un budget réaliste réserve une ligne aux événements probables, sans transformer chaque risque en montant arbitraire.
Identifiez les risques, leur probabilité et leur impact :
| Risque | Signal observable | Réponse budgétaire |
|---|---|---|
| Module non maintenu | Retards de version, support absent | Remplacement ou développement alternatif |
| Synchronisation fragile | Échecs et corrections manuelles | Supervision, reprise et refonte du flux |
| Dépendance à une agence | Documentation faible, accès incomplets | Transfert, audit et second prestataire |
| Montée de version majeure | Version en fin de support | Projet de mise à niveau et recette |
| Changement de plateforme | Limite métier bloquante | Export, migration, redirections et double exploitation |
Le coût de sortie couvre l’export des données, la reconstruction des fonctions, la migration SEO, les tests et une éventuelle période où deux systèmes fonctionnent en parallèle.
La feuille de calcul TCO sur 36 mois
Utilisez une ligne par coût et conservez la source de chaque hypothèse.
| Poste | Initial | Mensuel | Variable sur 36 mois | Temps interne | Sortie/risque | Total 36 mois |
|---|---|---|---|---|---|---|
| Plateforme | ||||||
| Design et développement | ||||||
| Applications et modules | ||||||
| Hébergement et sécurité | ||||||
| Intégrations | ||||||
| Paiement et fraude | ||||||
| Données et mesure | ||||||
| Maintenance | ||||||
| Opérations manuelles | ||||||
| Migration ou sortie |
Pour chaque ligne :
Total 36 mois = initial + mensuel × 36 + variable + temps interne + sortie/risque.
Calculez ensuite deux ratios :
Coût technique par commande = TCO / nombre de commandes livrées.
Poids de la stack = TCO / chiffre d’affaires net projeté.
Ces ratios ne donnent pas une norme universelle. Ils permettent de comparer des scénarios qui n’ont pas la même structure tarifaire.
Construire trois scénarios plutôt qu’un budget unique
Scénario prudent
Croissance faible, peu de dépassements de volume, équipe stable. Ce scénario vérifie que le projet reste soutenable si les ventes progressent moins vite que prévu.
Scénario central
Hypothèses retenues par le plan d’activité : commandes, pays, utilisateurs, catalogue et besoins d’évolution les plus probables.
Scénario haut
Volumes plus élevés, nouveaux canaux et paliers tarifaires. Il vérifie si l’architecture reste économiquement cohérente lorsque l’activité accélère.
Ajoutez un test de sensibilité sur les trois variables les plus importantes : volume de transactions, jours de maintenance et coût des applications. Une faible variation qui change le verdict signale une décision fragile.
Comparer SaaS, open source et sur-mesure
SaaS
Le SaaS concentre davantage de coûts dans l’abonnement et les applications. Il peut réduire l’administration de l’infrastructure et rendre certaines dépenses plus prévisibles.
Open source
L’open source réduit ou supprime une licence du cœur, mais exige hébergement, intégration, mises à jour et responsabilités techniques. Il devient économique lorsque la liberté obtenue évite des contournements coûteux et que l’exploitation est maîtrisée.
Sur-mesure ou composable
Le sur-mesure et le composable déplacent le budget vers l’architecture, le développement, les API, les tests et l’observabilité. Ils ne sont rationnels que si des capacités différenciantes financent cette complexité.
Le comparatif des plateformes e-commerce aide à sélectionner les scénarios à chiffrer. Pour le duel le plus fréquent en France, consultez aussi Shopify ou PrestaShop.
Les erreurs qui faussent le calcul
Utiliser des fourchettes sans périmètre
Un « site entre X et Y euros » ne précise pas forcément le catalogue, les intégrations, la migration, la maintenance ni le niveau de design. La fourchette seule ne permet pas de décider.
Oublier les paliers
Une application peu chère au lancement peut changer de tarif avec les commandes, contacts ou marchés. Projetez la consommation attendue chaque année.
Compter le développement et oublier la recette
Une fonction livrée mais non testée sur les taxes, remboursements et erreurs n’est pas terminée. La recette et la correction doivent être budgétées.
Donner une valeur nulle au temps interne
Une opération manuelle reste un coût même si elle n’apparaît pas sur une facture. Elle augmente aussi le risque d’erreur et limite la capacité de l’équipe.
Comparer des durées différentes
Un devis de création et un abonnement annuel ne sont pas comparables directement. Ramenez chaque scénario à la même période et au même volume.
Questions fréquentes
Combien coûte une stack e-commerce ?
Le montant dépend du périmètre, des volumes, des intégrations et du modèle d’exploitation. Un chiffre unique serait trompeur. La méthode consiste à chiffrer les mêmes capacités sur trente-six mois.
Quelle durée utiliser pour calculer le TCO ?
Trois ans offrent un bon compromis pour un choix de plateforme. Cinq ans peuvent être utiles pour une architecture d’entreprise, avec davantage d’incertitude sur les tarifs et les besoins.
Faut-il inclure le marketing ?
Pas dans le TCO technique si l’objectif est de comparer des plateformes. Conservez un budget global séparé qui additionne technologie, opérations, acquisition et contenus.
Comment comparer une licence gratuite à un SaaS ?
Attribuez une valeur à l’hébergement, aux mises à jour, au support, au temps interne et au risque. Comparez ensuite les deux totaux sur la même période.
Quand mettre le calcul à jour ?
Revoyez-le avant un renouvellement important, l’ajout d’un pays ou d’un canal, une refonte, un changement de volume ou une montée de version majeure.