TCO e-commerce : ce que coûte vraiment une boutique au-delà de la licence

Sur WooCommerce comme sur PrestaShop, le logiciel de base est gratuit. Drupal Commerce l’est aussi. Un dirigeant qui compare ces trois options sur le seul critère du prix d’entrée conclut logiquement qu’elles se valent. C’est là que commence le malentendu : le prix d’une boutique en ligne ne se lit pas sur la facture d’installation, mais sur trois à cinq ans d’exploitation. Hébergement, maintenance, extensions, montées de version — ce sont ces postes récurrents qui, additionnés, forment le coût total de possession, ou TCO. C’est ce chiffre, et non le prix de la licence, qui doit orienter une décision de plateforme.

Le prix affiché ne raconte qu’une partie de l’histoire

Le choix entre WooCommerce, PrestaShop et Drupal Commerce se pose d’abord en termes de fonctionnalités, d’écosystème et de compétences disponibles en interne ou chez un prestataire — un comparatif détaillé de ces trois plateformes a déjà posé ces critères. La question du coût total est différente et complémentaire : à fonctionnalités équivalentes, deux boutiques peuvent afficher des budgets annuels très éloignés selon la façon dont elles ont été construites et selon ce qui a été anticipé, ou non, dès le départ.

Les postes à additionner sur trois à cinq ans

Un budget de boutique en ligne complet regroupe des dépenses ponctuelles, concentrées sur la première année, et des dépenses récurrentes qui se répètent chaque exercice. Les principaux postes sont :

• l’hébergement et l’infrastructure technique (serveur, CDN, sauvegardes) ;
• la maintenance corrective et les mises à jour de sécurité ;
• les licences des extensions et des thèmes payants, souvent facturées à l’année ;
• les développements spécifiques, ponctuels puis d’évolution ;
• le temps interne consacré au support, à la gestion du catalogue et au pilotage du prestataire ;
• la migration ou la refonte qui accompagne, tôt ou tard, la fin de vie d’une version majeure.

Hébergement et infrastructure

Le poste le plus visible, et le plus facile à sous-estimer dès qu’une boutique grossit : trafic en hausse, catalogue étendu, pics saisonniers. Un hébergement dimensionné pour le lancement ne l’est plus forcément un an plus tard, et son coût suit la croissance de l’activité plutôt qu’un forfait fixe annoncé au départ.

Maintenance, sécurité et fin de support

C’est le poste le plus souvent oublié dans un budget prévisionnel, alors qu’il conditionne la sécurité de la boutique. Toute plateforme e-commerce s’appuie sur PHP, dont le calendrier de support est strict : chaque version bénéficie de deux ans de support actif puis de deux ans supplémentaires réservés aux seuls correctifs de sécurité critiques, avant sa fin de vie complète — le calendrier est public. Une boutique qui ne budgète pas la maintenance régulière de son cœur logiciel et de ses extensions se retrouve, à l’échéance, devant un choix binaire : payer une mise à niveau en urgence, ou continuer à tourner sur une version qui n’est plus corrigée. Le second cas coûte rarement moins cher, il coûte plus tard — et souvent plus cher : un catalogue mal maintenu finit par générer des incidents techniques dont la résolution en urgence dépasse largement le coût d’un entretien régulier.

Extensions, modules et développements spécifiques

WooCommerce et PrestaShop reposent sur un modèle où le cœur est gratuit mais où de nombreuses fonctionnalités utiles à une boutique — moyens de paiement, connecteurs comptables, gestion avancée des stocks — passent par des extensions payantes, généralement sous licence annuelle. Multiplier les extensions revient, avec le temps, à recomposer un abonnement logiciel dont le montant cumulé mérite d’être comparé, poste par poste, à ce qu’un développement sur mesure aurait coûté. Sur Drupal Commerce, la logique s’inverse en partie : le développement initial est plus élevé, mais une part plus importante du résultat appartient au site sans dépendre d’une licence tierce reconductible.

Migration et fin de vie d’une version majeure

Aucune plateforme n’échappe à ce cycle : une version majeure finit par ne plus être maintenue, et la boutique doit migrer. Les grands projets open source, comme Drupal, documentent publiquement leur politique de support et leur cadence de versions majeures — consultable sur drupal.org — ce qui permet d’anticiper l’échéance plutôt que de la découvrir au moment où le support s’arrête. Provisionner cette échéance dès le budget initial évite l’arbitrage dans l’urgence entre migrer et rester exposé. La question se pose d’ailleurs autant côté plateforme que côté organisation : une refonte complète n’est pas toujours la bonne réponse à une fin de support, une migration ciblée peut suffire.

1. Lister les postes existants. Hébergement, licences d’extensions, contrat de maintenance, temps interne estimé : partir de ce qui est payé aujourd’hui, même approximativement.
2. Projeter sur trois à cinq ans. Un budget à un an masque les échéances de montée de version et de renouvellement de licences qui tombent en année deux ou trois.
3. Chiffrer le temps interne. Le temps passé par l’équipe sur le support, la gestion du catalogue ou le suivi du prestataire est un coût réel, même s’il n’apparaît sur aucune facture.
4. Vérifier les échéances de support. Version de la plateforme, version de PHP, fin de vie des extensions critiques : dater ces échéances plutôt que les découvrir a posteriori.
5. Comparer le total, pas le prix d’appel. Mettre en regard le TCO calculé, et non le prix de la licence ou du devis initial, avant d’arbitrer entre plateformes ou entre prestataires.

Ce que cela change concrètement selon la plateforme

Sur le papier, WooCommerce et PrestaShop affichent un ticket d’entrée plus bas que Drupal Commerce, dont le développement initial est généralement plus conséquent. Mais ce ticket d’entrée se rattrape souvent sur la durée par l’accumulation de licences d’extensions et par un temps de maintenance plus fragmenté entre plusieurs modules tiers. Drupal Commerce inverse la proportion : plus cher à mettre en place, potentiellement plus stable et moins dépendant de licences tierces sur la durée. Aucune de ces trois options n’est mécaniquement la moins chère : le TCO dépend du périmètre fonctionnel réel de la boutique, et c’est ce calcul, propre à chaque projet, qui doit trancher plutôt qu’une préférence de principe pour telle ou telle plateforme.

Ce qu’il faut retenir

• Le prix d’une licence ou d’un devis initial ne représente qu’une fraction du coût réel d’une boutique en ligne.
• Hébergement, maintenance, sécurité et licences d’extensions doivent être budgétés sur trois à cinq ans, pas sur la seule première année.
• La fin de support d’une version majeure est prévisible : l’anticiper coûte moins cher que la subir dans l’urgence.
• Comparer des plateformes sur leur TCO, et non sur leur prix d’appel, change souvent la conclusion d’un arbitrage.