Choisir une plateforme e-commerce : contrôle, coûts et travail quotidien

Ce que nous ferions

Nous développons des modules PrestaShop, et notre recommandation doit être lue en tenant compte de cet intérêt. Pour une boutique existante, nous commencerions par tester le besoin non couvert sur la configuration actuelle. Une catégorie lente, un thème peu pratique ou un connecteur défaillant nécessite un diagnostic avant de justifier un changement de plateforme.

La démarche dépend de vos modules et développements spécifiques installés, des intégrations, du thème, de la qualité des données, des marchés de vente et des personnes qui maintiennent la boutique. Consignez le besoin que la boutique actuelle ne satisfait pas et le coût de sa résolution. Comparez-le à un remplacement ayant démontré le même fonctionnement avec vos données, en incluant la formation du personnel et la reconstruction des intégrations.

Lorsqu'un changement se justifie, préparez une cible propre et prise en charge, puis testez-la hors production. Pour les changements au sein de PrestaShop, utilisez une copie de préproduction avec le thème, les modules et la configuration réels ; pour un changement de plateforme, répétez les imports vers la cible proposée. Isolez les paiements, emails et exports logistiques de test, protégez les données clients copiées et excluez la boutique de test des résultats de recherche. Répétez la synchronisation finale et la bascule planifiée, avec un plan de retour tenant compte des commandes reçues après le lancement.

Pour un besoin PrestaShop incertain, le PrestaShop Module Selection & Fit Assessment teste les paramètres natifs, les modules candidats et la nécessité d'un développement spécifique sur une copie contrôlée de la boutique.

Quelle piste tester en premier ?

Choisir le modèle d'exploitation

Commencez par déterminer qui exploitera la boutique. Shopify fournit un service de commerce hébergé. Avec PrestaShop auto-hébergé, vous choisissez l'hébergeur et contrôlez les fichiers de l'application et la base de données. Vous pouvez déléguer la maintenance de l'infrastructure de PrestaShop auto-hébergé à un hébergeur infogéré. Une agence peut entretenir les personnalisations et les intégrations de la boutique sur l'une ou l'autre plateforme.

L'hébergement infogéré peut réduire votre charge technique. Il ne supprime pas votre responsabilité de convenir de qui applique les correctifs, restaure les sauvegardes et gère les incidents. Une plateforme hébergée vous laisse aussi la responsabilité des comptes du personnel, des permissions des applications, des règles produit, de la configuration fiscale et du traitement des données clients.

Si vous recherchez un lancement simple avec peu de travail d'infrastructure, un service hébergé mérite un essai. Si vous avez besoin d'un accès direct aux données ou de modifications de l'application, testez une option auto-hébergée. La taille du catalogue ou le chiffre d'affaires mensuel ne peuvent pas décider seuls de ce choix.

Comprendre les licences et la portabilité

Le cœur de PrestaShop utilise l'Open Software License 3.0. Les thèmes, modules et dépendances incluses ont des licences distinctes. L'accès au code source vous donne le contrôle d'une copie sous licence ; il ne vous transfère pas les droits d'auteur.

Votre boutique ne se limite pas à sa base de données. La configuration est répartie entre des tables et des fichiers tels que app/config/parameters.php. Le préfixe des tables est configurable ; ps_ n'est qu'un exemple. Incluez les fichiers de l'application, les modules, surcharges, thèmes, images, fichiers téléversés, téléchargements et secrets cryptographiques dans votre plan de reprise, avec la base de données. Consignez les paramètres PHP, de base de données et de serveur web. Testez une restauration complète.

Distinguez changement d'hébergeur et changement de plateforme. Un changement d'hébergeur peut préserver l'application PrestaShop après des changements de configuration. Un changement de plateforme nécessite toujours une correspondance des champs et le remplacement des thèmes, modules et intégrations incompatibles.

• Testez les exports des produits, déclinaisons, images, clients, commandes, remises et champs SEO avant de vous engager.
• Établissez séparément les correspondances pour les anciennes commandes, les abonnements et les enregistrements propres aux applications.
• Prévoyez des réinitialisations de mots de passe lorsque leurs hachages ne peuvent pas être transférés ou réutilisés.
• Interrogez votre prestataire de paiement sur la portabilité des jetons de cartes enregistrées. Posséder la base de données ne rend pas les jetons du prestataire portables.
• Comparez les exigences d'URL avant de choisir : Shopify utilise les préfixes fixes /products/ et /collections/, tandis que PrestaShop permet de configurer les modèles d'URL simplifiées dans Paramètres de la boutique > Trafic et SEO. Vérifiez les balises canoniques, hreflang et les données structurées de la mise en œuvre proposée. Établissez un plan de redirection des URL et validez les pages de destination importantes.

Un module autonome peut rester utilisable après la cessation d'activité de son auteur, dans les limites de sa licence. Les services externes, les contrôles d'activation et les évolutions futures de l'environnement d'exécution peuvent toutefois l'affecter. Obtenez les conditions de mise à jour, de support et de dépendance aux services avant l'achat. Pour un développement commandé, convenez de la livraison des sources, des droits de licence, des instructions de compilation et des accès aux comptes de services avant le début des travaux. Faites détenir par la boutique les identifiants nécessaires à la reprise par un autre mainteneur.

Utilisez le guide de sauvegarde et le guide de migration de plateforme pour préparer une sortie.

Comparer les coûts sur des hypothèses équivalentes

Construisez un budget sur trois ans avec le même pays d’établissement du marchand, la même devise de règlement, la même base fiscale, la même répartition des cartes, les mêmes moyens de paiement, le même nombre de transactions et la même périodicité de facturation. Incluez les cartes internationales, la conversion de devises, les remboursements, les litiges et les éventuels tarifs négociés. Convertissez les devis en devises étrangères de façon cohérente.

36-month total = setup + theme + migration
               + hosting or platform subscriptions
               + apps/modules and update/support renewals
               + development, maintenance and staff time
               + payment processing and applicable platform transaction fees
               + backups, monitoring, tax services and other integrations
Payment processing = sum(volume for each payment type × its rate)
                   + sum(transaction count for each payment type × its fixed fee)

Les abonnements Shopify, les frais de traitement des paiements, les frais de transaction liés au recours à un prestataire tiers et les frais d'applications sont des postes distincts. Les frais de transaction supplémentaires dépendent du forfait et de l'organisation des paiements, avec des exemptions notamment pour les configurations Shopify Payments éligibles. Le cœur PrestaShop n'ajoute pas de commission proportionnelle aux ventes pour la plateforme. Votre prestataire de paiement, vos modules et services externes peuvent néanmoins facturer des frais de transaction.

Les scénarios de vente suivants servent à la planification, pas de seuils recommandés pour choisir une plateforme. Ils montrent seulement le calcul pour un volume mensuel constant. Un écart de taux d'un point de pourcentage est hypothétique et exclut les frais fixes par paiement.

Pour chaque scénario, saisissez le nombre réel de transactions et des devis de prestataires équivalents des deux côtés. Ne comparez pas un tarif de carte américaine avec un tarif de carte de l'EEE. Appliquez les frais de plateforme uniquement aux transactions éligibles. Ajoutez ensuite les autres postes budgétaires avant de conclure.

Vérifiez les tarifs Shopify et ses règles de frais de transaction pour votre pays. Consignez la date du devis et la périodicité de facturation. Les promotions ne sont pas le tarif de renouvellement à long terme.

Comparez les ensembles d'extensions fonctionnalité par fonctionnalité. La licence d'un module acheté et l'accès aux futures mises à jour sont des droits différents. Business Care de PrestaShop Marketplace comprend un abonnement initial et un renouvellement annuel automatique sauf résiliation. Les vendeurs indépendants et les fournisseurs d'extensions WooCommerce fixent leurs propres conditions. Incluez ces renouvellements et les abonnements aux services externes.

Ne calculez le retour sur investissement de la migration qu'après avoir obtenu un devis et estimé vos économies récurrentes. Incluez la bascule et le coût d'exploitation des deux boutiques pendant la transition. Dans l'exemple à 25 000 EUR mensuels, l'écart hypothétique en points de pourcentage ne produit 9 000 EUR sur 36 mois que si ce volume et cet écart de taux s'appliquent sur toute la période. C'est une ligne budgétaire à comparer à la mise en œuvre, aux renouvellements et à la maintenance, pas une économie acquise en choisissant PrestaShop.

Transformer le budget en grille fournisseur

Remettez la même liste de besoins à chaque fournisseur. Pour chaque point, indiquez s'il relève du natif, d'une extension payante, d'un service externe ou d'un développement spécifique ; précisez l'édition, le titulaire de la licence, les modalités de renouvellement et le responsable des mises à jour. Demandez ce qui change si vous ajoutez un marché, remplacez le thème ou cessez de payer le support. Une intégration non chiffrée reste un poste budgétaire non résolu.

Évaluer les possibilités et limites de Shopify

Shopify regroupe l'hébergement, l'administration de la boutique, les intégrations de paiement et un écosystème d'applications. Cela peut réduire le nombre de fournisseurs d'infrastructure à coordonner. Le lancement dépend toujours de la préparation des produits, de l'approbation des paiements, de la livraison, des taxes et des intégrations nécessaires.

Tunnel de commande et développement sur mesure

Shopify prend en charge les applications personnalisées, les API, Functions et les extensions de paiement dans le cadre des règles de sa plateforme. La personnalisation visuelle du paiement et les applications Functions publiques prises en charge sont disponibles en dessous de Plus. Les extensions après achat et de remerciement ou de statut de commande prises en charge sont également disponibles dans les forfaits inférieurs. Les extensions d'interface sur les pages d'informations, de livraison et de paiement nécessitent Plus. Les applications Functions personnalisées ont des restrictions de forfait distinctes. Faites correspondre chaque modification requise au tableau de disponibilité des applications de paiement.

Sur PrestaShop, vous pouvez étendre le tunnel de commande au moyen de modules, de hooks et de développements. Cette souplesse exige des tests de compatibilité et du parcours de paiement. Pour remplacer le tunnel de commande, consultez la page d'aide de Checkout Revolution.

Paiements, fiscalité et services du réseau

Shopify Payments, Shop Pay, Capital, Balance, Installments, Audiences, POS et Inbox répondent à différentes tâches de paiement, de financement, de marketing et de vente au détail. Vérifiez les exigences de chaque service en matière de pays, de forfait, de matériel et d'éligibilité. L'approbation d'un financement est distincte de l'ouverture d'une boutique.

Shop Pay bénéficie d'une intégration native, mais les plateformes de commerce externes éligibles peuvent l'intégrer via la Shop Pay Wallet API. Il n'est pas réservé à une boutique Shopify.

Shopify Tax inclut des fonctionnalités de TVA pour l'UE et le Royaume-Uni, ainsi que des services pour d'autres marchés pris en charge. Vérifiez le processus de facturation et de fiscalité dont vous avez besoin. Ni un moteur fiscal ni un module de paiement ne remplissent toutes vos obligations déclaratives.

Support et sélection des applications

Le comparatif tarifaire indique un chat en direct 24 h/24 et 7 j/7 pour les forfaits standards et un support téléphonique prioritaire pour Plus. Vérifiez les droits de support actuels avant de contracter. Quelle que soit la plateforme, testez la réactivité des fournisseurs et définissez un canal de contact pour les incidents.

L'examen par une place de marché d'applications est un critère de sélection utile. Évaluez néanmoins les permissions, la compatibilité, les transferts de données, le support et les conditions de sortie de chaque application. Testez une vente réelle en magasin et son remboursement si un système de caisse fait partie de votre activité. Par exemple, vendez un article en ligne et retournez-le en magasin selon la procédure de caisse proposée. Vérifiez où le personnel retrouve la commande, quel système effectue le remboursement et comment évolue le stock. Un catalogue partagé ne prouve pas à lui seul que les activités en magasin et en ligne s'articulent correctement.

Évaluer l'exploitation et la maintenance de PrestaShop

Vous pouvez gérer les produits, commandes et clients depuis le back-office sans écrire de PHP. Le travail technique reste nécessaire pour l'hébergement, les pannes, les intégrations et les montées de version. Prévoyez qui l'assurera.

• Utilisez les langues, devises, règles de taxes, groupes de clients, prix spécifiques, règles panier, déclinaisons et packs natifs lorsqu'ils répondent à vos besoins.
• La précision d'une devise est distincte du mode et du type d'arrondi des prix configurés. Testez les factures et remboursements dans chaque devise de vente.
• Choisissez les modules des prestataires de paiement et vérifiez les restrictions de pays et de devises. Configurez les règles de taxes, la facturation, le consentement et les déclarations pour vos juridictions.
• Testez le partage multiboutique et le comportement des modules dans chaque contexte de boutique. Décidez avant le déploiement si les clients, le stock et les autres paramètres doivent être partagés.

PrestaShop combine des classes et contrôleurs historiques avec une administration fondée sur Symfony. Les hooks permettent des extensions sans modifier le cœur, mais ne garantissent pas la compatibilité avec les futures versions de PHP, de la plateforme ou du thème. Préférez les points d'extension documentés et retestez chaque module pendant les montées de version.

Utilisez Update Assistant, dont le nom technique de module est autoupgrade, pour un parcours de mise à niveau pris en charge. Clonez la boutique dans une préproduction isolée, vérifiez la compatibilité des modules et du thème, effectuez la mise à niveau et testez l'ensemble du parcours d'achat et de remboursement avant la production.

Adaptez PHP à la version exacte de PrestaShop, aux modules et au thème. PrestaShop 9.0 prend en charge PHP 8.1 à 8.4 ; les versions 9.x ultérieures ont leur propre matrice de compatibilité. Choisissez une branche PHP maintenue autorisée par cette matrice. Consultez la configuration système requise propre à la version.

PrestaShop inclut des paramètres de cache Smarty et CSS/JavaScript. La configuration d'installation de la version 9.0 active la mise en cache Smarty et les caches intelligents CSS/JS. Vérifiez les paramètres réels après une installation ou une migration. OPcache dépend de l'hébergement. L'intégration Redis, le cache par proxy inverse et les services CDN nécessitent une configuration supplémentaire. Un module de surveillance Redis ne crée pas un cache d'application. Suivez le guide du cache pour tester les prix personnalisés, les paniers et les sessions.

Évaluez la préparation avec des tests en préproduction, des temps de réponse mesurés et des tests de restauration. La disponibilité du code source, un nom de marque ou le nombre brut de CVE ne vous indiquent pas quelle plateforme est la plus sûre ou la plus rapide pour votre boutique.

Comparer PrestaShop à WooCommerce

WooCommerce ajoute le commerce à WordPress. C'est un candidat pertinent lorsque vos processus existants reposent sur la publication WordPress, son éditeur de blocs, ses taxonomies, sa programmation et ses outils multimédias. PrestaShop propose des pages CMS ; un processus éditorial peut nécessiter un module supplémentaire. Blog Revolution ajoute des articles multilingues, la programmation des publications et des liens entre conseils et produits du catalogue. Testez le travail éditorial réel de votre personnel avant d'y voir un remplacement d'un processus de publication WordPress établi.

Ne considérez pas toutes les données WooCommerce comme des métadonnées d'articles. Les données produit utilisent le modèle WordPress avec des tables de recherche propres aux données e-commerce. High Performance Order Storage stocke les commandes dans des tables dédiées lorsqu'il est activé. Vérifiez la compatibilité des extensions avec HPOS.

Comparez les fonctionnalités natives avec l'ensemble d'extensions que vous installeriez réellement. PrestaShop inclut les champs de catalogue multilingues, les devises, les tarifs par groupe de clients, les déclinaisons et le multiboutique. Pour WooCommerce, précisez le fonctionnement des langues, du changement de devise, des tarifs B2B et de l'exploitation multisite. Les deux proposent des variantes produit, des promotions et une configuration fiscale ; la validation avancée et l'automatisation peuvent nécessiter des extensions des deux côtés.

Testez une tâche de rédaction, l'achat d'une déclinaison, un prix de groupe client et un remboursement chez les deux candidats. Mesurez la recherche, le filtrage et le tunnel de commande avec des données, un trafic et des états de cache équivalents. Incluez les mises à jour de WordPress, WooCommerce, du thème et des extensions dans le plan de maintenance. Évitez de choisir selon un seuil universel de nombre de produits ou un classement supposé des performances.

Comparer Magento Open Source et Adobe Commerce

Distinguez Magento Open Source d'Adobe Commerce payant et de son extension B2B. Les devis, listes de demandes d'achat et approbations de bons de commande d'Adobe Commerce B2B ne sont pas tous inclus dans l'édition gratuite de Magento.

Le développement Magento utilise Composer, l'injection de dépendances, les contrats de service, la mise en page XML et les plugins/intercepteurs. Le déploiement peut impliquer bin/magento setup:upgrade, la compilation de l'injection de dépendances et la gestion des index. Incluez ce processus dans vos devis d'agence et d'hébergement. Le personnel de la boutique effectue toujours le travail quotidien sur le catalogue et les commandes dans son interface d'administration.

Utilisez la matrice des dépendances de la version exacte pour choisir un moteur de recherche et des services de cache et de session pris en charge. Un cache de page complète intégré est disponible. Adobe recommande fortement Varnish en production ; cette recommandation est distincte de l'exigence concernant la recherche catalogue. La prise en charge de Redis, Valkey et des moteurs de recherche varie selon la version.

Faites démontrer vos processus réels multisites, d'attributs, d'ERP et de B2B avant de les payer. Par exemple, faites demander un devis à un acheteur professionnel, approuver l'achat par un responsable et envoyer la commande obtenue vers l'ERP par le personnel. Consignez ce qui se passe si l'acheteur modifie le panier après approbation. Une démonstration des prix par groupe de clients ne prouve pas à elle seule que le processus de devis et d'approbation fonctionne. Comparez des devis de mise en œuvre et des tests de charge équivalents. Ni une quantité de RAM ni un seuil tel que 50 000 références ne détermine quand il faut changer de plateforme.

Comparer PrestaShop à Shopware

Shopware 6 fournit des API Store et Admin, une couche d'abstraction des données et une boutique Twig standard rendue côté serveur. Son administration utilise des composants JavaScript. Évaluez-le si vous avez besoin de plusieurs canaux de vente ou d'une boutique personnalisée.

Le rendu serveur et les API peuvent coexister. PrestaShop 9 inclut une Admin API pour l'administration et les intégrations ; cela n'en fait pas une API complète pour la boutique. Pour un projet headless, faites démontrer la récupération du catalogue et des prix, la connexion client, le panier, la commande et les paiements, puis recensez les besoins d'intégration ainsi que les points d'accès supplémentaires ou développements spécifiques nécessaires.

Shopware permet le téléversement d'extensions ZIP, leur installation, leur activation et leurs mises à jour via Extensions > My Extensions. Le déploiement avec Composer et en ligne de commande constitue d'autres processus. Demandez à votre intégrateur lequel est utilisé pour votre déploiement.

Comparez les Sales Channels de Shopware au multiboutique PrestaShop à partir de vos domaines, assortiments, langues, devises, stocks et besoins de partage des clients. Essayez la configuration réelle dans chaque système. Obtenez des devis d'hébergement pour la même charge et les mêmes services requis. Les besoins de moteur de recherche dépendent de la version et de la charge de travail.

Comparez séparément les offres commerciales autogérées et hébergées. Vérifiez les fonctions de chaque édition, les conditions de licence ou de service, le support local et la documentation des extensions dans les langues de votre équipe. Demandez à votre personnel de suivre les instructions du fournisseur pour une modification produit courante, et à votre développeur d'expliquer le processus de mise en production. Vous vérifiez ainsi si le support et les compétences réellement accessibles conviennent au déploiement, sans supposer que le marché d'origine d'une plateforme détermine son adéquation.

Comparer PrestaShop à OpenCart

Essayez les deux interfaces d'administration avec votre catalogue et votre personnel. OpenCart inclut les options, attributs, prix spéciaux, remises sur quantité, groupes de clients, taux de taxes, classes de taxes et zones géographiques. Ces fonctions ne nécessitent pas toutes des extensions.

Comparez le modèle de stock précis dont vous avez besoin. Dans PrestaShop, une déclinaison peut avoir sa propre référence et sa propre quantité. Dans OpenCart, examinez le comportement des valeurs d'options, des identifiants et des variations de quantité dans la version retenue. Testez une matrice complète de tailles et couleurs, les packs et les mises à jour fournisseurs au lieu de considérer toutes les variantes comme équivalentes. Pour une boutique de vêtements, importez une référence fournisseur et une quantité en stock pour chaque couple taille-couleur, achetez un couple, puis remboursez-le. Vérifiez que seul le stock prévu change et que la mise à jour fournisseur identifie toujours le même article. Des champs de taille et de couleur sélectionnables ne suffisent pas à prouver que le modèle de stock répond à vos besoins.

Les deux plateformes prennent en charge plusieurs boutiques. OpenCart permet d'affecter des produits et catégories aux boutiques sélectionnées. Testez les limites exactes du partage pour les clients, commandes, prix, stocks, thèmes et paramètres de langue, plutôt que de supposer que des assortiments distincts nécessitent PrestaShop.

OpenCart propose un système d'événements ainsi que des mécanismes de modification dépendant de la version, tels qu'OCMOD. Les extensions fondées sur les modifications et les abonnés aux événements présentent des risques d'intégration différents. Les hooks PrestaShop nécessitent aussi des tests de compatibilité. Comparez les extensions précises dont vous avez besoin et les versions qu'elles prennent en charge.

Vérifiez la génération d'URL simplifiées et l'édition groupée sur la version choisie. Comparez les performances de catalogues et d'ensembles d'extensions équivalents. Examinez les historiques de versions datés et les dépendances maintenues ; évitez de supposer que l'un des projets décline ou qu'un nombre de requêtes suffit à prédire les performances.

Réaliser un essai de sélection pratique

1. Consignez les processus essentiels : publication, langues, devises, taxes, déclinaisons, stocks, B2B, POS, livraison, retours et intégrations.
2. Distinguez les besoins couverts par l'édition choisie de ceux nécessitant des extensions payantes et du développement sur mesure.
3. Utilisez un échantillon de catalogue représentatif, comprenant des déclinaisons et règles tarifaires complexes.
4. Demandez au personnel qui utilisera la boutique d'ajouter un produit, de traiter une commande et de la rembourser.
5. Testez les exports, les sauvegardes, les restaurations et un échec d'intégration réaliste.
6. Comparez les mêmes catégories de coûts sur trois ans, les engagements de support et la charge des tests de nouvelles versions.
7. Choisissez l'option répondant à vos besoins avec une organisation de maintenance durable pour vous.

Conserver une grille des besoins avec les preuves de réussite ou d'échec

Pour chaque processus essentiel, conservez les données de test, le résultat attendu, le résultat obtenu et le responsable de tout écart. Associez au résultat la version, le thème, les extensions et la configuration proposés afin que le fournisseur ne puisse pas leur substituer une autre démonstration ultérieurement.

PrestaShop reste un candidat si vous souhaitez accéder à l'application et pouvez organiser la maintenance. Shopify, WooCommerce, Magento Open Source, Adobe Commerce, Shopware et OpenCart répondent à des besoins d'exploitation différents. Votre essai, les conditions contractuelles et le plan d'implémentation doivent déterminer l'adéquation.

Repérer les pièges de comparaison avant de signer

Planifier la bascule et la passation

Un essai réussi prouve que la configuration proposée peut réaliser le travail ; il ne transfère pas l'activité réelle. Si votre boutique existante reçoit des commandes pendant la construction de sa remplaçante, décidez comment les changements intervenus pendant cette période atteindront la cible. Consultez le guide de migration de plateforme pour le détail du transfert.

1. Convenez du périmètre des données : catalogue, comptes clients, commandes, réductions, contenu, redirections et données propres aux intégrations. Consignez ce qui sera importé, conservé pour référence ou reconstruit, et qui valide chaque résultat.
2. Répétez sur une cible de préproduction protégée avec les versions et extensions prévues. Rapprochez les données et les totaux commerciaux de la source, puis faites réaliser au personnel les vérifications d'achat, de traitement des commandes et de remboursement.
3. Chronométrez la procédure réelle et planifiez l'interruption de l'activité à partir de cette répétition. Décidez quand cessent les modifications du catalogue, les flux de stock et les nouvelles commandes, et comment rapprocher les paiements et expéditions en attente.
4. Effectuez des copies restaurables avant la synchronisation finale. Importez les changements depuis la répétition, rapprochez les données finales et basculez le trafic et les intégrations dans l'ordre convenu. Désignez un responsable pour chaque export, tâche planifiée et notification de paiement afin que les deux boutiques n'émettent pas simultanément des opérations réelles.
5. Validez le domaine public, les redirections, l'indexabilité, les statistiques, les emails, le tunnel de commande et les commandes transmises aux systèmes suivants. Retirez les restrictions propres à la préproduction sur la cible destinée à la production, tout en protégeant l'ancienne copie et celles de test de l'indexation publique.
6. Appliquez les conditions d'arrêt convenues si les paiements, le traitement des commandes ou les contrôles de données échouent. Gardez l'ancien environnement disponible pour le plan de retour, et rapprochez les commandes, paiements et mouvements de stock créés après la bascule avant d'y renvoyer le trafic. Restaurer uniquement une ancienne base peut faire perdre de nouvelles données commerciales.

Questions à poser à votre développeur ou agence

• Quels besoins ne sont pas satisfaits sur la boutique actuelle et quelles preuves excluent une correction plus limitée ?
• Quelles versions, édition, thème, modules et contrats de service sont inclus dans le devis, et où sont les résultats d'acceptation ?
• Qui détient les comptes d'hébergement, de domaine, de licence et d'intégration, et un autre mainteneur peut-il obtenir les sources et les instructions de déploiement ?
• Comment rapprocherez-vous l'import final, les transactions en attente et les changements intervenus pendant la coexistence des deux environnements ?
• Qu'est-ce qui déclenche le retour à l'ancienne boutique et comment préserverez-vous l'activité postérieure à la bascule ?
• Qui gère les incidents, les mises à jour d'extensions, les tests de restauration et la formation du personnel après la passation ?

Questions des commerçants

Qui décide si l'essai est concluant ?

Désignez un responsable métier pour chaque processus essentiel. Faites valider les résultats consignés par le personnel qui l'utilisera et demandez à votre développeur d'expliquer les limites techniques. Le fournisseur doit démontrer la solution ; votre entreprise décide si le résultat répond au besoin convenu.

Faut-il choisir une plateforme pour l'entreprise que nous espérons devenir ?

Testez le prochain besoin confirmé et chiffrez le chemin pour y répondre. Une vitrine headless ou un système d'approbation hypothétique exige un responsable, une justification économique et un budget de maintenance avant de figurer parmi les exigences essentielles.

Pouvons-nous garder l'ancienne boutique ouverte après le lancement ?

Conservez une copie de référence protégée si vous avez besoin d'accéder à l'historique, avec une politique convenue de conservation et d'accès. Désignez le système de production chargé des paiements et de l'envoi des opérations logistiques. Laisser actifs les tâches et connecteurs des deux boutiques peut créer des conflits de commandes ou de stocks.

Et si notre agence préférée ne prend en charge qu'un seul candidat ?

Demandez-lui de démontrer vos exigences et de chiffrer les dépendances proposées. Pour un processus essentiel hors de son expérience, obtenez l'avis d'une personne qui maintient ce candidat. La familiarité renseigne utilement sur le support disponible, mais ne prouve pas l'adéquation de la plateforme.

Que faire des besoins qui échouent pendant l'essai ?

Convenez d'une correction démontrée, d'un changement de périmètre chiffré ou d'un autre candidat avant de vous engager. Ne classez une fonction comme facultative que si le responsable métier en accepte les conséquences. Ne laissez pas un processus essentiel de paiement, de stock ou de fiscalité au stade d'une promesse inexpliquée pour après le lancement.