Vous avez identifié un manque au niveau du paiement, de l’administration ou du traitement des commandes. D’ici vendredi, trois options s’offrent à vous : un abonnement mensuel à une application, un devis fixe d’un freelance, et une agence qui souhaite d’abord organiser un atelier de découverte. Cette croisée des chemins représente la véritable décision pour acheter ou développer une application e-commerce – et non un débat philosophique. Cette liste de contrôle est conçue pour être lue en une seule fois, afin que vous quittiez la réunion avec une voie par défaut plutôt qu’une nouvelle semaine de discussions sur Slack.
Ci-dessous : ce que signifient acheter et développer pour une boutique en ligne, les cas où chaque option est préférable, quand demander une petite fonctionnalité à un fournisseur, les coûts que l’on oublie souvent, une grille d’évaluation à imprimer, et trois scénarios courts. Pas d’argumentaire de vente – juste un moyen de choisir sans deviner.
Ce que signifie acheter ou développer une application e-commerce pour une boutique en ligne
Sur Shopify, PrestaShop ou WooCommerce, « acheter » désigne généralement une application, un module ou un plugin de la marketplace que vous installez, configurez et payez via un abonnement ou une licence unique. « Développer » désigne du code sur mesure – une application privée, un module personnalisé, des surcharges de thème ou un middleware – écrit pour vos processus. En pratique, deux voies intermédiaires comptent : configurer fortement le produit existant le plus proche (et s’arrêter avant de forker le code de l’éditeur), ou demander à cet éditeur d’ajouter la pièce manquante à son produit.
L’approche de la Harvard Business Review pour les entreprises de taille moyenne est également utile ici : le choix relève moins de « ce qui est moralement le mieux » et plus de savoir si le manque est un problème courant ou quelque chose qui doit rester le vôtre. Consultez When Should Your Company Develop Its Own Software? pour cette vision plus large. Cependant, les équipes e-commerce ont toujours besoin d’une liste de contrôle adaptée à leur boutique.
Quand l’achat l’emporte
Achetez lorsque le problème est commun, que l’application est maintenue au fil des mises à jour de la plateforme, et que la désinstallation constitue une véritable porte de sortie. Les signaux forts : plusieurs applications réputées décrivent déjà votre cas d’usage dans leur présentation ; les avis mentionnent la version de votre stack technique ; le support répond en quelques jours, pas jamais ; vous pouvez tester avec un sous-ensemble de commandes ou sur une boutique de préproduction (staging).
L’achat l’emporte également lorsque la rapidité compte plus que la singularité – pic de saison dans six semaines, nouveau canal en ligne le mois prochain, ou lacune de conformité que vous ne devriez pas inventer vous-même. Exemples d’opérations qui relèvent généralement de l’achat : exporter de gros CSV de commandes de manière fiable, ajouter une colonne que les marchands attendent déjà, ou accélérer un écran de commandes saturé. Ces modèles se retrouvent dans des guides comme la gestion des commandes WooCommerce en 2025 pour un flux de travail admin plus rapide sans nouveaux onglets – une douleur partagée, des outils partagés.
Quand le développement l’emporte
Développez lorsque le flux de travail vous appartient et qu’aucune offre ne couvre le cas particulier sans mentir. Signaux forts : la règle réside dans le fonctionnement réel de votre entrepôt, de votre tarification B2B ou de la synchronisation marketplace ; les données ne peuvent pas quitter vos serveurs ; la fonctionnalité est un processus compétitif, pas une case à cocher ; chaque démonstration d’application se termine par « nous aurions besoin d’un fork personnalisé ».
Le développement gagne aussi lorsque vous assumerez le résultat pendant des années et pouvez nommer le responsable – un développeur en interne, un partenaire en maintenance avec de la documentation, ou vous avec assez de compétences pour que les hooks fonctionnent après la prochaine mise à jour de plateforme. Si personne ne gère les mises à jour, vous n’avez pas choisi de développer. Vous avez choisi une future panne.
Quand demander au développeur de l’extension à la place
Il y a une autre option entre l’achat et le développement, et elle est sous-utilisée : choisissez l’application ou le module le plus approprié en lequel vous avez déjà confiance, puis demandez à son développeur d’ajouter la petite fonctionnalité dont vous avez besoin.
Si la demande est unique à votre boutique – une règle ponctuelle que personne d’autre n’utilisera jamais – ils diront généralement non, et c’est la bonne réponse. S’il s’agit d’un manque commun que d’autres marchands rencontreront, et que l’extension est activement maintenue, vous obtenez souvent un accord gagnant-gagnant : ils le livrent dans une mise à jour normale, vous évitez de posséder du code personnalisé, et leur produit devient plus fort. Au quotidien avec les modules et applications, cette conversation comble plus de lacunes qu’un projet complet sur mesure.
Gardez la demande petite et concrète (une colonne, un filtre, un champ d’export, une règle de statut). Indiquez comment d’autres l’utiliseraient. Acceptez un « pas sur la feuille de route » sans le transformer en un fork payant de leur paquet – c’est un accord différent, plus risqué.
Les coûts cachés que les deux côtés ignorent
Côté achat : des paliers de licences et de volume de commandes qui bondissent après votre succès ; trois applications qui se chevauchent et se battent pour le même statut de commande ; des formats d’export qui correspondent presque à la comptabilité ; la douleur de migration quand vous partez. Le « forfait mensuel pas cher » devient onéreux quand deux outils font chacun 60 % du travail.
Côté développement : les mises à jour de plateforme (hooks PrestaShop, versions API Shopify, sorties Woo), les patchs de sécurité, la documentation, et le facteur bus quand un seul freelance connaît le repo. La friction d’installation et de mise à jour de modules n’est pas théorique – elle apparaît la semaine où vous en avez le moins envie, c’est pourquoi des articles comme problèmes d’installation ou de mise à jour de modules dans PrestaShop restent pertinents des années après.
Ne confondez pas « demander à l’éditeur » avec la coûteuse voie intermédiaire : acheter une application adaptée à 80 % puis payer quelqu’un pour forker ou patcher le paquet de l’éditeur. Cela coûte souvent plus cher qu’un pur achat ou un développement sur mesure étroit, et vous héritez du risque de mise à jour des deux mondes.
Une liste de contrôle d’une page (note de 1 à 5)
Notez chaque ligne de 1 (favorise l’achat / configuration / demande à l’éditeur) à 5 (favorise le développement). Les totaux sont un coup de pouce, pas un verdict de tribunal.
- Singularité du problème : 1 = besoin très courant du marché, 5 = uniquement votre flux de travail
- Délai de rentabilité : 1 = besoin cette semaine, 5 = peut attendre un mois ou plus
- Taux de changement de plateforme : 1 = les mises à jour cassent souvent ce domaine (préférez un produit maintenu par l’éditeur), 5 = assez rare pour que posséder du code soit réaliste
- Propriété à 12 mois : 1 = support de l’éditeur clair, 5 = seulement vous ou un freelance
- Coût de sortie : 1 = désinstaller et passer à autre chose, 5 = code sur mesure profond à réécrire
- Sensibilité des données : 1 = très bien dans un SaaS ou une app normale, 5 = doit rester sur vos serveurs
Guide approximatif : majoritairement 1 – 2 → achetez ou configurez. Majoritairement 4 – 5 → développez étroit. Milieu mixte → demandez d’abord la petite fonctionnalité au meilleur éditeur ; s’ils refusent ou si le besoin est vraiment unique, limitez un test payant dans le temps (deux jours max) avant de vous engager sur un devis de développement complet.
Trois mini-scénarios
1) Colonnes supplémentaires sur la liste de commandes (date de livraison, bon de commande, message cadeau). Habituellement acheter ou configurer. Le besoin est commun ; des parcours sans code et par application existent déjà – y compris des modèles de personnalisation gratuits couverts dans personnaliser la page des commandes WooCommerce gratuitement sans code. Du PHP sur mesure pour une colonne vaut rarement la taxe de mise à jour. S’il manque une colonne à un module solide, demandez à ce développeur avant de commander un fork privé.
2) Expliquer les termes produits sur la boutique (infobulles, pages de glossaire). Habituellement acheter si une app maintenue fait l’affaire. Construire un système de glossaire complet de zéro recrée des problèmes de recherche, de liens et de traduction que vous n’avez pas demandés – à moins que les définitions soient un produit central de votre marque.
3) Règle de prix B2B étrange (groupe client × région × date contrat × famille SKU). Habituellement développer (ou un pont ERP fortement configuré). Les apps de la marketplace s’arrêtent à « presque », et le « presque » crée des tickets de support à chaque commande. Demander à un plugin de prix générique d’absorber votre logique de contrat est rarement réaliste – c’est une singularité de 5.
Comment décider en une réunion
Apportez la grille de score, pas une ambiance. Nommez le responsable pour le chemin que vous choisissez. En cas d’égalité, choisissez par défaut l’achat pour la douleur d’admin courante, demandez au meilleur éditeur quand il manque une fonctionnalité sur un produit actif, et développez pour la logique de revenu propriétaire – puis planifiez un test de deux jours seulement si ces défauts semblent toujours mauvais. Écrivez la décision en un paragraphe dans votre doc d’opérations pour que la prochaine recrue ne rouvre pas le fil de zéro.
D’après la livraison de modules et d’apps pour marchands : le travail sur mesure qui a bien vieilli était ciblé, documenté et possédé. Le travail douloureux a commencé comme « juste une petite modification » sans plan de mise à jour. Beaucoup de « fonctionnalités manquantes » n’ont jamais eu besoin d’un développement privé – elles avaient besoin d’une requête claire à un éditeur qui possédait déjà le problème. Traitez les choix d’acheter ou développer une application e-commerce d’abord comme des choix de propriété – le budget suit.