Proposition — Plateforme e-commerce B2B/B2C sur mesure pour Bullet Distribution

ArtifiQ · brouillon v1 · 18 août 2026 · pour relecture interne (Anthony) Les montants sont à compléter par Anthony (les efforts en semaines-dev sont fournis) ; les mentions « à confirmer » sont des questions ouvertes à poser à Bullet avant la version finale. Le prototype cliquable (pages/02-dashboard-direction-v2.html pour l'admin, pages/boutique.html pour la boutique) est l'annexe A de cette proposition.

0. Ce que nous avons compris

Bullet Distribution distribue plus de 600 produits de vapotage à plus de 250 détaillants, aujourd'hui sur Shopify. Le RFP ne demande pas « un nouveau site » : il demande le système central des opérations commerciales — comptes B2B, catalogues et prix par client, commandes, facturation liée à QuickBooks, analytique — dans une catégorie réglementée, sans dépendance à un fournisseur.

Deux faits récents pèsent sur le projet :

1. Shopify se retire du vapotage. Annoncé les 23–24 juin 2026 sous la pression de 25 procureurs généraux américains, avec retrait des produits exigé au 7 juillet 2026 aux États-Unis ; le périmètre canadien n'est pas officiellement précisé et des marchands canadiens rapportent une application « à toutes les juridictions ». Nous ne présumons pas de la situation exacte de Bullet, mais nous proposons ci-dessous une phase 0 « départ rapide de Shopify » et des priorités ajustables selon les annonces.
2. Les processeurs de paiement grand public excluent la catégorie (Stripe, Shopify Payments, Square). Notre compréhension actuelle — à confirmer — est que Bullet n'a pas besoin de processeur dans l'application au lancement : la commande est portée au compte du client, la facture est créée dans QuickBooks et réglée par carte (+3 %), dépôt bancaire, chèque ou comptant. L'architecture prévoit néanmoins l'intégration d'un processeur haut risque le jour où Bullet le voudra (B2C notamment).

Notre proposition, en une phrase : une plateforme propriétaire (code, données, infrastructure au nom de Bullet), un seul modèle de données pour le B2B et le B2C, un admin conçu pour l'équipe de Bullet, et un plan en phases dont chaque étape livre quelque chose d'utilisable.

1. Architecture recommandée

Principes : un seul Postgres, pas de microservices ; toute règle métier (prix, taxes, visibilité) vit dans un module testé ; tout ce qui est lourd ou externe passe par une file avec reprise ; tout est journalisé (qui, quand, quoi).

2. Technologies proposées

Next.js · TypeScript · Tailwind CSS · shadcn/ui · NestJS · Drizzle · PostgreSQL · Redis/BullMQ · Payload CMS · DigitalOcean (App Platform/droplets, Managed Postgres, Spaces, CDN) · Sentry · GitHub Actions. API interne typée (REST + client TypeScript généré) plutôt que GraphQL : un seul client, moins de complexité ; GraphQL n'est utilisé que là où un tiers l'impose (export Shopify).

3. Fonctionnalités incluses (et où les voir dans le prototype)

4. Intégrations proposées

• QuickBooks Online (obligatoire) — voir §6.
• Transporteurs — Purolator et Postes Canada en direct, ou agrégateur (ShipStation/EasyPost) selon volumes ; livraison Bullet (camion) et ramassage en magasin natifs.
• Courriel — transactionnels envoyés par la plateforme (fournisseur SMTP transactionnel type Postmark/Resend) ; campagnes via Klaviyo ou Mailchimp avec listes/segments synchronisés (B2B actifs, inactifs 60 j, B2C).
• Paiements — enregistrement manuel (carte au terminal +3 %, dépôt bancaire, chèque, comptant) et lien de paiement de facture ; processeur carte en ligne haut risque en option (voir §15).
• Shopify — lecture seule, pour la migration (§5).
• Analytics web — GA4/Meta après consentement (Loi 25).

5. Stratégie de migration Shopify

1. Audit (semaines 1–2) : inventaire via l'API Admin (produits, variantes, metafields, collections, clients, comptes B2B, commandes, pages, redirections, apps installées) → rapport : quoi migrer, quoi remplacer, quoi abandonner.
2. Extraction complète vers des tables de staging shopify_* (bulk operations), rejouable.
3. Transformation vers le modèle cible avec mapping documenté champ par champ ; metafields → champs personnalisés ; comptes B2B et prix par client → groupes/catalogues/prix ; commandes historiques → lecture seule (pour l'analytique dès le jour 1).
4. Réconciliation automatisée : comptages par entité, totaux de commandes, sommes de soldes, échantillons manuels signés par Bullet.
5. Médias vers Spaces (WebP), SEO : carte d'URL, 301 automatiques, handles conservés, sitemap.
6. Migrations à blanc répétées (au moins deux) sur staging ; cutover avec gel des écritures Shopify, delta final, bascule DNS, hypercare. Livrables : rapport d'audit, mapping, rapport de réconciliation, plan de cutover.

6. Stratégie QuickBooks Online

Sources de vérité et sens de synchronisation (activables objet par objet) :

Mécanique : OAuth2, webhooks + rattrapage périodique, file idempotente (clé externe des deux côtés — rejouer ne crée jamais de doublon), écran d'erreurs avec ré-essai et résolution (doublons de clients, code de taxe inactif…), journal, mode « comparer plateforme ↔ QBO » avant la première synchronisation, import initial de l'historique financier avec rapprochement des soldes. Règles de conflit écrites (facture modifiée dans QBO = refusée et signalée ; paiement supprimé = solde recalculé et représentant averti ; panne QBO = file locale, aucune perte). À confirmer avec Bullet : une seule société QBO ; QBO Canada avec TPS/TVQ ; plafonds d'API.

7. Stratégie B2B

Le B2B est le cœur, pas un plugin : entreprise (avec ses utilisateurs, rôles, adresses, documents, conditions, crédit) → groupe de clients (catalogue par défaut, ajustement de prix, conditions par défaut) → surcharges par entreprise (catalogue, exceptions produits, prix spécifiques, conditions). Représentants avec portefeuille, objectifs, règles d'assignation, prix client proposé avec approbation au-delà d'un seuil. Approbation interne côté client (acheteur → propriétaire) au-dessus d'un montant. Commande rapide (fréquents, dernière commande, paliers) et « Mon entreprise » complet. Le B2C partage le même modèle (une entreprise « particulier ») — voir §15 pour son périmètre.

8. Gestion des catalogues et des prix

• Catalogue = requête sauvegardée (règles) + exceptions, pas une liste à maintenir ; il décide quoi voir. Assignation par groupe et par client, simulateur « vu par », publication versionnée.
• Prix — un seul ordre de résolution, déterministe et affiché : prix spécifique client (variante) → prix client par marque/collection → ajustement du groupe → ajustement du catalogue → palier de volume (quantité totale du produit) → prix de base, puis une promotion (la plus avantageuse) si elle est empilable ou si aucune règle plus spécifique n'a joué. Pas d'empilement implicite. Prix plancher = avertissement. Prix et origine figés sur la ligne de commande.
• Modifications massives : sélection multi-produits/marque/collection/groupe, rabais % ou fixe, nouveau prix, paliers, promos temporaires ; brouillon → aperçu diff (avant/après, volume et marge estimés, plancher, conflits) → publication immédiate ou planifiée → historique immuable et restauration ; import/export CSV avec validation ligne par ligne.
• Détail : PRIX-PLAN-DE-MATCH.md (validé avec Anthony le 17 août).

9. Dashboards analytiques

• Client 360 : CA, 30/60/90 j, YTD, croissance, vs N-1, commandes, panier moyen, fréquence, dernière commande, produits/quantités, marques/catégories, marge brute et %, rabais accordés, historique, produits abandonnés, cross-sell, représentant, notes, factures, paiements, solde ; clients similaires (même groupe/région/taille) ; Health Score transparent (récence, fréquence, montant, tendance, paiement) → segments croissance / stable / en baisse / inactif / potentiel.
• Direction : ventes, marge, croissance, meilleurs clients/produits, performance des représentants, clients en baisse/inactifs, tendances ; filtres période, client, représentant, province, marque, catégorie, produit ; vues enregistrées ; export.
• Prérequis : coûts d'achat par variante (migrés depuis QuickBooks/listes fournisseurs ou saisis) — sans eux, la marge est fausse ; le champ existe dans la fiche produit du prototype (coût d'achat, coût moyen pondéré, plancher) et dans la table des prix.

10. Délais estimés et phasage

Le phasage est construit pour que Bullet puisse basculer tôt si Shopify l'impose : la phase 1 est autonome, les suivantes s'ajoutent sans reconstruire.

Avec deux développeurs à plein temps et les phases 2–4 menées en parallèle : MVP opérable à 2 mois, construction ≈ 12–15 semaines, projet « terminé » (bascule + hypercare) en 4 à 6 mois. Les détails fins et l'amélioration continue s'étalent ensuite sur ~1 an. La vitesse dépend en bonne partie de Bullet : voir « calendrier de décision » (§17). Le chemin critique n'est pas le code : ce sont les décisions, les données Shopify et l'accès QuickBooks.

Dépendances explicites : phase 2 tient en 4–5 semaines si la comptable de Bullet est disponible et si l'audit QuickBooks (doublons, taxes) est propre ; les demandes de processeur carte, si voulues, se lancent dès la signature.

Note d'effort livraison/fulfillment (§10 du RFP) : règles/tarifs par zone S, restrictions au panier S (données de §11), statuts et expéditions partielles M, étiquettes/suivi transporteur M (agrégateur = plus court), RMA → crédit QBO M, inventaire réservé/disponible/seuils M ; ≈ 4–5 semaines-dev réparties entre les phases 1 et 2.

Critères d'acceptation par phase (proposés — à affiner avec Bullet)

Phase 1 : un détaillant se connecte, voit son catalogue et ses prix (client, groupe, catalogue, paliers, promo) ; passe une commande rapide et la retrouve dans l'admin ; l'admin approuve, prépare, expédie (ou ramassage) et la commande passe « livrée » ; les 600+ produits et 250+ comptes migrés sont réconciliés (rapport signé) ; un lot de prix est publié avec aperçu et restauré ; un client entreprise gère ses utilisateurs et adresses ; le journal enregistre chaque action. Phase 2 : une facture émise apparaît dans QuickBooks en < 5 minutes avec les bons codes de taxe ; un paiement saisi dans QuickBooks met à jour le solde et le statut du compte ; une erreur de synchronisation est visible, explicable et rejouable ; les taxes/accise d'un panier correspondent à la matrice validée pour 5 provinces test ; une expédition génère étiquette et suivi ; un RMA produit une note de crédit dans QuickBooks. Phase 3 : les 21 indicateurs du client 360 sont calculés et vérifiés sur 3 clients contre les données source ; les 7 filtres du tableau de bord direction fonctionnent ; le health score est expliqué par ses composantes. Phase 4 : l'équipe crée une page, l'ajoute à un menu, la publie et la voit en boutique sans intervention d'ArtifiQ ; une bannière ciblée B2B n'apparaît pas à un visiteur ; un changement d'URL crée sa redirection.

11. Ressources nécessaires

• ArtifiQ : deux développeurs seniors à plein temps — l'un sur les fondations, la boutique, les prix et l'admin ; l'autre sur QuickBooks, la migration, les transporteurs puis l'analytique — assistés par nos outils d'IA de développement ; design/UX déjà largement fait (prototype) — retouches au fil de l'eau ; direction de projet = Anthony (ArtifiQ).
• Bullet : un répondant produit disponible ~½ jour/semaine (règles de prix, catalogues, taxes), la comptable pour QuickBooks (mapping, réconciliation), un testeur détaillant « ami » pour la boutique, et des décisions rapides en fin de phase (voir §17).
• Formation : capsules vidéo par rôle (direction, représentants, comptabilité, entrepôt, marketing) réalisées avec Scribe, consultables à volonté, complétées par des sessions en personne aux étapes clés ; guide administrateur et documentation d'exploitation livrés avec le code. (À valider avec l'associé d'ArtifiQ.)

12. Coût de développement

Prix forfaitaire du projet : 90 000 $ (avant taxes) pour l'ensemble des phases 1 à 4, la migration, la formation, la documentation, la bascule et l'hypercare, tel que décrit dans cette proposition. Répartition indicative par phase (proportionnelle à l'effort) :

Modalités de paiement, au choix de Bullet : (a) par phase — 20 % à la signature, puis le solde de chaque phase à son acceptation ; ou (b) mensualisé — 15 000 $/mois sur 6 mois, ou 18 000 $/mois sur 5 (ajusté si le calendrier s'étire du fait de Bullet, voir §17). La phase 0 « départ rapide de Shopify », si Bullet l'active, est un réordonnancement de la phase 1 : sans coût additionnel, sauf demandes hors périmètre.

Efforts sous-jacents (pour transparence) : ≈ 40–50 semaines-dev réparties comme suit — fondations 3–4 · produits/catalogues/comptes 4–5 · moteur de prix 3–4 · commandes/fulfillment/inventaire/livraison 4–5 · boutique/Mon entreprise 4–5 · QuickBooks 4–6 · taxes/accise 2 · contenu (Payload) 1–2 · analytique 3 · migration 3 + cutover · tests/formation/doc/hypercare 3–4. Le test d'intrusion est réalisé pendant le développement et inclus.

13. Coûts récurrents (estimation, à valider)

DigitalOcean (app + Postgres managé + Redis + Spaces/CDN + staging) ≈ 150–300 $/mois ; courriel transactionnel ≈ 20–50 $/mois ; Sentry/monitoring ≈ 30–60 $/mois ; sauvegardes hors site incluses ; Payload : gratuit (open source) ; Klaviyo/Mailchimp : selon nombre de contacts (à la charge de Bullet) ; frais de carte : ceux de l'acquéreur choisi (refacturés 3 % aujourd'hui) ; QuickBooks : abonnement existant. Aucune licence ArtifiQ récurrente sur le logiciel livré.

14. Support continu et amélioration

Ce qui est inclus sans frais : tout ce qui a été livré doit fonctionner comme convenu — la correction des bugs et des pannes causées par notre travail est incluse tant que le contrat de support est en vigueur, sans décompte d'heures. Ce qui passe par la banque d'heures : tout changement ou ajout qui ne faisait pas partie de l'entente initiale (nouvelle fonctionnalité, modification d'une règle, intégration supplémentaire).

Tarifs (à confirmer par Anthony) : banque d'heures prépayée (10 à 20 heures ou plus, au choix de Bullet) : 110–120 $/h ; intervention ponctuelle sans banque : 150 $/h ; travail sur mesure important : évalué et devisé.

Délais de réponse ArtifiQ : urgence (panne, plateforme inutilisable) 24–48 h ; amélioration continue 1–2 semaines ; sur mesure : évalué au cas par cas. Demandes et notifications par courriel (adresse dédiée), suivi dans un registre partagé.

Inclus dans le forfait : monitoring et alertes, sauvegardes vérifiées (test de restauration trimestriel), mises à jour de sécurité et de dépendances, correction de bugs, revue trimestrielle des priorités ; infrastructure refacturée au réel ; hors scope au tarif ci-dessus.

15. Risques et limitations identifiés

16. Recommandations pour l'évolution future

Multi-entrepôts et transferts ; application mobile pour les représentants (commande sur place, prise de photos, notes) ; EDI/portails pour les chaînes ; prévisions de réassort et suggestions par IA (déjà amorcées avec « à réapprovisionner » et cross-sell) ; B2C hors Québec avec processeur dédié ; place de marché fournisseurs (Bullet comme plateforme pour ses marques) ; API partenaire pour les grands comptes ; rapports d'accise automatisés.

17. Modalités, sécurité et hypothèses

Paiement du projet : par phase (à l'acceptation de chaque phase livrée) ou mensualisé sur la durée du projet, au choix de Bullet.

Propriété : Bullet reçoit une licence perpétuelle, non exclusive et transférable avec l'entreprise d'utiliser et de modifier la plateforme (code source livré dans son dépôt, données et infrastructure à son nom, aucune dépendance à ArtifiQ pour opérer) ; la licence ne permet pas de revendre la plateforme comme produit. ArtifiQ conserve la propriété intellectuelle de son code et peut le réutiliser pour d'autres clients — jamais les données ni la configuration de Bullet.

Gestion des changements : toute demande hors périmètre est chiffrée (banque d'heures ou devis) et acceptée par courriel avant réalisation.

Calendrier de décision : la vitesse du projet dépend de la disponibilité de Bullet. Engagement réciproque : ArtifiQ livre et documente chaque étape ; Bullet valide ou répond dans les 5 jours ouvrables à chaque étape livrée (décisions, données, accès QuickBooks, comptable) ; au-delà, le calendrier glisse d'autant, sans pénalité pour l'une ou l'autre partie.

Environnement de staging : permanent, avec données migrées, accessible à l'équipe de Bullet ; démonstration à chaque fin de sprint ; rien n'est déployé en production sans validation en staging.

Sécurité : authentification à deux facteurs pour l'admin, rôles et permissions, journal d'audit complet, chiffrement en transit et au repos, sauvegardes quotidiennes + récupération à un instant donné avec test de restauration trimestriel, mises à jour de sécurité, séparation staging/production, secrets hors du code ; conformité Loi 25 (Québec) pour les données personnelles ; test d'intrusion réalisé pendant le développement (inclus).

Hypothèses et exclusions : le B2C n'est pas dans le périmètre de lancement. C'est faisable sur la même plateforme (même modèle de données, boutique et checkout déjà prévus pour un visiteur), mais il ajoute quelques semaines de travail dédié — barrière d'âge, restrictions par province, processeur de carte en ligne, et vente en ligne interdite au Québec donc hors Québec seulement — que nous chiffrerons précisément au moment voulu, selon l'état de la plateforme ; nous demandons à Bullet son intention et son horizon ; aucun processeur de carte en ligne au lancement (à confirmer : processeur actuel, part des paiements par carte) ; la migration reprend le contenu Shopify existant ; les nouveaux textes, photos et traductions EN sont produits par l'équipe de Bullet dans le CMS ; les ententes et tarifs négociés avec les transporteurs sont ceux de Bullet (à documenter) ; « Actualités » est optionnel (pas de blog sur le site actuel) ; QuickBooks Online Canada, une seule société.

18. Plan de bascule Shopify (encadré)

1. J-15 : migration à blanc n° 2 validée, formation faite, staging = miroir de production.
2. J-2 : gel des modifications de contenu/prix côté Shopify (les commandes continuent).
3. J-1 : extraction du delta (nouvelles commandes, clients, stocks) → réconciliation.
4. Jour J (matin, hors pointe) : dernier delta, vérifications de recette (commande test, facture test → QuickBooks), bascule DNS, redirections 301 actives, boutique Shopify en mode « fermé » avec message.
5. J+1 à J+30 : hypercare — surveillance renforcée, correctifs prioritaires, point quotidien puis hebdomadaire ; retour arrière possible pendant 14 jours (Shopify conservé en veille, plan documenté).
6. J+30 à J+45 : clôture de la phase, exports de contrôle, fin de l'abonnement Shopify à la main de Bullet.

Annexes

• A. Prototype cliquable (admin : pages/02-dashboard-direction-v2.html ; boutique : pages/boutique.html).
• B. ANALYSE-RFP.md — analyse section par section et couverture.
• C. PRIX-PLAN-DE-MATCH.md — modèle de prix validé.
• D. PAIEMENTS-VAPE.md — contexte paiements et Shopify.
• E. DESIGN-BRIEF.md — système visuel.

Questions ouvertes à Bullet avant la version finale : avis Shopify reçu et échéance ; processeur de carte actuel (fournisseur, taux, existe-t-il en dehors de Shopify ? — s'il a une API ou une page de paiement hébergée, nous le réutilisons) ; part des paiements par carte ; ententes de livraison (transporteurs, tarifs, volumes) ; une seule société QuickBooks, QBO Canada, accès sandbox ; coûts d'achat par produit disponibles ? (source : QuickBooks, listes fournisseurs) — nécessaires pour les marges ; outil d'inventaire/entrepôt actuel ; B2C : intention et horizon ; quelles apps/fonctions marketing utilisez-vous sur Shopify aujourd'hui (courriels, avis, pop-ups, codes promo…) — le RFP demande de les reconstruire ou remplacer.