Demande de devis en ligne et questionnaire en plusieurs étapes

Le problème concret du marchand : la rupture entre panier standard et vente sur devis

Dans l'univers du commerce électronique, le parcours d'achat conventionnel repose sur une hypothèse simple : un visiteur consulte un catalogue, place un article au panier et procède immédiatement au paiement en ligne par carte bancaire. Ce modèle direct convient parfaitement aux produits de grande consommation. En revanche, pour un volume considérable d'entreprises opérant dans le commerce interentreprises ou vendant des biens à fortes contraintes techniques, ce tunnel transactionnel standardisé crée une rupture opérationnelle majeure. Les acheteurs professionnels ne commandent pas des équipements industriels, des matières premières ou des volumes personnalisés comme de simples articles de détail.

Le premier obstacle rencontré par le marchand réside dans l'incapacité du panier classique à recueillir des besoins complexes. Un client professionnel a souvent besoin de soumettre des spécifications précises, de solliciter des remises quantitatives, d'indiquer des impératifs de livraison ou d'obtenir une validation interne avant tout engagement budgétaire. Face à une boutique en ligne qui n'offre qu'un passage en caisse immédiat, ce visiteur qualifié abandonne le site. S'il se rabat sur un formulaire de contact générique, les informations collectées arrivent incomplètes, dépourvues de référence produit précise et dispersées dans des boîtes de réception électroniques individuelles.

Cette dispersion entraîne un surcoût de traitement quotidien pour les équipes commerciales. Le marchand doit recontacter le prospect par courriel ou par téléphone pour lui réclamer les données manquantes élémentaires. Chaque échange supplémentaire prolonge le délai d'instruction du dossier et accroît le risque que le prospect se tourne vers un concurrent plus réactif. L'enjeu technique consiste donc à proposer un recueil structuré sur la boutique sans pour autant déstabiliser la structure du catalogue, une problématique d'architecture logicielle que nous avions déjà explorée lors de notre analyse sur PrestaShop Headless ou Shopify pour les marchands en quête d'autonomie.

L'absence de recueil structuré des besoins en ligne oblige les marchands à un traitement manuel fastidieux qui ralentit la réponse commerciale.

Le second dysfonctionnement concerne l'absence de traçabilité des dossiers commerciaux. Lorsqu'une sollicitation tarifaire est formulée par un message informel, elle échappe aux outils d'analyse et de gestion de l'activité. Les responsables de la boutique ne disposent d'aucun indicateur consolidé pour savoir combien d'estimations ont été demandées, combien ont été traitées ou quelles sont celles qui dorment sans réponse. Le marchand a donc besoin d'un canal dédié, accessible directement sur la vitrine, qui transforme une intention d'achat technique en une fiche structurée et exploitable dans son back-office.

Ce que fait la demande de devis en ligne dans CodeMyShop

CodeMyShop est un PaaS e-commerce open source, sous licence AGPL-3.0, présenté comme souverain et européen, conçu en France par Alexandre Carette. Conçu sur une stack 100 % TypeScript articulant Nuxt 4, Drizzle, PostgreSQL et intégrant une brique d'IA, CodeMyShop propose un modèle économique clair : 0 % de commission sur les ventes et un auto-hébergement gratuit. La plateforme intègre nativement la prise en compte des besoins commerciaux spécifiques à travers une mécanique d'évaluation tarifaire directement connectée à ses bases de données.

La fonctionnalité de demande de chiffrage repose sur des mécanismes éprouvés et rigoureusement définis :

• Le prospect envoie une demande de devis depuis la vitrine en sélectionnant les articles ou en explicitant son projet.
• Le marchand la traite dans le hub et fait évoluer son statut à mesure que le dossier progresse dans son traitement.
• La demande est relayée vers le CRM afin de centraliser l'historique de la relation commerciale sans double saisie.
• Une variante en bêta met à disposition un questionnaire de devis en plusieurs étapes, entièrement paramétré en base.

L'ensemble de ces fonctionnalités est accessible au sein de l'édition Community, disponible sur le code source public de CodeMyShop. L'architecture logicielle a été allégée pour supprimer les dépendances superflues, selon une approche d'épuration du code dont nous présentions les principes dans notre retour sur la Révolution S.O.A.P appliquée au commerce moderne.

Le tableau ci-dessous synthétise les rôles et les interactions des différents modules impliqués dans ce flux :

Grâce à ce dispositif, la donnée saisie sur la vitrine est immédiatement persistée dans PostgreSQL via l'ORM Drizzle. Le marchand évite ainsi l'empilement d'extensions tierces fragiles et maintient une cohérence absolue entre ses tables de données et son interface d'administration.

Comment utiliser la demande de devis et le questionnaire, écran par écran

L'utilisation de la solution se caractérise par une ergonomie épurée, pensée pour guider le prospect sans le perdre dans des champs superflus et offrir au marchand un espace de pilotage fonctionnel. La circulation des informations s'effectue sans couture entre les deux grands environnements de CodeMyShop : la vitrine publique et le hub de gestion.

Le fonctionnement opérationnel s'articule concrètement autour des étapes suivantes :

1. Depuis la vitrine : le visiteur parcourt le catalogue de la boutique. Dès qu'un produit ou une sélection requiert une estimation sur mesure, le prospect envoie une demande de devis depuis la vitrine. Il renseigne les coordonnées de son organisation, détaille les références concernées et formule ses contraintes spécifiques dans les champs prévus à cet effet.
2. Avec la variante en bêta : pour les configurations qui exigent un cadrage approfondi, le visiteur est guidé à travers un questionnaire de devis en plusieurs étapes. Chaque étape isole une dimension du besoin pour faciliter la saisie sans surcharger la vue. Ce questionnaire est entièrement paramétré en base, permettant aux équipes techniques de structurer les questions directement dans leurs schémas PostgreSQL.
3. Dans le hub : dès la validation par le prospect, la demande apparaît dans l'interface de gestion du marchand. L'équipe commerciale prend connaissance de l'ensemble des données fournies, vérifie la faisabilité technique ou les disponibilités, puis traite la demande dans le hub et fait évoluer son statut pour refléter la prise en charge du dossier.
4. Vers le CRM : parallèlement à cette gestion interne, la demande est relayée vers le CRM intégré à CodeMyShop. Cette passerelle assure que les coordonnées du contact et les spécificités de son besoin viennent enrichir la base de prospection globale, garantissant une parfaite continuité du suivi commercial.

Ce double parcours permet d'assurer une transition fluide depuis la découverte publique jusqu'au traitement interne. Cette démarche d'indépendance technologique et de maîtrise des outils internes s'accorde avec les principes d'autonomie développés dans notre guide sur le Triptyque Souverain pour les dirigeants du numérique.

Le traitement centralisé dans le hub offre une traçabilité immédiate sans dépendre de courriels isolés.

La vitrine collecte l'information de manière ordonnée, le hub permet de piloter la vie du dossier commercial, et le relais vers le CRM élimine les ressaisies manuelles qui pénalisent l'efficacité des équipes de vente.

Pour qui la demande de devis est faite, et pour qui elle ne l'est pas

La pertinence d'un système de chiffrage préalable dépend étroitement de la typologie des produits commercialisés, de la nature de la clientèle et des modes de facturation adoptés par l'entreprise. Ce mécanisme a été conçu pour répondre à des modèles d'affaires spécifiques et ne doit pas être déployé indistinctement sur toutes les vitrines en ligne.

Cette fonctionnalité répond précisément aux attentes des acteurs suivants :

• Les marchands B2B traitant des commandes de volume où les tarifs dépendent de grilles dégressives, de paliers d'achat ou de contrats cadres annuels.
• Les distributeurs de biens d'équipement, de machines professionnelles ou de pièces techniques nécessitant une validation de compatibilité avant toute expédition.
• Les entreprises dont les cycles de vente s'inscrivent dans une logique de maturation progressive, semblable à celle décrite dans notre dossier sur le tunnel de conversion appliqué aux contextes B2B.
• Les développeurs et intégrateurs exploitant une stack moderne en TypeScript qui recherchent une base Nuxt 4 et PostgreSQL sous licence AGPL-3.0 pour garder un contrôle intégral sur le cycle de vie des données.

À l'opposé, ce système présente des frictions inutiles pour plusieurs profils de boutiques :

• Les commerces B2C de détail vendant des produits standardisés à faible valeur unitaire, où la décision d'achat est immédiate et requiert un règlement instantané.
• Les boutiques dont les stocks sont fixes, les prix non négociables et les modalités de transport totalement automatisées dès la commande.
• Les marchands qui ne disposent d'aucune équipe commerciale pour traiter les dossiers entrants : un système de devis non suivi d'un traitement rapide dans le hub crée une déception client plus grande qu'un panier traditionnel.
• Les entreprises cherchant un logiciel de facturation complet et autonome intégré au front-office, CodeMyShop se limitant à la capture de la demande, à son suivi dans le hub et à son relais vers le CRM.

En identifiant clairement les cas d'usage appropriés, le marchand préserve la clarté de son catalogue tout en fournissant un outil de recueil adapté à ses clients stratégiques.

Les limites actuelles du devis en ligne et du questionnaire en plusieurs étapes

Adopter une solution open source implique une compréhension lucide et transparente de son périmètre fonctionnel. Il est indispensable de distinguer ce qui est effectivement livré dans l'édition Community de ce qui relève d'outils complémentaires ou de développements sur mesure.

Dans sa version actuelle, la solution comporte des délimitations précises qu'il convient de connaître avant tout déploiement :

• Aucune génération du devis en PDF : la plateforme enregistre la demande et met à jour son statut dans le hub, mais elle ne génère pas de devis chiffré en PDF ; seul un accusé de réception PDF, sans prix, est envoyé au prospect avec l'email de confirmation. Le chiffrage formel doit être rédigé sur vos outils habituels.
• Aucune signature électronique : CodeMyShop n'embarque aucun module de signature légale ou de recueil de consentement électronique pour sceller contractuellement l'estimation en ligne.
• Aucune acceptation en ligne : l'acceptation du devis en ligne n'est pas livrée ; la conclusion de l'affaire se fait par échange direct avec le marchand.
• Paramétrage du questionnaire en base uniquement : le questionnaire de devis en plusieurs étapes est actuellement une variante en bêta. Son paramétrage n'a pas encore d'écran dans le hub. Toute création ou modification de questions requiert une configuration directe dans les tables de la base de données PostgreSQL gérées par Drizzle.
• Formulaire standard pensé pour les entreprises françaises : il exige un nom d'entreprise et un SIRET à 14 chiffres.
• Relais CRM sans alerte : si le relais vers le CRM échoue, la demande reste enregistrée et visible dans le hub, mais sans fiche CRM associée.

Le tableau récapitulatif suivant dresse l'état des lieux rigoureux des fonctionnalités disponibles et des frontières techniques actuelles :

Cette transparence technique permet aux architectes logiciels et aux marchands de calibrer leur système d'information. Le devis chiffré se rédige donc dans l'outil de gestion commerciale habituel, à partir des informations centralisées dans le hub.

Pour évaluer la plateforme, configurer votre environnement ou tester le code source de l'édition Community, rendez-vous sur le parcours de démarrage CodeMyShop.

À lire aussi

• PrestaShop vs Shopify en 2026 : posséder sa boutique ou la louer ?