Comment créer une boutique en ligne : ce que le projet comprend vraiment

Créer une boutique en ligne, ce n’est pas seulement choisir un modèle. Comment préparer le catalogue, les paiements, la livraison et la rétractation, et quoi vérifier avant la mise en ligne.

Une boutique en ligne n’est pas prête dès que l’on peut y ouvrir la fiche d’un produit et le mettre dans le panier. Elle l’est lorsque l’acheteur voit le bon prix, choisit une variante réellement disponible, paie et reçoit une confirmation compréhensible, et lorsque le vendeur est en mesure d’exécuter la commande et, le cas échéant, de reprendre la marchandise ; le design est la partie la plus visible du projet, mais ce n’est pas lui qui décide si la première commande se termine par une livraison.

C’est pourquoi la question « comment créer une boutique en ligne » doit d’abord être précisée : quel processus de vente doit pouvoir se dérouler sans improvisation ? La réponse commence par un produit et une commande complète, où sont clairs la source des données, la réservation du stock, le résultat du paiement, la création de l’envoi et la conduite à tenir en cas de rétractation. Chaque question sans réponse devient ensuite un périmètre de travail ou une opération manuelle : indiquez le responsable, le délai d’exécution et la limite au-delà de laquelle l’approche manuelle ne convient plus. Sinon, une boutique techniquement achevée continuera de s’appuyer sur un accord oral et sur la mémoire d’une personne.

Dans cet article, l’attention porte sur la préparation et l’acceptation du projet, non sur la comparaison des prix des plateformes ; avant le développement et la mise en ligne, vous devez préparer les données d’entrée, distinguer les fonctions de la boutique du processus de l’entreprise, et accepter le travail sur une vraie commande de test, non sur une capture d’écran. Cette approche vaut aussi bien si vous créez la boutique vous-mêmes que si vous confiez la tâche à un développeur.

Commencez par une commande, pas par le nom d’une plateforme

Avant de choisir la technologie, décrivez une commande ordinaire, de la découverte du produit jusqu’à la livraison, avec un produit concret, un prix, un moyen de paiement et une adresse. Notez ce que font, à chaque étape, l’acheteur, la boutique et votre collaborateur. Si la réponse est « on arrangera cela à la main », indiquez aussi la personne responsable, le temps que l’opération demande et le nombre de commandes à partir duquel cette organisation ne sera plus praticable.

Cette description montre vite si vous avez besoin d’une boutique standard ou d’un traitement des commandes plus individuel, parce qu’un catalogue, une seule logique de prix, un paiement par carte habituel et une consigne automatique n’exigent généralement pas un système complexe, alors que des prix selon le contrat du client, une disponibilité dans plusieurs entrepôts ou une validation dans un autre système changent le périmètre déjà avant le design. Sur une liste de fonctions, les deux projets peuvent se ressembler, mais dans la description du processus la différence devient nette, et on peut la transformer en critère d’acceptation que, à la fin du projet, on peut vérifier sans conjecturer ce que le prestataire avait en tête.

La plateforme se choisit d’après ce processus et la croissance prévue : WooCommerce peut être une solution rationnelle pour un commerce standardisé, tandis que Laravel donne plus de liberté à une logique atypique et aux intégrations ; une comparaison plus large se trouve dans l’article sur quand choisir WooCommerce ou Laravel. À ce stade, l’essentiel est de comprendre que le nom de la plateforme, à lui seul, ne dit pas ce qui arrivera à votre commande.

Ajoutez aussi à la description du processus une exception, et vérifiez ce qui se passe si le paiement échoue, si deux personnes tentent d’acheter en même temps la dernière unité, si la consigne automatique n’est pas disponible ou si le client veut rendre une partie d’un lot. Il n’est pas nécessaire d’énumérer chaque situation rare ; un seul scénario raté révèle pourtant les statuts, les notifications et les devoirs des collaborateurs bien mieux que dix cases cochées en vert sur un devis.

Le catalogue commence par la définition de l’unité vendue

Un fichier Excel de produits n’est pas encore un catalogue, parce qu’il faut d’abord s’accorder sur ce qu’est, dans le système, une unité vendable : pour un livre simple, ce peut être un produit avec un prix et un stock, mais pour un vêtement chaque combinaison de taille et de couleur peut avoir sa propre référence, son image, son code-barres et son stock. Pour un lot, il faut à son tour savoir s’il s’agit d’un produit autonome ou d’un ensemble de plusieurs unités d’entrepôt.

Préparez un produit-échantillon entièrement renseigné avant que l’équipe commence l’importation de masse, et y incluez le nom, la description courte et la description complète, le prix, l’application de la taxe, la catégorie, la variante, la référence, le stock, le poids ou les dimensions utiles à la livraison, les images et toute autre information importante pour l’acheteur. L’échantillon permet de remarquer un champ manquant tant qu’il n’y a qu’une ligne à corriger, et donne en même temps au designer un contenu réel, non une fiche de démonstration idéale.

Un nombre illimité de références dans la solution technique ne signifie pas que préparer quarante produits et en préparer quatre mille demande le même travail, parce que le prix des fonctions de la boutique peut ne pas changer, alors que dans un catalogue plus grand croissent le nettoyage des données, le rattachement des images, le contrôle des variantes, la traduction et l’importation. C’est pourquoi le devis doit indiquer séparément la capacité de la plateforme à stocker un catalogue et le travail à fournir pour rendre vos données utilisables ; ce travail peut comprendre la mise en correspondance des champs, le traitement des lignes erronées, le contrôle des images et la comparaison de l’importation finale avec le fichier source.

Vêtements : la taille et la couleur ne sont pas qu’un filtre

Dans une boutique de vêtements, la taille et la couleur sont souvent des variantes avec leur propre disponibilité, non de simples valeurs de filtre, donc l’acheteur doit voir que le M bleu est épuisé même si le M noir est encore disponible, l’image doit changer avec la couleur choisie et la commande doit recevoir la combinaison exacte. Avant de saisir tout le catalogue, testez un produit avec au moins deux tailles, deux couleurs et une variante indisponible.

Le catalogue a besoin d’un responsable aussi après la mise en ligne, donc déterminez qui change un prix, ajoute une variante, corrige une description et retire un produit de la vente ; si l’information arrive d’un fournisseur ou d’un ERP, il faut fixer la source principale des données et le sens de la synchronisation. Deux endroits où les collaborateurs peuvent corriger un même prix ne créent pas de souplesse, mais les conditions d’un écart. Il faut donc s’accorder sur l’historique des modifications, les droits d’approbation et la conduite à tenir en cas d’importation erronée ; l’équipe doit pouvoir établir dans quelle source est née la valeur fausse et ce qu’elle a déjà affecté.

Le processus de paiement se décrit par des statuts et des actions

L’intégration des paiements n’est pas achevée à l’ouverture d’une fenêtre de paiement, parce que le projet doit s’accorder sur ce que fait la boutique après chaque résultat : un paiement réussi peut changer le statut de la commande, envoyer une confirmation, diminuer la quantité disponible et transmettre une tâche à la préparation. Un paiement échoué ou interrompu ne doit pas ressembler à une commande payée, mais il ne devrait pas non plus réserver la marchandise indéfiniment.

Dans le langage courant, « le paiement a réussi » peut signifier que la banque a confirmé l’opération, que le service de paiement l’a enregistrée ou que l’argent est déjà crédité sur le compte de l’entreprise, et le processus d’exécution ne peut pas reposer sur une formule aussi vague, donc déterminez quel statut système autorise à commencer la préparation et comment le collaborateur voit une commande qui demande un contrôle. Les commandes en paiement à la livraison et par virement se traitent à part, non comme une copie du processus par carte.

Il faut aussi décider combien de temps une commande non payée réserve la marchandise, parce qu’une période trop courte peut libérer l’article pendant que l’acheteur termine encore le paiement, et qu’une période trop longue réduit artificiellement le stock disponible. Les réglages de stock de base de WooCommerce permettent de gérer les quantités et de fixer un délai de réservation pour les commandes non payées, donc une boutique standard peut contrôler son stock interne sans intégration d’entrepôt externe.

Avant la mise en ligne, effectuez au moins un paiement réussi, un paiement interrompu et un remboursement, en mode test ou avec une petite somme réelle, et contrôlez l’écran de l’acheteur, le statut de la commande dans l’administration, les e-mails, la variation de stock et l’enregistrement chez le service de paiement. Si l’équipe n’a vu que le scénario réussi, une grande partie du processus de paiement n’est toujours pas vérifiée, parce que dans le travail réel il faut distinguer une notification bancaire en retard, un paiement interrompu par l’acheteur et une erreur système, et chaque cas doit laisser dans l’administration un enregistrement compréhensible.

Livraison et exécution de la commande ne sont pas une case cochée

Une intégration de livraison peut calculer un prix, afficher des consignes automatiques, créer un envoi et renvoyer un numéro de suivi, mais toutes les solutions ne font pas toutes ces opérations, donc la formule « raccorder un transporteur » doit être remplacée par des questions concrètes : l’acheteur choisit-il une consigne automatique, le prix dépend-il du poids, du montant du panier ou du pays, l’étiquette se crée-t-elle dans la boutique et le lien de suivi arrive-t-il tout seul dans l’e-mail ?

L’exécution de la commande commence après son acceptation, et le collaborateur doit voir clairement les commandes payées et à préparer, ainsi que la conduite à tenir en cas d’erreur. Déterminez qui peut changer le statut, si l’acheteur reçoit une notification et comment le numéro de suivi est enregistré ; dans une petite boutique, une seule personne peut le faire, mais dans une équipe plus grande, sans répartition des responsabilités, une commande peut être préparée deux fois tandis qu’une autre passe inaperçue.

Vérifiez les prix de livraison avec des exemples extrêmes, pas seulement avec un panier moyen, et essayez le produit le moins cher et le plus cher, le seuil de livraison gratuite, une adresse hors du territoire autorisé et un produit qui ne rentre pas dans une consigne automatique. Si le calcul utilise le poids, un seul produit sans poids peut fausser tout le résultat. En cas de prix fixe, il faut savoir qui couvre la différence pour un envoi hors standard ; il faut aussi vérifier la livraison en plusieurs colis et si la méthode reste disponible pour un panier de produits de tailles différentes.

Le retrait au bureau ou en magasin est aussi une méthode de livraison avec ses propres règles, donc l’acheteur doit connaître l’adresse, les horaires et le moment où la commande est prête à être retirée, et le collaborateur d’entrepôt doit l’apprendre à temps. Un bon test ne s’arrête pas à l’inscription « commande reçue », mais à un colis ou une marchandise préparée pour la remise et à une notification précise envoyée à l’acheteur.

Les exigences de commande et de rétractation doivent devenir des actions concrètes

Un contrat à distance peut se conclure sur un site web, par e-mail, par messagerie ou par un autre moyen de communication à distance, donc les devoirs du vendeur ne disparaissent pas si la commande est prise sur un réseau social et que la facture part plus tard ; dans le processus de commande électronique, le bouton ou une action équivalente doit indiquer sans ambiguïté que la commande crée une obligation de payer. Les exigences portent sur la séquence de commande elle-même, pas seulement sur une page de conditions dans le pied de page du site.

L’article L. 221-14 du code de la consommation prévoit que, juste avant une commande électronique, l’acheteur doit notamment voir certaines informations essentielles, le prix final et les coûts supplémentaires, et que les moyens de paiement et les restrictions de livraison doivent être indiqués au plus tard au début de la passation de commande. Comme la composition des exigences peut changer, il faut, avant la mise en ligne, vérifier la rédaction en vigueur ce jour-là et comparer les écrans de la boutique aux normes concrètes.

La confirmation de commande doit inclure une copie des conditions du contrat elles-mêmes, ou un autre document que l’acheteur peut conserver sous une forme inaltérée ; un lien vers une page que le vendeur peut modifier unilatéralement ne suffit pas, donc vérifiez que la confirmation contient les produits commandés, le prix, la livraison, les données du commerçant et les informations précontractuelles requises. Accordez avec un juriste le jeu exact de documents et les formulations, selon votre modèle de vente. Conservez la version utilisée avec la date de la commande, afin qu’en cas de litige on puisse montrer non seulement la page actuelle des conditions, mais aussi les informations réellement fournies à l’acheteur.

Service-public.fr explique que le consommateur dispose en général, pour les biens, d’un droit de rétractation de quatorze jours, comptés à partir de la réception de la marchandise, et que les textes nomment des exceptions précises. Le projet doit prévoir non seulement le texte sur la rétractation, mais aussi un formulaire ou un contact, l’enregistrement de la date de la notification, le contrôle de la marchandise, le remboursement et le rétablissement du stock ; si ces opérations vivent dans la mémoire d’un seul collaborateur, la boutique ne fonctionne que tant que cette personne est disponible.

Une boutique sans entrepôt propre reste un processus du vendeur

On peut exploiter une boutique sans entrepôt physique propre, par exemple en faisant expédier la marchandise par un distributeur ou un fabricant, et cela réduit le besoin de stocker, mais n’annule pas la responsabilité du vendeur envers l’acheteur. Si le contrat est conclu avec votre entreprise, c’est encore votre entreprise qui répond de son exécution envers l’acheteur, non le fournisseur.

Dans ce modèle, l’information de disponibilité est critique, et si le fournisseur fournit un flux de données ou une interface de programmation, il faut s’accorder sur la fréquence de mise à jour, le traitement des erreurs et la conduite à tenir en cas de coupure de connexion. Un retard de cinq minutes peut être décisif pour une dernière unité qui se vend vite, mais acceptable pour un catalogue à rotation lente. La fréquence de synchronisation se fixe d’après le mouvement des stocks et le risque de l’entreprise, et il faut aussi décider si, pendant une erreur de connexion, le produit est masqué, laissé en vente ou passé à un contrôle manuel.

Il importe de distinguer le suivi interne des stocks de la boutique d’un module de gestion d’entrepôt ou d’une intégration externe : les fonctions de base de WooCommerce peuvent stocker une quantité pour chaque produit et chaque variante, la diminuer après une commande et empêcher de commander un produit sans stock, et cela peut suffire pour un catalogue tenu dans la boutique elle-même. Le module de gestion d’entrepôt devient nécessaire si le stock principal vit dans un autre système, s’il y a plusieurs lieux de stockage ou s’il faut synchroniser plusieurs canaux de vente.

Avant la mise en ligne, jouez la situation où le fournisseur ne peut pas exécuter la commande alors que le produit apparaît encore disponible à l’écran, et déterminez qui reçoit la notification, à quelle vitesse on contacte l’acheteur, si l’on propose une alternative et comment on rembourse. Ce scénario ne rend pas le modèle mauvais ; il transforme une complication inattendue en un risque que l’on peut gérer.

Peut-on créer une boutique en ligne gratuitement ?

Créer une boutique en ligne gratuitement peut vouloir dire plusieurs choses différentes, par exemple un modèle de design gratuit, un logiciel libre, une formule d’essai ou une vitrine sur un réseau social. Ces outils peuvent réduire les frais de licence initiaux et aider à vérifier si l’offre intéresse, mais ils n’annulent pas le travail sur les données produits, les paiements, la livraison, les conditions, la sécurité et l’administration quotidienne.

Si vous créez la boutique vous-mêmes, commencez par le plus petit processus que l’on puisse exécuter correctement, parce qu’une seule langue, un petit catalogue, un moyen de paiement et une méthode de livraison permettent de tester la demande sans prendre en charge la maintenance d’intégrations complexes. Même dans cette version, l’acheteur doit voir le bon prix et les conditions de livraison, la commande doit arriver dans l’administration, et vous devez pouvoir envoyer la marchandise et traiter une rétractation.

Les coûts apparaissent en général là où l’outil gratuit s’arrête : sur le nom de domaine et l’hébergement, les commissions de paiement, les extensions payantes, l’importation des données, l’adaptation du design, la maintenance et votre propre temps, donc comparez non seulement l’abonnement mensuel, mais aussi les heures qu’il faudra pour le catalogue, la correction des erreurs et les mises à jour. Dès la phase d’essai, notez les travaux répétitifs, parce qu’un outil gratuit peut être économique précisément tant que le service manuel ne mange pas l’économie réalisée sur la licence. Si vous exécutez une opération manuelle pour cinq commandes, elle peut se justifier ; pour cinq cents commandes, c’est déjà une ligne de coût mesurable.

Une aide professionnelle devient rationnelle lorsqu’une erreur coûte plus cher que la mise en place, ou que le processus ne tient plus dans la journée d’une seule personne, et un tel seuil peut se lire dans des stocks qui ne coïncident plus, plusieurs langues et groupes de prix, des contrôles manuels répétés des données ou des intégrations avec la comptabilité et les fournisseurs. Une boutique créée par vos propres moyens n’est pas un échec, et faire appel à un développeur n’est pas l’étape suivante obligatoire ; ce sont la complexité du processus et la capacité de l’entreprise à le maintenir qui fixent la décision. Il faut dans l’équipe une personne qui contrôle régulièrement les mises à jour, les sauvegardes, les avis de sécurité et les journaux d’erreurs, et il faut pouvoir rétablir le processus d’achat après la mise à jour des extensions et documenter la solution de façon que la boutique ne dépende pas du temps libre d’un collaborateur.

Quel que soit l’exécutant, les comptes du nom de domaine, de l’hébergement, du service de paiement et de la livraison doivent rester sous le contrôle de l’entreprise, non liés à l’adresse personnelle d’un collaborateur ou d’un prestataire externe ; notez où l’on conserve les accès, qui peut valider les paiements et comment on rétablit l’accès en l’absence de la personne responsable. Dans un projet fait par vos propres moyens, cet ordre vaut autant qu’en prestation externe, parce que les droits d’administration de la plateforme ne signifient pas encore le contrôle du nom de domaine, du serveur et des contrats des services externes.

Contenus et migration se préparent avant la fin du développement

Un projet de boutique est souvent retardé non par le code, mais par des données produits manquantes, des images et des décisions, donc déterminez qui, dans l’entreprise, fournit le contenu, qui l’approuve et quels champs sont obligatoires, et chaque résultat intermédiaire a besoin d’une date. Le développeur peut créer le champ de la description, mais ne peut pas décider à la place de l’entreprise ce que l’on a le droit de promettre sur le produit.

Les images demandent une proportion unifiée, une résolution suffisante et le droit de les utiliser ; contrôlez les noms de fichiers, les textes alternatifs et quelle photo appartient à une variante précise. Si le fournisseur change les adresses d’images sans préavis, le lien externe peut disparaître, donc le processus plus sûr consiste en général à importer et optimiser les images de façon contrôlée dans l’environnement de la boutique, en conservant le lien avec l’identifiant du produit.

Dans une migration, il faut énumérer à part les produits, les catégories, les clients, l’historique des commandes, les coupons, les contenus et les fichiers, parce que tout n’a pas le droit ni le besoin d’être transféré, et les données clients historiques s’évaluent aussi du point de vue de la protection des données et des durées de conservation. Avant la migration complète, faites un essai sur un petit jeu de données, comparez le nombre d’enregistrements et les champs, et seulement alors fixez le moment à partir duquel l’ancien système n’est plus modifié ; après l’importation finale, préparez un relevé des enregistrements manquants, des doublons et des valeurs que le nouveau système a interprétées autrement.

En changeant de site, préparez la carte des anciennes et des nouvelles adresses, parce qu’une adresse sans redirection emmène l’utilisateur et le moteur de recherche vers une page inexistante, et la redirection à elle seule ne garantit pas le positionnement précédent, mais elle aide à conserver un chemin logique et à transmettre les signaux à la nouvelle page correspondante. Après la mise en ligne, vérifiez les adresses les plus importantes de produits et de catégories, pas seulement la page d’accueil.

Avant la mise en ligne, exécutez un test d’acceptation complet

Dans le test d’acceptation, utilisez un scénario d’acheteur réaliste avec un produit concret : ouvrez la boutique sur un téléphone, trouvez le produit par la recherche ou une catégorie, choisissez une variante, mettez-la dans le panier et changez la quantité, puis contrôlez le prix avec les taxes, la remise prévue et la livraison. Continuez jusqu’à la passation de commande, payez et lisez tous les écrans et tous les e-mails.

Continuez le test dans l’administration : contrôlez le statut de la commande, la diminution de stock sur la variante exactement choisie, l’adresse, la consigne automatique et la note de l’acheteur, créez l’envoi, envoyez les informations de suivi et clôturez la commande. Enfin, traitez une rétractation et un remboursement, parce qu’un cycle complet révèle souvent que chaque fonction marche isolément, mais que l’information ne passe pas d’une fonction à l’autre.

Répétez un test plus court avec des erreurs : un coupon invalide, une variante indisponible, un paiement interrompu, une adresse hors zone de livraison et la dernière unité d’un produit ; le message d’erreur doit expliquer l’étape suivante, et le système ne doit pas laisser une réservation incorrecte. Le résultat du test doit fournir non seulement une liste d’erreurs, mais aussi une décision sur celles qui bloquent la mise en ligne. Pour chaque correction, indiquez le responsable, la date du nouveau contrôle et la preuve d’acceptation, puis assurez-vous que l’erreur ne se reproduit ni sur le téléphone ni dans le navigateur d’un ordinateur.

Vérifiez aussi les réglages de confidentialité et de mesure d’audience, parce que les scripts facultatifs de mesure d’audience, de publicité ou d’autre suivi, dont le fonctionnement exige un consentement, ne doivent pas démarrer avant le choix correspondant, et le contrôle se fait aussi après un refus et après le retrait du consentement. Les opérations techniques nécessaires à la commande, de leur côté, ne doivent pas cesser de fonctionner si l’acheteur refuse la mesure d’audience.

Au moment de la mise en ligne, nommez les responsables et préparez un plan d’action en cas d’échec, en déterminant qui contrôle les paiements, la livraison et le contenu, à qui signaler une erreur critique et comment agir si l’on ne peut plus accepter les paiements ou si les prix sont faux. Parfois la décision la plus sûre est de suspendre un temps les commandes, plutôt que de collecter des commandes que l’on ne peut pas exécuter. Dans le contrôle de mise en ligne, comparez la configuration de l’environnement de test et de l’environnement public, les clés de paiement, les comptes de livraison, les réglages fiscaux et l’expéditeur des e-mails, parce qu’un test réussi dans un autre environnement ne prouve pas encore que les mêmes conditions valent dans la boutique accessible à l’acheteur.

L’administration et la maintenance commencent avant la mise en ligne

L’administrateur de la boutique n’est pas un rôle abstrait que l’on attribue après la remise du projet, donc avant la mise en ligne déterminez qui a le droit de changer les prix, de publier des produits, d’effectuer un remboursement et de voir les données clients, parce que chaque personne n’a pas besoin de tous les droits. Un rédacteur de contenu n’a en général pas à changer les réglages de paiement, et un collaborateur d’entrepôt n’a pas à voir plus d’informations sur le client que ce qu’il faut pour préparer l’envoi.

Accordez-vous sur la façon d’installer les mises à jour du système, des extensions et des intégrations, qui ne doivent pas arriver pour la première fois dans la boutique publique un vendredi après-midi seulement parce qu’un avis est apparu dans le panneau d’administration. Il faut une sauvegarde, un environnement de test et une personne qui, après la modification, exécute un court test d’achat, parce qu’une mise à jour peut toucher non seulement l’apparence, mais aussi les intégrations de paiement, de livraison et d’e-mail.

Déterminez qui s’aperçoit que les notifications de paiement n’arrivent plus dans la boutique, que l’interface d’expédition répond par une erreur ou que le nombre de commandes échouées augmente brusquement. Un appel de l’acheteur ne doit pas être le premier signal d’une erreur. Au moins pour les intégrations critiques, il faut un journal d’erreurs et une notification au responsable, et pour l’équipe une procédure de traitement des incidents indiquant où l’on conserve la décision sur la solution temporaire et selon quel critère on vérifie le rétablissement du service.

Dans les premières semaines, les mesures doivent répondre à des questions de processus, non seulement compter les visites, donc comparez les achats commencés et ceux qui sont achevés, les erreurs de paiement, les choix de livraison et les motifs du support client. Si beaucoup de personnes s’arrêtent à une étape, vérifiez d’abord un obstacle technique ou de contenu, avant de conclure que le marché n’a pas de demande.

Que préparer avant de parler à un développeur

Pour que le premier entretien soit productif, préparez un produit-échantillon, un scénario de commande complet et une situation d’exception, et ajoutez le nombre approximatif de produits et de variantes, les langues, les pays, les moyens de paiement et de livraison. S’il existe déjà un site, indiquez ce que vous voulez migrer et avec quels systèmes la boutique doit échanger des données ; vous n’avez pas à connaître la solution technique, mais vous devez pouvoir montrer le travail de l’entreprise.

Nommez à part les exigences qui doivent figurer dès la première mise en ligne et les idées que l’on peut reporter : le processus de base de paiement et de livraison est en général une exigence de mise en ligne, tandis qu’un programme de fidélité complexe peut être l’étape suivante, si sans lui on peut accepter et exécuter une commande correctement. Cette distinction protège le budget mieux qu’une suppression arbitraire de fonctions, parce que chaque travail reporté garde un motif nommé, une dépendance et le moment où il faudra revenir à la décision d’après des données de commandes réelles.

Un produit-échantillon, un scénario de commande et une situation d’exception suffisent, dans le cadrage d’un projet de boutique en ligne, à fixer un périmètre de travail clair et vérifiable, ainsi qu’un délai et un prix. Dans le devis, demandez non seulement les noms des fonctions, mais aussi les limites : qui prépare les données, qui configure le service externe et après quel test le travail est accepté.

Si vous avez déjà un catalogue ou une esquisse de processus, l’étape suivante est de l’examiner avec quelqu’un qui peut évaluer les dépendances techniques ; s’il n’y a pas encore d’esquisse, nous pouvons commencer par l’établir et dire ce qu’il ne faut pas construire dans la première version. Demander le cadrage d’un projet de boutique en ligne a de la valeur avant le choix de la plateforme, parce qu’alors le prix est fixé par un périmètre de travail clairement défini, non par des hypothèses sur ce que devrait contenir le mot « boutique ». Les deux parties doivent, déjà avant le développement, comprendre de la même façon quel résultat vérifiable attestera que le projet est achevé.