# Rapport client — Boutique en ligne d'une microbrasserie (exemple fictif)

> **Résultat assisté par IA — proposition, revue critique et contrôles automatiques ; non validé par un professionnel ; ne constitue ni une estimation validée ni une offre de prix**

- **Espace** : Espace libre-service local (fictif)
- **Projet** : Boutique en ligne d'une microbrasserie (exemple fictif)
- **Destinataire** : Espace libre-service local (fictif)
- **Version** : V2 — 27 septembre 2026
- **Conservé par** : Client local (fictif)
- **Statut** : Résultat assisté par IA
- **Révision** : V1 → Maquettes d'interface M-1 jointes au dossier.

## Besoin et objectifs

Lancer un canal de vente en ligne de caisses de bière, complémentaire au comptoir physique, avec un stock fiable entre les deux canaux (dans les deux sens), un paiement en ligne avec possibilité de remboursement, une vérification d'âge conforme à la loi et un suivi de commande jusqu'à la livraison ou la cueillette.

Dossier fictif d'exemple public : une microbrasserie sans présence en ligne veut ajouter la vente par internet à son comptoir existant. Aucune donnée réelle. Le volume de commandes et le budget ne sont pas arrêtés ; le client attend l'estimation pour décider. La vente d'alcool impose une vérification d'âge, la comptabilité reste dans le système existant, et la résidence des données au Québec doit être vérifiée sur toute la chaîne de traitement, y compris chez les fournisseurs tiers.

## Recommandation

Boutique en ligne sur mesure, intégrée à la caisse existante et à un service de paiement externe — Construction d'une boutique en ligne sur mesure (comptes, catalogue, panier, commandes avec annulation et remboursement, suivi) couvrant le cœur métier propre à la brasserie. Le traitement des cartes de paiement est confié à un service de paiement externe pour éviter de stocker des numéros de carte et pour permettre le remboursement d'une commande annulée. La synchronisation du stock avec la caisse du comptoir est développée sur mesure et doit couvrir les deux sens (comptoir → boutique et boutique → comptoir), le système faisant foi restant à désigner avec vous. La vérification d'âge combine une déclaration en ligne et un contrôle à la remise, mécanisme à valider avec votre propre conseil juridique, surtout en cas de livraison par transporteur externe.

Le volume déclaré (100 à 1000 commandes/mois) ne justifie ni une plateforme lourde ni une décomposition en microservices : un bloc applicatif modulaire (catalogue, panier, commandes, comptes) suffit et reste simple à exploiter pour une petite équipe. Le paiement par carte est acheté auprès d'un service externe pour réduire la portée de conformité sur les données de carte, une donnée sensible déclarée, et pour permettre le remboursement d'une commande annulée. L'intégration avec la caisse du comptoir est un développement sur mesure car aucun connecteur existant n'est confirmé, et doit couvrir les deux sens pour éviter la survente dans les deux directions. La résidence des données au Québec borne l'hébergement et devra être vérifiée pour chaque fournisseur tiers, pas seulement pour l'application.

Conditions :
- Le volume mensuel reste de l'ordre de 100 à 1000 commandes
- La caisse du comptoir expose un moyen d'échange bidirectionnel (interface ou export) pour le stock
- Un service de paiement par carte externe est disponible, intégrable et permet le remboursement
- L'ensemble de la chaîne de traitement (hébergement, sauvegardes, journaux, paiement, courriel) respecte la résidence des données au Québec, à confirmer comme obligation ferme

## Périmètre inclus

| Code | Nature | Élément | État |
|---|---|---|---|
| E-1 | Objectif | Ouvrir un canal de vente en ligne complémentaire au comptoir | à confirmer |
| E-2 | Objectif | Éviter la survente entre le comptoir et la boutique en ligne | à confirmer |
| E-3 | Exigence | Parcours catalogue et panier | à confirmer |
| E-4 | Exigence | Paiement par carte au moment de la commande | à confirmer |
| E-5 | Exigence | Choix cueillette ou livraison à la commande | à confirmer |
| E-6 | Exigence | Synchronisation bidirectionnelle du stock avec la caisse du comptoir | à confirmer |
| E-7 | Exigence | Courriels de confirmation et d'expédition | à confirmer |
| E-8 | Exigence | Suivi de l'état de la commande en ligne | à confirmer |
| E-9 | Exigence | Vérification de l'âge avant paiement et à la remise | à confirmer |
| E-10 | Exigence | Parcours d'annulation et de remboursement d'une commande | à confirmer |
| E-11 | Exigence | Comptes et accès personnels | à confirmer |
| E-12 | Exigence | Intégrations avec la caisse du comptoir et un service de paiement | à confirmer |
| E-13 | Contrainte | Résidence des données au Québec, sur toute la chaîne | à confirmer |
| E-14 | Contrainte | Livraison limitée à la province | à confirmer |
| E-15 | Contrainte | Traitement de numéros de carte de paiement | à confirmer |
| E-16 | Contrainte | Durées de conservation des données personnelles à fixer | à confirmer |
| E-21 | Hypothèse | Volume mensuel de commandes non mesuré, hypothèse 100 à 1000 | à confirmer |
| E-22 | Hypothèse | Livraison et suivi gérés manuellement, sans transporteur intégré | à confirmer |
| E-23 | Hypothèse | Budget non arrêté | à confirmer |

E-17 figure à la section « Exclusions ».
E-18 figure à la section « Exclusions ».
E-19 figure à la section « Exclusions ».
E-20 figure à la section « Exclusions ».

## Exclusions

- E-17 : Traduction hors périmètre
- E-18 : Conseil juridique ou réglementaire hors périmètre
- E-19 : Comptabilité et remises aux distributeurs hors mandat
- E-20 : Production des textes et photos du catalogue à confirmer

- Ne couvre pas la comptabilité ni les remises aux distributeurs, laissées au système existant
- Ne couvre pas une vérification d'identité par un service tiers tant que le mécanisme de vérification d'âge n'est pas confirmé
- Ne couvre pas un suivi automatisé par transporteur tant que le mode de livraison n'est pas confirmé
- Dépend d'un moyen d'échange exploitable côté caisse du comptoir, non confirmé à ce stade, dans les deux sens
- La résidence des données n'est assurée pour l'instant que pour l'application ; les fournisseurs tiers (paiement, courriel, surveillance) restent à vérifier

## Principales hypothèses

- Trois ateliers avec le client suffisent à lever les principales inconnues, dont l'annulation et la conservation des données.
- Le périmètre fonctionnel reste celui décrit, sans ajout majeur.
- Une seule base relationnelle couvre l'ensemble des domaines, complétée d'un stockage objet pour les images.
- Le découpage en modules retenu ne change pas en cours de projet.
- Utilisation d'un cadriciel web courant avec composants d'interface réutilisables.
- La brasserie fournit les textes et photos ; seule l'intégration technique du stockage est chiffrée ici.
- Pas de personnalisation avancée du catalogue (variantes, promotions complexes).
- Authentification par courriel/mot de passe uniquement, sans connexion sociale.
- Aucune exigence de double authentification n'est confirmée à ce stade.
- Une seule adresse de livraison par commande.
- Le remboursement lui-même est délégué au fournisseur de paiement via P-10 ; ce poste porte la logique de statut et de déclenchement.
- Les statuts de commande restent un jeu limité incluant annulée/remboursée.
- L'hypothèse retenue est une auto-déclaration en ligne et un contrôle visuel par le personnel de la brasserie à la remise, sans service tiers ni transporteur externe.
- Aucune intégration transporteur ; mise à jour manuelle des statuts par le personnel.
- Le nombre de statuts reste limité (créée, préparée, expédiée/remise, annulée/remboursée).
- Les mouvements de stock du comptoir arrivent au moins toutes les quelques minutes.
- Un seul point de vente physique alimente le stock partagé.
- Le système faisant foi pour le stock reste à désigner avec vous.
- Un service d'envoi de courriel externe standard est utilisé via son SDK.
- Trois modèles de courriel (confirmation, expédition, annulation/remboursement).
- Le service de paiement retenu propose un SDK ou une intégration hébergée standard, incluant une fonction de remboursement.
- Aucun mode de paiement additionnel (portefeuille, virement) n'est requis.
- Hypothèse par défaut : le système de caisse offre une interface ou un export exploitable dans au moins un sens.
- La capacité de recevoir un flux retour (boutique vers caisse) reste à confirmer.
- Le nombre de références de caisses est limité (catalogue simple d'une microbrasserie).
- Les données de départ sont fournies par le client dans un format exploitable (tableur).
- Revue interne, sans audit de sécurité externe indépendant.
- Le mode d'intégration du paiement délègue la donnée de carte au fournisseur externe.
- Le niveau ASVS visé est retenu comme hypothèse de base, à confirmer.
- Les tests s'exécutent au fil de la réalisation, en parallèle des postes de développement.
- Les zones à risque (paiement, stock, âge) font l'objet de tests automatisés ; le reste demeure testé manuellement.
- Un hébergeur avec une région canadienne ou québécoise est disponible pour l'application, la base et le stockage objet.
- Trois environnements (dev, préproduction, production) suffisent.
- Aucune exigence de haute disponibilité multi-zone n'est demandée au volume déclaré.
- Documentation rédigée en français uniquement, sans traduction (hors périmètre).
- Une seule séance de formation regroupée suffit pour le personnel concerné.
- Ratio de coordination appliqué à l'ensemble des autres postes, dans la fourchette usuelle de 10 à 18 %, sur un total révisé d'environ 596 h.
- Période de stabilisation d'environ deux à trois semaines après le lancement.
- Aucun incident majeur nécessitant une intervention hors de ce cadre.

## Architecture proposée

Construction d'une boutique en ligne sur mesure (comptes, catalogue, panier, commandes avec annulation et remboursement, suivi) couvrant le cœur métier propre à la brasserie. Le traitement des cartes de paiement est confié à un service de paiement externe pour éviter de stocker des numéros de carte et pour permettre le remboursement d'une commande annulée. La synchronisation du stock avec la caisse du comptoir est développée sur mesure et doit couvrir les deux sens (comptoir → boutique et boutique → comptoir), le système faisant foi restant à désigner avec vous. La vérification d'âge combine une déclaration en ligne et un contrôle à la remise, mécanisme à valider avec votre propre conseil juridique, surtout en cas de livraison par transporteur externe.

**Acteurs**

- Client grand public (utilisateur) — Personne qui achète des caisses de bière en ligne, crée un compte, choisit cueillette ou livraison, suit sa commande et peut être remboursée en cas d'annulation.
- Personnel de la brasserie (personnel) — Employé qui prépare les commandes, met à jour leur statut, vérifie l'âge à la remise, confirme l'expédition ou la cueillette, et déclenche une annulation/remboursement au besoin.
- Système de caisse du comptoir (système externe) — Système existant du comptoir physique ; source et destinataire des mouvements de stock partagés avec la boutique en ligne, dans les deux sens.

**Composants**

- Portail boutique en ligne (Interface) — Catalogue, panier, tunnel de commande, compte client, suivi de commande. Point d'entrée unique du client grand public.
- Interface interne de gestion des commandes (Interface) — Utilisée par le personnel pour préparer les commandes, mettre à jour leur statut (préparation, prête, expédiée/remise, annulée/remboursée) et confirmer visuellement l'âge à la remise.
- Service catalogue et disponibilité (Service) — Expose la liste des caisses et leur disponibilité réelle, calculée à partir du stock partagé synchronisé avec la caisse du comptoir.
- Service comptes clients (Service) — Création de compte, authentification, gestion du profil (coordonnées, adresse) du client grand public.
- Service commandes (Service) — Cycle de vie de la commande : panier, choix cueillette/livraison (province), déclenchement du paiement, statut jusqu'à remise, et annulation/remboursement d'une commande déjà payée (refus d'âge, survente).
- Service de vérification d'âge (Service) — Enregistre la déclaration d'âge du client avant paiement et le résultat de la vérification à la remise. Mécanisme précis, notamment pour une remise par transporteur externe, à confirmer avec vous.
- Service de synchronisation du stock (Service) — Réconcilie le stock affiché en ligne avec les ventes au comptoir dans les deux sens : une vente au comptoir retire une caisse de la boutique, et une vente en ligne doit être répercutée vers la caisse. Le système qui fait foi reste à désigner avec vous selon les capacités réelles de la caisse.
- Service de notifications (Service) — Envoie les courriels de confirmation, d'expédition et d'annulation/remboursement, déclenchés par les changements de statut de commande.
- Base de données transactionnelle (Données) — Stockage structuré des comptes, catalogues, commandes (incluant annulations et remboursements), stock et statuts. Aucune donnée de carte de paiement n'y est conservée. Durées de conservation à fixer avec vous.
- Stockage des images et documents du catalogue (Données) — Conserve les photos et documents des fiches produit séparément de la base transactionnelle, avec accès par liens temporaires. Région et politique de sauvegarde à aligner avec la résidence des données au Québec.
- Connecteur de paiement (Intégration) — Interface entre le service commandes et le service de paiement externe : autorisation, capture et remboursement, sans manipuler ni stocker le numéro de carte en clair.
- Connecteur caisse du comptoir (Intégration) — Échange les mouvements de stock avec la caisse du comptoir dans les deux sens (vente comptoir vers boutique, vente boutique vers caisse). Moyen d'échange exact et capacité bidirectionnelle à confirmer.
- Service de paiement par carte (externe) (Externe) — Fournisseur tiers traitant l'autorisation, la capture, le remboursement et la sécurité des numéros de carte ; réduit la portée de conformité de la boutique sur ces données.
- Système de caisse du comptoir (existant) (Externe) — Système existant de vente au comptoir physique, source et destinataire des mouvements de stock à répercuter avec la boutique. Reste hors du mandat pour la comptabilité et les remises.
- Hébergement applicatif et base de données (Infrastructure) — Héberge la boutique, les services et les bases de données dans une région respectant l'exigence de résidence au Québec.
- Surveillance et journalisation centralisée (Infrastructure) — Centralise les journaux techniques et d'accès pour la supervision et la détection d'anomalies. Localisation à confirmer pour que la résidence des données au Québec couvre aussi les journaux.

**Flux**

- (1) Portail boutique en ligne → Service catalogue et disponibilité (appel) : Consultation du catalogue et de la disponibilité réelle des caisses.
- (2) Portail boutique en ligne → Service comptes clients (action d'une personne) : Création de compte et connexion du client.
- (3) Portail boutique en ligne → Service commandes (action d'une personne) : Ajout au panier, choix cueillette/livraison et création de la commande.
- (4) Service commandes → Service de vérification d'âge (appel) : Vérification du statut de déclaration d'âge avant d'autoriser le paiement.
- (5) Service commandes → Connecteur de paiement (appel) : Demande d'autorisation et de capture du paiement de la commande.
- (6) Connecteur de paiement → Service de paiement par carte (externe) (appel) : Transmission de la transaction au service de paiement externe.
- (7) Service de paiement par carte (externe) → Connecteur de paiement (événement) : Retour du résultat d'autorisation ou de refus.
- (8) Service commandes → Connecteur de paiement (appel) : Demande de remboursement d'une commande annulée (refus d'âge à la remise, survente).
- (9) Connecteur de paiement → Service de paiement par carte (externe) (appel) : Transmission de la demande de remboursement au service de paiement externe.
- (10) Service de paiement par carte (externe) → Connecteur de paiement (événement) : Confirmation du remboursement effectué.
- (11) Service commandes → Base de données transactionnelle (appel) : Persistance de la commande, de son statut (incluant annulation/remboursement) et du mode de remise.
- (12) Service comptes clients → Base de données transactionnelle (appel) : Lecture et écriture des données de compte client.
- (13) Service catalogue et disponibilité → Base de données transactionnelle (appel) : Lecture du catalogue et des niveaux de stock disponibles.
- (14) Service catalogue et disponibilité → Stockage des images et documents du catalogue (appel) : Lecture des images et documents associés aux fiches produit.
- (15) Système de caisse du comptoir (existant) → Connecteur caisse du comptoir (événement) : Vente au comptoir affectant le stock partagé, transmise ou exportée.
- (16) Connecteur caisse du comptoir → Service de synchronisation du stock (appel) : Réception des mouvements de stock du comptoir pour réconciliation.
- (17) Service de synchronisation du stock → Base de données transactionnelle (appel) : Mise à jour du stock partagé consultable par la boutique.
- (18) Service de synchronisation du stock → Connecteur caisse du comptoir (appel) : Répercussion vers la caisse d'une caisse vendue en ligne, pour retirer le stock côté comptoir (sens boutique vers caisse, moyen d'échange à confirmer).
- (19) Connecteur caisse du comptoir → Système de caisse du comptoir (existant) (appel) : Transmission au système de caisse d'une vente en ligne affectant le stock partagé, selon les capacités confirmées de la caisse.
- (20) Service commandes → Service de notifications (événement) : Déclenchement du courriel de confirmation, d'expédition ou d'annulation/remboursement, selon le statut.
- (21) Interface interne de gestion des commandes → Service commandes (action d'une personne) : Mise à jour du statut de préparation, de remise/expédition ou d'annulation de la commande.
- (22) Interface interne de gestion des commandes → Service de vérification d'âge (action d'une personne) : Confirmation de la vérification visuelle de l'âge au moment de la remise.
- (23) Portail boutique en ligne → Service commandes (appel) : Consultation du suivi de l'état de la commande par le client.

**Parcours utilisateurs**

- Acheter une caisse en ligne, avec vérification d'âge et paiement (Client grand public) — 1. Client grand public → Portail boutique en ligne : parcourt le catalogue et ajoute des caisses au panier ; 2. Client grand public → Service comptes clients : se connecte ou crée un compte ; 3. Client grand public → Service commandes : choisit la cueillette ou la livraison à domicile ; 4. Client grand public → Service de vérification d'âge : déclare son âge avant de payer ; 5. Service commandes → Connecteur de paiement : déclenche le paiement de la commande ; 6. Connecteur de paiement → Service de paiement par carte (externe) : transmet la transaction au service de paiement ; 7. Service de paiement par carte (externe) → Connecteur de paiement : renvoie le résultat de l'autorisation ; 8. Service commandes → Service de notifications : déclenche le courriel de confirmation ; 9. Service de notifications → Client grand public : envoie le courriel de confirmation de commande
- Garder le stock fidèle entre le comptoir et la boutique, dans les deux sens (Système de caisse du comptoir) — 1. Système de caisse du comptoir → Connecteur caisse du comptoir : transmet une vente réalisée au comptoir ; 2. Connecteur caisse du comptoir → Service de synchronisation du stock : transmet le mouvement de stock reçu du comptoir ; 3. Service de synchronisation du stock → Base de données transactionnelle : met à jour la quantité disponible en ligne ; 4. Client grand public → Service catalogue et disponibilité : consulte le catalogue avec la disponibilité à jour ; 5. Service commandes → Service de synchronisation du stock : signale une vente en ligne affectant le stock partagé ; 6. Service de synchronisation du stock → Connecteur caisse du comptoir : répercute la vente en ligne vers la caisse du comptoir ; 7. Connecteur caisse du comptoir → Système de caisse du comptoir : transmet la vente en ligne au système de caisse
- Préparer, vérifier l'âge et remettre une commande (Personnel de la brasserie) — 1. Personnel de la brasserie → Interface interne de gestion des commandes : consulte la liste des commandes à préparer ; 2. Personnel de la brasserie → Service commandes : met à jour le statut à « en préparation » ; 3. Service commandes → Service de notifications : déclenche le courriel d'expédition ; 4. Service de notifications → Client grand public : envoie le courriel d'expédition ; 5. Personnel de la brasserie → Service de vérification d'âge : confirme la vérification de l'âge à la remise ; 6. Personnel de la brasserie → Service commandes : marque la commande comme remise ou livrée ; 7. Client grand public → Portail boutique en ligne : consulte le suivi de sa commande mis à jour
- Annuler et rembourser une commande après un refus d'âge ou une survente (Personnel de la brasserie) — 1. Personnel de la brasserie → Service commandes : signale un refus au contrôle d'âge à la remise, ou une survente détectée ; 2. Service commandes → Connecteur de paiement : demande le remboursement de la commande annulée ; 3. Connecteur de paiement → Service de paiement par carte (externe) : transmet la demande de remboursement ; 4. Service de paiement par carte (externe) → Connecteur de paiement : confirme le remboursement effectué ; 5. Service commandes → Service de notifications : déclenche le courriel d'annulation et de remboursement ; 6. Service de notifications → Client grand public : envoie le courriel d'annulation et de remboursement

**Intégrations**

- Intégration au service de paiement par carte : Déléguer l'autorisation, la capture et le remboursement à un tiers spécialisé afin de ne jamais stocker ni faire transiter le numéro de carte par la boutique, réduisant la portée de conformité.
- Intégration à la caisse du comptoir : Synchroniser les niveaux de stock entre les ventes au comptoir et la boutique en ligne dans les deux sens, pour éviter toute survente dans un sens comme dans l'autre.

**Contraintes**

- Résidence des données au Québec traitée comme contrainte dure bornant l'hébergement ; sa couverture sur toute la chaîne (sauvegardes, journaux/surveillance, paiement, courriel) n'est pas encore établie et doit être vérifiée fournisseur par fournisseur.
- Aucune donnée de carte de paiement stockée dans la solution ; traitement et remboursement délégués à un service de paiement externe, à confirmer sur sa capacité de remboursement.
- Livraison à domicile limitée à la province.
- L'intégration du stock dépend d'un moyen d'échange bidirectionnel exploitable côté caisse du comptoir, non confirmé à ce stade ; le système faisant foi pour le stock reste à désigner avec vous.
- Aucun délai maximal de synchronisation du stock n'est fixé ; un risque résiduel de survente subsiste entre deux synchronisations tant que ce délai n'est pas confirmé.
- Volume mensuel non mesuré ; dimensionnement basé sur l'hypothèse haute de 1000 commandes/mois.
- Budget non arrêté : l'architecture proposée sert de base de décision, sans contrainte de coût préalable.
- Les numéros de carte ne transitent jamais par la boutique ni par sa base de données ; ils sont traités uniquement par le service de paiement externe, y compris pour les remboursements.
- Un client authentifié n'accède qu'à son propre profil, panier, commandes et historique.
- L'interface interne de gestion des commandes est réservée au personnel de la brasserie et n'est pas exposée au public.
- Le connecteur vers la caisse du comptoir ne transmet, dans chaque sens, que les mouvements de stock nécessaires, sans exposer les autres données du comptoir ni de la boutique.
- Le stockage des images et documents du catalogue n'est accessible que par liens temporaires, sans URL publique permanente.
- L'hébergement de l'application et de la base est limité à une région respectant la résidence au Québec ; la couverture des sauvegardes, des journaux et des fournisseurs tiers (paiement, courriel, surveillance) reste à confirmer service par service, et n'est pas encore garantie.
- Le service de surveillance et de journalisation centralise les journaux techniques sans donnée de carte ; sa localisation reste à confirmer pour couvrir la résidence au Québec.
- Le service de notifications n'accède qu'à l'adresse courriel et au statut de commande, rien d'autre du profil client.

## Détails techniques

Avec quoi la solution est construite, et où elle est hébergée. Chaque choix porte son statut : retenu lorsque le dossier l'arrête, hypothèse lorsqu'il a simplement servi au chiffrage, à confirmer lorsqu'il dépend d'une réponse attendue. Un choix marqué hypothèse n'engage personne ; il indique ce qui a été supposé pour produire les chiffres.

**Outils de programmation**

- Langage et exécution : Node.js avec TypeScript (langage d'exécution unique pour les services et le portail) (hypothèse) — Équipe de réalisation unique sur un monolithe modulaire : un langage unique simplifie l'exploitation pour un volume modéré (jusqu'à 1000 commandes/mois). Aucune compétence d'équipe précisée au dossier. · Écarté : Python (Django/FastAPI) ; PHP (Laravel) ; .NET/C#
- Cadriciel applicatif : Cadriciel applicatif monolithique modulaire (ex. NestJS) avec modules catalogue, comptes, commandes (incluant annulation/remboursement) et stock (hypothèse) — Le volume déclaré et une équipe unique ne justifient pas des microservices ; un monolithe modulaire garde les transactions locales (annulation liée au stock et au paiement) et simplifie le déploiement, sans fermer la porte à une extraction future. · Écarté : Django (Python) ; Laravel (PHP) ; ASP.NET Core
- Interface utilisateur : Application web front-end (ex. React/Next.js) pour le portail public, interface web interne distincte pour le personnel (hypothèse) — Catalogue, panier et suivi de commande (incluant le statut d'annulation) exigent une expérience réactive côté client ; l'interface interne (préparation, remise, vérification d'âge, annulation) est un outil de travail séparé réservé au personnel. · Écarté : Vue.js ; Rendu côté serveur classique sans framework JS lourd ; Angular
- Base de données : Base de données relationnelle transactionnelle (ex. PostgreSQL) (hypothèse) — Comptes, catalogue, stock, commandes et leurs statuts (incluant annulation/remboursement) forment un modèle structuré avec cohérence forte requise pour éviter la survente dans les deux sens. Aucune donnée de carte n'y est stockée ; les durées de conservation restent à fixer avec vous. · Écarté : MySQL/MariaDB ; Base gérée par le fournisseur infonuagique retenu
- File de tâches de fond : File de tâches asynchrones interne pour l'envoi des courriels, la réconciliation bidirectionnelle de stock et le traitement des remboursements (hypothèse) — Les notifications, la synchronisation de stock dans les deux sens avec la caisse et l'appel de remboursement au service de paiement doivent s'exécuter sans bloquer la réponse au client ; le monolithe modulaire isole ces traitements en tâches internes, adapté au volume déclaré. · Écarté : Courtier de messages dédié (ex. Redis/RabbitMQ) ; Tâches planifiées simples (cron)
- Authentification : Authentification applicative intégrée (courriel/mot de passe, sessions sécurisées) pour les comptes clients (hypothèse) — Volume modéré de comptes grand public, sans exigence de fédération d'identité déclarée ; une authentification intégrée avec hachage sécurisé couvre le besoin déclaré (comptes et accès personnels). · Écarté : Service d'identité géré externe (ex. Auth0, Cognito) ; Connexion via fournisseurs tiers (Google, etc.)
- Paiement : Passerelle de paiement par carte externe, catégorie service de paiement en ligne conforme PCI-DSS, avec capacité de remboursement (fournisseur à choisir) (à confirmer) — Le paiement est délégué à un tiers pour ne jamais stocker le numéro de carte et pour permettre le remboursement d'une commande annulée (refus d'âge à la remise, survente). Le fournisseur n'est pas choisi, ni sa localisation confirmée au regard de la résidence des données. · Écarté : Stripe ; Moneris ; Square ; PayPal
- Courriel et notifications : Service infonuagique transactionnel d'envoi de courriels (catégorie messagerie transactionnelle) (hypothèse) — Trois courriels transactionnels par commande (confirmation, expédition, annulation/remboursement) à volume modéré : un service externe assure la délivrabilité sans exploiter un serveur dédié. Sa localisation reste à vérifier pour couvrir la résidence des données au Québec sur toute la chaîne. · Écarté : Service de messagerie du fournisseur infonuagique retenu ; Serveur SMTP auto-géré
- Observabilité : Journalisation centralisée et surveillance de base (journaux applicatifs, alertes de disponibilité) (à confirmer) — Petite équipe sans personnel d'exploitation dédié : une surveillance minimale détecte les incidents (paiement, synchronisation de stock) sans surinvestir ; la localisation du service de journaux reste à confirmer pour couvrir la résidence au Québec sur toute la chaîne, non garantie à ce jour. · Écarté : Solution infonuagique managée de journaux et métriques ; Outil auto-hébergé
- Intégration continue : Pipeline d'intégration continue et de déploiement automatisé (tests, build, déploiement) (hypothèse) — Un monolithe déployé d'un bloc bénéficie d'un pipeline reproductible pour limiter le risque d'erreur humaine lors des mises à jour fréquentes attendues après le lancement et pendant la stabilisation. · Écarté : Déploiement manuel scripté ; Plateforme d'intégration continue alternative
- Tests : Suite de tests automatisés (unitaires et d'intégration) ciblant le paiement et son remboursement, la synchronisation bidirectionnelle de stock et la vérification d'âge (hypothèse) — Ces zones concentrent le risque métier et légal (survente dans les deux sens, paiement, remboursement, vente à un mineur) : elles justifient un effort de test automatisé prioritaire. La revue de sécurité applicative s'appuie sur l'OWASP ASVS version 5.0.0, niveau de base retenu comme hypothèse à confirmer avec vous (authentification, sessions, contrôle d'accès). · Écarté : Tests manuels de recette seulement ; Couverture automatisée étendue à l'ensemble du portail

**Hébergement**

- Modèle d'hébergement : Infonuagique gérée (plateforme) (à confirmer)
- Catégorie de fournisseur : Fournisseur infonuagique géré disposant d'une région québécoise (ex. OVHcloud, région Beauharnois) pour l'application, la base et le stockage des fichiers du catalogue
- Conservation des données : Québec (centre de données situé au Québec, Canada)
- Sauvegardes et rétention : Sauvegardes régulières de la base (récupération à un point dans le temps) et du stockage objet des images et documents du catalogue, avec réplication distincte de ce dernier ; restauration conjointe base et fichiers testée périodiquement. Fréquence, rétention et durées de conservation des données personnelles à confirmer avec vous.
- Reprise après incident : Hypothèse de reprise après incident : restauration visée sous 24 heures (RTO) avec perte de données maximale d'une journée (RPO), proportionnée à une boutique sans exigence de continuité extrême déclarée ; cible à confirmer avec vous.
- Environnements : Développement · Test / recette · Production

- Le modèle d'hébergement et le fournisseur restent des hypothèses, sans engagement contracté ; le choix définitif dépend de la confirmation de la force de l'exigence de résidence (obligation légale ou préférence).
- La résidence des données peut viser le Québec pour l'hébergement principal, mais la couverture de toute la chaîne (sauvegardes, journaux/surveillance, service de paiement, service de courriel) n'est pas encore établie ; chaque fournisseur tiers doit être vérifié individuellement avant un choix définitif.
- Le fournisseur de paiement n'est pas choisi ; le chiffrage suppose une intégration standard par redirection ou formulaire hébergé, sans stockage de numéro de carte, avec capacité de remboursement pour les annulations (refus d'âge à la remise, survente).
- Le moyen d'échange bidirectionnel avec la caisse du comptoir n'est pas confirmé (sens caisse vers boutique et boutique vers caisse) ; le connecteur et la file de tâches de synchronisation de stock sont chiffrés sur l'hypothèse d'une interface exploitable dans les deux sens, avec un délai de synchronisation de l'ordre de quelques minutes.
- Référentiel de vérification de sécurité applicative retenu comme hypothèse : OWASP ASVS version 5.0.0, niveau de base à confirmer avec vous, portant notamment sur l'authentification, les sessions et le contrôle d'accès.
- Alternative d'hébergement écartée à ce stade : infrastructure infonuagique de type infrastructure-service (IaaS) avec gestion serveur complète, jugée disproportionnée pour une petite équipe sans personnel d'exploitation dédié.

## Maquettes d'interface

_Une maquette illustre le périmètre cadré. Ce n'est ni un design, ni un engagement sur une identité visuelle, ni une promesse sur le nombre d'écrans livrés._

**Passe M-1 — Site grand public**

- Écran 1 — Catalogue des bières (Liste) — Présenter les caisses disponibles à l'achat en ligne, avec accès direct à la fiche de chaque produit. · Éléments cadrés servis : E-1, E-3
- Écran 2 — Fiche produit (Détail) — Détailler une bière (description, format) et permettre son ajout au panier. · Éléments cadrés servis : E-3
- Écran 3 — Mon panier (Liste) — Récapituler les articles choisis, leur quantité disponible, et mener vers la commande. · Éléments cadrés servis : E-2, E-3, E-6
- Écran 4 — Vérification de l'âge (Formulaire) — Confirmer l'âge légal du client avant de poursuivre vers le paiement. · Éléments cadrés servis : E-9
- Écran 5 — Cueillette ou livraison (Formulaire) — Choisir entre récupérer la commande en magasin ou se faire livrer dans la province. · Éléments cadrés servis : E-5, E-14
- Écran 6 — Paiement (Formulaire) — Saisir les informations de carte et confirmer le paiement sécurisé de la commande. · Éléments cadrés servis : E-4, E-15, E-13
- Écran 7 — Commande confirmée (Confirmation) — Afficher le récapitulatif de la commande et annoncer l'envoi d'un courriel de confirmation. · Éléments cadrés servis : E-7, E-13
- Écran 8 — Suivi de ma commande (Détail) — Montrer l'état actuel d'une commande (reçue, en préparation, prête ou expédiée). · Éléments cadrés servis : E-8, E-22
- Écran 9 — Mon compte (Paramètres) — Regrouper les informations personnelles du client et l'historique de ses commandes. · Éléments cadrés servis : E-11
- Écran 10 — Annuler ou être remboursé (Formulaire) — Permettre au client de demander l'annulation d'une commande et suivre le remboursement. · Éléments cadrés servis : E-10
- Écran 11 — Préparation des commandes (Tableau de bord) — Vue interne pour le personnel du comptoir listant les commandes à préparer, avec statut de stock synchronisé. · Éléments cadrés servis : E-6, E-12, E-22

## Décisions d'architecture et justifications

Aucune décision d'architecture justifiée retenue.

## Effort, enveloppe de services et coûts

Montants en CAD, horizon de 12 mois. Les bornes basse / centrale / haute sont des scénarios de planification, non un intervalle de confiance ; l'enveloppe n'est pas un devis ferme.

| Résultat | Basse | Centrale | Haute |
|---|---|---|---|
| Effort (heures) | 232,5 h | 407,3 h | 760,6 h |
| Enveloppe de services | 32 152,25 CAD | 56 157,25 CAD | 104 342,75 CAD |
| Coût total client sur l'horizon | 70 601,25 CAD | 94 606,25 CAD | 142 791,75 CAD |
| Dont frais proportionnels à l'activité (D-14) | 34 800,00 CAD | 34 800,00 CAD | 34 800,00 CAD |
| Coût du projet hors frais proportionnels à l'activité | 35 801,25 CAD | 59 806,25 CAD | 107 991,75 CAD |

- **Dépenses initiales** : 25,00 CAD
- **Récurrent mensuel indicatif** : 3 202,00 CAD
- **Récurrent sur l'horizon** : 38 424,00 CAD
- Montants hors taxes.
- Convention du récurrent annuel : toute période entamée sur l'horizon est comptée entière.
- Les frais proportionnels à l'activité (frais de transaction d'un processeur de paiement, par exemple) suivent vos ventes : ils se paient sur le chiffre d'affaires, pas sur le budget du projet. Ils restent inclus dans le coût total ci-dessus, et sont chiffrés à part pour que la décision ne les confonde pas avec le coût du projet.
- **Budget recommandé à autoriser** : 113 527,50 CAD (scénario central plus une provision pour imprévus de 18 921,25 CAD, soit 20 %)
- La provision suit la part du budget à confirmer : 10 % jusqu'à 15 %, 15 % jusqu'à 40 %, 20 % au-delà.
- **Sans l'accélération supposée par le mode de réalisation : 91 390,00 CAD d'enveloppe de services et 24 semaines.**
- **74 % du budget (70 271,00 CAD sur 94 606,25 CAD) repose sur des hypothèses que vos réponses peuvent confirmer — voir « À préciser ensemble ».**


### Coût total de possession

| Résultat | Basse | Centrale | Haute |
|---|---|---|---|
| Coût total (construction, dépenses initiales et récurrent sur l'horizon) | 70 601,25 CAD | 94 606,25 CAD | 142 791,75 CAD |

### Hypothèse de réalisation

Mode : Réalisation assistée par l'IA. Réalisation assistée par des outils d'IA de développement, par une équipe qui les emploie au quotidien, sous la supervision de développeurs. Les heures de chaque poste sont estimées pour une réalisation classique, puis multipliées par un facteur publié selon la nature du travail ; le dossier montre les deux.

Facteur = heures retenues ÷ heures de réalisation classique, par nature de travail et par borne (basse / centrale / haute).

| Nature de travail | Facteurs (b / c / h) | Base | Source et date |
|---|---|---|---|
| Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 0,30 / 0,40 / 0,60 | Hypothèse d'une équipe rompue aux outils d'IA sur une application neuve : au-delà des essais en entreprise publiés (0,79–0,81), en deçà du cas isolé de Peng 2023 (0,44) pour la valeur haute. | Peng et al. 2023, arXiv 2302.06590 ; Cui, Demirer et al., Management Science 2025 ; décision d'Alexandre du 27 septembre 2026, 2026-09-27 |
| Tests automatisés et documentation | 0,25 / 0,35 / 0,55 | Artefacts les plus générables ; même hypothèse d'équipe que le code standard. | Extrapolation des facteurs du code standard ; décision d'Alexandre du 27 septembre 2026, 2026-09-27 |
| Infrastructure et déploiement | 0,50 / 0,65 / 0,85 | Configuration largement générée ; les pièges propres à chaque fournisseur demeurent. | Jugement structuré ; décision d'Alexandre du 27 septembre 2026, 2026-09-27 |
| Migration et reprise de données | 0,55 / 0,70 / 0,90 | Les scripts s'accélèrent, la compréhension des données existantes beaucoup moins. | Jugement structuré ; décision d'Alexandre du 27 septembre 2026, 2026-09-27 |
| Intégration avec l'existant et les tiers | 0,65 / 0,80 / 1,00 | Zone du ralentissement mesuré par METR 2025 : inconnues et attentes de tiers, accélération limitée. | METR, juillet 2025, arXiv 2507.09089 ; décision d'Alexandre du 27 septembre 2026, 2026-09-27 |
| Analyse, cadrage, conception | 0,70 / 0,80 / 0,95 | Temps dominé par les échanges et les décisions humaines ; rédaction et variantes accélérées. | Jugement structuré ; décision d'Alexandre du 27 septembre 2026, 2026-09-27 |
| Coordination, validation client, formation | 1,00 / 1,00 / 1,00 | Calendriers de personnes ; la politique compte déjà 5 jours de validation par jalon. | Politique de chiffrage de la plateforme (boucle de validation client par jalon), 2026-09-27 |
| Sécurité, revue et assurance qualité | 1,00 / 1,00 / 1,10 | Plus de code généré = plus à relire (Faros 2025 : revue +91 % ; DORA 2024–2025 : stabilité en baisse). | Faros AI 2025 ; DORA 2024 et 2025 ; Denisov-Blanch (Stanford) 2025, 2026-09-27 |

| Borne | Référence | Retenue |
|---|---|---|
| Basse | 460 h | 232,5 h |
| Centrale | 677 h | 407,3 h |
| Haute | 981 h | 760,6 h |

- 6 facteurs reposent sur un jugement, sans mesure dédiée : Code standard (écrans, formulaires, CRUD, API internes, logique courante), Tests automatisés et documentation, Infrastructure et déploiement, Migration et reprise de données, Intégration avec l'existant et les tiers, Analyse, cadrage, conception.
- Si l'accélération ne se matérialisait pas, l'enveloppe de services serait de 91 390,00 CAD au lieu de 56 157,25 CAD, et le délai de 24 semaines au lieu de 18 (scénario central).

### Postes d'effort

| Code | Poste | Nature de travail | Référence (b / c / h) | Facteur (b / c / h) | Basse | Centrale | Haute | À confirmer | Comment ce chiffre est établi |
|---|---|---|---|---|---|---|---|---|---|
| P-1 | Cadrage et spécification détaillée | Analyse, cadrage, conception | 20 / 32 / 50 h | 0,70 / 0,80 / 0,95 | 14 h | 25,6 h | 47,5 h | dépend de Q-3 | Jugement structuré : ampleur des ateliers estimée à partir du nombre de zones encore ouvertes dans le dossier révisé (âge, caisse bidirectionnelle, paiement, annulation, conservation). |
| P-2 | Conception technique et modèle de données | Analyse, cadrage, conception | 18 / 30 / 46 h | 0,70 / 0,80 / 0,95 | 12,6 h | 24 h | 43,7 h | dépend de Q-4 | Jugement structuré à partir de l'architecture déjà esquissée (composants, flux bidirectionnels et stockage des fichiers définis dans le dossier révisé). |
| P-3 | Catalogue de produits et panier | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 42 / 58 / 76 h | 0,30 / 0,40 / 0,60 | 12,6 h | 23,2 h | 45,6 h | — | Décomposition en cinq sous-tâches estimables (liste/fiche, panier, recherche, habillage, stockage d'images), sommées. |
| P-4 | Comptes clients et authentification | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 18 / 28 / 45 h | 0,30 / 0,40 / 0,60 | 5,4 h | 11,2 h | 27 h | dépend de Q-2 | Jugement structuré : fonction standard construite sur une brique d'authentification réutilisée, sans particularité métier. |
| P-5 | Service commandes : panier, remise, annulation et remboursement | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 44 / 60 / 80 h | 0,30 / 0,40 / 0,60 | 13,2 h | 24 h | 48 h | — | Décomposition en quatre sous-tâches du cycle de vie de la commande, incluant l'annulation, sommées. |
| P-6 | Déclaration et confirmation de vérification d'âge | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 10 / 16 / 25 h | 0,30 / 0,40 / 0,60 | 3 h | 6,4 h | 15 h | dépend de Q-6 | Jugement structuré sur une fonction simple d'après l'hypothèse retenue par défaut du dossier révisé. |
| P-7 | Suivi de commande et interface interne | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 28 / 39 / 50 h | 0,30 / 0,40 / 0,60 | 8,4 h | 15,6 h | 30 h | — | Décomposition en trois écrans/fonctions du suivi, incluant l'annulation, sommées. |
| P-8 | Logique de réconciliation bidirectionnelle du stock partagé | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 31 / 44 / 56 h | 0,30 / 0,40 / 0,60 | 9,3 h | 17,6 h | 33,6 h | — | Décomposition en trois flux (réconciliation entrante, répercussion sortante, gestion des écarts), sommées. |
| P-9 | Notifications par courriel | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 12 / 19 / 30 h | 0,30 / 0,40 / 0,60 | 3,6 h | 7,6 h | 18 h | dépend de Q-2 | Jugement structuré sur une fonction simple réutilisant un service d'envoi courant, étendue à un troisième modèle. |
| P-10 | Intégration au service de paiement par carte, avec remboursement | Intégration avec l'existant et les tiers | 22 / 33 / 55 h | 0,65 / 0,80 / 1,00 | 14,3 h | 26,4 h | 55 h | dépend de Q-5 | Jugement structuré : intégration typique d'un service de paiement par carte avec SDK réutilisable, étendue au remboursement. |
| P-11 | Intégration bidirectionnelle à la caisse du comptoir | Intégration avec l'existant et les tiers | 30 / 46 / 75 h | 0,65 / 0,80 / 1,00 | 19,5 h | 36,8 h | 75 h | dépend de Q-4 | Jugement structuré sur un connecteur bidirectionnel typique, en l'absence d'information sur le système de caisse réel et sa capacité de flux retour. |
| P-12 | Chargement initial du catalogue et du stock de départ | Migration et reprise de données | 6 / 9 / 15 h | 0,55 / 0,70 / 0,90 | 3,3 h | 6,3 h | 13,5 h | dépend de Q-1 | Jugement structuré : chargement d'un catalogue restreint, sans système source à migrer puisqu'il s'agit d'un nouveau produit. |
| P-13 | Revue de sécurité, minimisation des données de carte et référentiel ASVS | Sécurité, revue et assurance qualité | 16 / 25 / 40 h | 1,00 / 1,00 / 1,10 | 16 h | 25 h | 44 h | dépend de Q-8 | Jugement structuré : revue ciblée sur les flux sensibles identifiés dans l'architecture, structurée selon les chapitres pertinents de l'ASVS 5.0.0. |
| P-14 | Tests et recette | Tests automatisés et documentation | 45 / 61 / 81 h | 0,25 / 0,35 / 0,55 | 11,25 h | 21,35 h | 44,55 h | — | Décomposition en cinq sous-tâches de test, incluant l'automatisation des zones critiques, sommées. |
| P-15 | Mise en production, configuration de l'environnement et résidence des données | Infrastructure et déploiement | 28 / 44 / 70 h | 0,50 / 0,65 / 0,85 | 14 h | 28,6 h | 59,5 h | dépend de Q-8 | Jugement structuré : mise en place standard de trois environnements avec base de données, stockage objet, surveillance et sauvegardes coordonnées, plus un inventaire de résidence par fournisseur. |
| P-16 | Documentation technique et opérationnelle | Tests automatisés et documentation | 9 / 15 / 23 h | 0,25 / 0,35 / 0,55 | 2,25 h | 5,25 h | 12,65 h | dépend de Q-2 | Jugement structuré sur la documentation d'un projet de cette taille (un monolithe modulaire, deux intégrations bidirectionnelles/avec remboursement). |
| P-17 | Formation du personnel | Coordination, validation client, formation | 7 / 11 / 18 h | 1,00 / 1,00 / 1,00 | 7 h | 11 h | 18 h | dépend de Q-3 | Jugement structuré : une formation courte pour une interface interne simple, étendue au parcours d'annulation. |
| P-18 | Gestion de projet et coordination | Coordination, validation client, formation | 58 / 81 / 106 h | 1,00 / 1,00 / 1,00 | 58 h | 81 h | 106 h | — | Analogie interne : ratio de 10 à 18 % appliqué à la somme des heures centrales des autres postes du dossier révisé (environ 596 h). |
| P-19 | Stabilisation après mise en service | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 16 / 26 / 40 h | 0,30 / 0,40 / 0,60 | 4,8 h | 10,4 h | 24 h | dépend de Q-1 | Jugement structuré : ampleur habituelle d'une stabilisation post-lancement, élargie par les flux bidirectionnels et le remboursement ajoutés à ce projet. |

### Taux appliqués et heures par rôle

Taux de référence pour l'évaluation : ils convertissent les heures en dollars et n'engagent personne ; un mandat de réalisation se négocie à part.

| Rôle | Taux de référence | Basse | Centrale | Haute |
|---|---|---|---|---|
| Analyste d'affaires / chargé de projet | 140,00 CAD | 14 h | 25,6 h | 47,5 h |
| Analyste qualité / développeur | 115,00 CAD | 11,25 h | 21,35 h | 44,55 h |
| Architecte technique | 165,00 CAD | 28,6 h | 49 h | 87,7 h |
| Chargé de projet | 140,00 CAD | 58 h | 81 h | 106 h |
| Développeur / support applicatif | 120,00 CAD | 4,8 h | 10,4 h | 24 h |
| Développeur back-end | 130,00 CAD | 16,8 h | 31,6 h | 66 h |
| Développeur back-end / analyste données | 135,00 CAD | 12,6 h | 23,9 h | 47,1 h |
| Développeur back-end / intégration | 130,00 CAD | 33,8 h | 63,2 h | 130 h |
| Développeur back-end/front-end | 130,00 CAD | 29,4 h | 56,4 h | 117,6 h |
| Formateur / analyste d'affaires | 135,00 CAD | 7 h | 11 h | 18 h |
| Rédacteur technique / architecte | 150,00 CAD | 2,25 h | 5,25 h | 12,65 h |
| Spécialiste infrastructure / DevOps | 150,00 CAD | 14 h | 28,6 h | 59,5 h |

### Dépenses du projet

| Code | Dépense | Périodicité | Montant par période | Sur l'horizon | À confirmer | Comment ce chiffre est établi |
|---|---|---|---|---|---|---|
| D-1 | Frais d'ouverture des comptes fournisseurs (paiement, hébergement) (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Pratique généralisée chez les fournisseurs de paiement et d'hébergement en libre-service (ouverture de compte gratuite, facturation à l'usage). |
| D-2 | Enregistrement du nom de domaine (première année) (prix hypothèse) | Une fois | 25,00 CAD | 25,00 CAD | dépend de Q-8 | Jugement structuré : prix habituel d'un domaine de premier niveau, non vérifié pour ce dossier précis. |
| D-3 | Renouvellement annuel du domaine (équivalent mensuel) (prix hypothèse) | Mensuelle | 2,00 CAD | 24,00 CAD | hypothèse à confirmer | Jugement structuré : renouvellement annuel typique d'un domaine, réparti sur 12 mois. |
| D-4 | Gabarit ou composant commercial pour l'interface (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Cohérent avec l'approche décrite (construction sur mesure du cœur métier). |
| D-5 | Frais de configuration facturés par les fournisseurs tiers (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Pratique courante des fournisseurs SaaS visés : configuration en libre-service sans frais. |
| D-6 | Reprise de données d'un système existant (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Donnée déclarée par le client dans le questionnaire d'ouverture (nature = nouveau produit, à partir de rien). |
| D-7 | Matériel physique dédié à l'exploitation (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Cohérent avec l'architecture proposée (hébergement applicatif infonuagique). |
| D-8 | Honoraires d'experts externes (juridique, réglementaire) (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Exclusion déclarée par le client dans le questionnaire d'ouverture (exclusions : conseil juridique). |
| D-9 | Photographie et rédaction des fiches du catalogue initial (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Hypothèse par défaut faute de réponse dans le dossier ou le questionnaire d'ouverture sur qui produit le contenu du catalogue. |
| D-10 | Audit de sécurité externe avant lancement (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Cohérent avec la portée de conformité réduite : les numéros de carte ne transitent pas par la solution, ce qui limite le besoin d'un audit PCI complet. |
| D-11 | Mise en place initiale de l'infrastructure d'hébergement (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Pratique courante des hébergeurs infonuagiques en libre-service (aucun frais d'activation). |
| D-12 | Hébergement mensuel de l'application, de la base et du stockage | Mensuelle | 220,00 CAD | 2 640,00 CAD | dépend de Q-1 | Jugement structuré : dimensionnement pour une charge moyenne de l'ordre de quelques centaines de commandes/mois avec absorption automatique des pics jusqu'à 1000/mois (principe d'optimisation des coûts), sans devis fournisseur vérifié pour ce dossier ; la région Beauharnois (Québec) d'OVHcloud est citée comme option de référence pour le stockage objet. |
| D-13 | Abonnement au service de courriel transactionnel (prix hypothèse) | Mensuelle | 25,00 CAD | 300,00 CAD | dépend de Q-1 | Jugement structuré : à 1000 commandes/mois et deux à trois courriels par commande (confirmation, expédition, annulation/remboursement le cas échéant), le volume reste dans un palier d'entrée courant. |
| D-14 | Frais de transaction du service de paiement par carte (prix hypothèse) | Mensuelle | 2 900,00 CAD | 34 800,00 CAD | dépend de Q-1 | Jugement structuré : taux de traitement standard appliqué à un panier moyen de 90 CAD (valeur harmonisée avec la volumétrie du dossier, non confirmée par le client) et 1000 commandes/mois (borne haute). |
| D-15 | Service tiers de vérification d'identité à l'acte (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Réponse par défaut proposée à la question ouverte sur le mécanisme de vérification d'âge, en l'absence de décision confirmée. |
| D-16 | Surveillance applicative et journalisation centralisée (prix hypothèse) | Mensuelle | 30,00 CAD | 360,00 CAD | dépend de Q-8 | Jugement structuré : palier d'entrée courant pour une supervision de base (disponibilité, journaux, alertes) d'une application de cette taille. |
| D-17 | Sauvegardes et rétention de la base et du stockage des fichiers (images du catalogue) (prix hypothèse) | Mensuelle | 25,00 CAD | 300,00 CAD | dépend de Q-11 | Jugement structuré : volume de données modeste (commandes, catalogue, images) à ce stade de démarrage ; le poste couvre désormais explicitement la sauvegarde du stockage de fichiers, sans condition, avec test de restauration conjointe. |
| D-18 | Licences logicielles annuelles renouvelables (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Cohérent avec l'approche technique décrite (monolithe modulaire sur composants libres). |
| D-19 | Contrat de support payant auprès des fournisseurs tiers (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Pratique courante : support de base inclus chez les fournisseurs infonuagiques et de paiement en libre-service. |
| D-20 | Licences ou abonnements logiciels généraux hors solution (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Cohérent avec le périmètre déclaré, qui ne mentionne aucun outil de gestion additionnel. |
| D-21 | Autres dépenses non catégorisées (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Revue systématique des catégories de dépenses applicables au dossier. |

## Hypothèses de consommation et de prix, postes non chiffrés et limites

Les heures sont des scénarios de planification (basse / centrale / haute), sans signification probabiliste. Tout poste entre dans les totaux : l'incertitude s'exprime par la largeur de la fourchette et par la base écrite de chaque chiffre, jamais par un retrait du total. Les lignes qui reposent sur une hypothèse à confirmer sont marquées comme telles, avec la question dont elles dépendent, et la part du budget qu'elles représentent est indiquée.

- Prix d'essai ou hypothèses (non référencés) : D-1, D-2, D-3, D-4, D-5, D-6, D-7, D-8, D-9, D-10, D-11, D-13, D-14, D-15, D-16, D-17, D-18, D-19, D-20, D-21.
- Les heures retenues supposent une réalisation assistée par des outils d'IA de développement : les facteurs appliqués sont des hypothèses déclarées, dont 6 reposent sur un jugement, sans mesure dédiée. La section « Hypothèse de réalisation » dit ce que vaudrait le dossier si l'accélération ne se matérialisait pas.
- 13 décisions d'architecture (DA-1, DA-2, DA-3, DA-4, DA-5, DA-6, DA-7, DA-8, DA-9, DA-10, DA-11, DA-12, DA-13) : propositions non encore revues (maintenues telles quelles à la revue).

## Risques et dépendances utiles à la décision

- Le système de caisse du comptoir n'expose peut-être aucune interface exploitable dans le sens boutique vers caisse (retrait d'une caisse vendue en ligne). — Sans flux retour, une caisse vendue en ligne resterait vendable au comptoir : la survente se produit dans l'autre sens, malgré la synchronisation prévue.
- Le mécanisme de vérification d'âge (déclaration en ligne, contrôle à la remise) n'est pas défini, et son acteur n'est plus désigné si un transporteur externe livre. — Une déclaration seule peut être jugée insuffisante au regard de la loi ; sans acteur de contrôle à la remise, l'exigence légale resterait sans mécanisme réel pour les livraisons.
- Le volume réel de commandes n'est pas mesuré ; l'architecture est dimensionnée sur l'hypothèse haute de 1000 commandes/mois. — Un volume réel plus bas entraînerait un hébergement surdimensionné et des coûts récurrents évitables ; un volume plus haut imposerait une révision du dimensionnement.
- Le fournisseur de paiement n'est pas choisi ; sa capacité de remboursement et son mode d'intégration (redirection vs formulaire intégré) restent à confirmer. — Un mode d'intégration plus intrusif augmenterait l'effort de sécurisation ; l'absence de remboursement natif ajouterait un développement compensatoire.
- La résidence des données au Québec n'est établie que pour l'hébergement principal ; les sauvegardes, les journaux et les fournisseurs tiers (paiement, courriel, surveillance) peuvent traiter des données hors du territoire exigé. — Non-conformité possible à l'exigence de résidence si elle est confirmée comme obligation ferme, nécessitant de resélectionner des fournisseurs pour toute la chaîne, pas seulement l'application.
- La mise à jour manuelle des statuts de commande par le personnel repose sur la discipline opérationnelle, sans automatisation ni transporteur intégré. — Risque d'erreurs ou de retards dans l'information communiquée au client, sans impact sur l'architecture elle-même.
- Aucun délai maximal de synchronisation du stock n'est fixé ; l'hypothèse par défaut admet un export périodique de quelques minutes. — Entre deux synchronisations, une caisse déjà vendue au comptoir pourrait rester vendable en ligne, avec un risque de commande à annuler après paiement.
- Aucune durée de conservation ni règle de suppression n'est fixée pour les comptes, adresses, dates de naissance déclarées et le journal des vérifications d'âge. — Des renseignements personnels risquent d'être conservés sans limite, y compris dans les sauvegardes et les journaux, au-delà de vos obligations légales.
- Ni les frais de livraison à domicile ni les taxes applicables ne sont encore calculés dans le panier. — Le montant payé par le client pourrait être incorrect au lancement, ou une fonction non chiffrée devrait être ajoutée en cours de réalisation.
- La sauvegarde et la restauration coordonnée entre la base de données et le stockage des images du catalogue ne sont pas encore prévues. — Une restauration de la base seule laisserait le catalogue sans images, ou avec des références orphelines.

## Volumétrie retenue

| Grandeur | Valeur retenue | À confirmer | Comment ce chiffre est établi |
|---|---|---|---|
| transactions par mois | 1000 | — | Réponse déclarée au questionnaire d'ouverture (bande 100 à 1000 commandes/mois), mais la description libre indique que ce chiffre n'a jamais été mesuré (« quelques centaines »). |
| valeur moyenne par transaction | 90 | hypothèse à confirmer | Jugement structuré : panier moyen approximé à environ deux caisses de bière à un prix de détail courant pour ce type de produit. |
| articles au catalogue | 12 | hypothèse à confirmer | Jugement structuré : une microbrasserie propose typiquement une dizaine de produits distincts (styles de bière, formats de caisse). |
| facteur de pointe | 2 | hypothèse à confirmer | Jugement structuré : les commerces saisonniers de boissons connaissent des pics autour des congés et événements estivaux, de l'ordre du double du volume moyen. |

## Ce qui ferait bouger le budget

| Facteur | Hypothèse retenue | Alternative | Impact | Effet sur le délai |
|---|---|---|---|---|
| Caisse fermée, sans flux retour (boutique vers caisse) exploitable | Le système de caisse expose au moins un export exploitable et peut recevoir un flux retour sans développement côté caisse (hypothèse des postes P-11 et P-8 révisés). | Si la caisse ne peut recevoir aucun flux retour, un mécanisme de contournement (réservation compensatoire, import manuel régulier) doit remplacer la répercussion automatique boutique vers caisse. | +25 à +55 h sur l'intégration caisse, +10 à +20 h sur la réconciliation de stock, soit +35 à +75 h · environ +4 550 $ à +9 750 $ CAD (au taux moyen des rôles de développement/intégration concernés) | +2 à +3,5 semaines (incluant l'attente d'une confirmation du fournisseur de caisse) |
| Fournisseur de paiement imposé ou sans remboursement natif | Le service de paiement retenu propose un SDK standard incluant une fonction de remboursement, sans exigence particulière imposée par la brasserie. | Un fournisseur imposé, ou sans remboursement natif, allongerait l'intégration, la revue de sécurité et la logique de statut de commande. | +15 à 30 h sur l'intégration paiement, +5 à 10 h sur la revue de sécurité, +10 à 20 h sur la logique de commande, soit +30 à +60 h · environ +3 900 $ à +7 800 $ CAD | +1 à +2 semaines, en plus du délai déjà prévu pour l'ouverture du compte marchand |
| Volume réel nettement sous la borne haute retenue (1000/mois) | L'infrastructure et le test de charge sont dimensionnés sur la borne haute déclarée (1000 commandes/mois), faute de mesure réelle. | Si le volume réel se confirme à quelques centaines par mois, le dimensionnement de l'infrastructure et l'ampleur du test de charge peuvent être réduits. | -8 à -12 h sur le test de charge, -10 à -18 h sur la configuration d'infrastructure, soit -18 à -30 h · environ -2 340 $ à -3 900 $ CAD | -0,5 à -1 semaine |
| Vérification d'âge par service tiers ou remise via transporteur externe | Une auto-déclaration en ligne et un contrôle visuel par le personnel de la brasserie suffisent à la remise, sans service tiers ni transporteur externe. | Un service tiers de vérification d'identité, ou une adaptation du contrôle pour un transporteur externe (sans acteur interne à la remise), ajouterait une intégration et une logique dédiées. | +15 à 25 h pour un service tiers, +8 à 15 h pour l'adaptation transporteur, soit +23 à +40 h · environ +2 990 $ à +5 200 $ CAD | +1 à +1,5 semaine |
| Fournisseur tiers (paiement, courriel, surveillance) non conforme à la résidence au Québec | Les fournisseurs tiers retenus peuvent confirmer un traitement et un stockage de leurs propres données au Québec ou au Canada, sans changement d'architecture. | Si un fournisseur ne peut confirmer cette résidence, son remplacement par une alternative conforme ajouterait de la recherche, de l'intégration et une revue de sécurité additionnelle. | +15 à 25 h de remplacement de fournisseur, +5 à 10 h de revue de sécurité, soit +20 à +35 h · environ +2 600 $ à +4 550 $ CAD | +1 à +2 semaines (recherche d'alternative et nouveaux tests) |

## Délai

18 semaines depuis le démarrage (13 à 27 semaines).
Hypothèse de capacité : 1,00 personne(s) à 40,00 h productives par semaine, plus une coordination à temps partiel.
Dont 7 semaine(s) de délais externes non compressibles.

### Rythmes possibles

| Rythme | Équipe | Délai | Effort | Enveloppe de services |
|---|---|---|---|---|
| Rapide | 5 personnes | 10 semaines | 488,76 h | 67 388,70 CAD |
| Équilibré | 3 personnes | 11 semaines | 448,03 h | 61 772,98 CAD |
| Économe | 1 personne | 18 semaines | 407,3 h | 56 157,25 CAD |

Le même travail (407,3 h), réparti sur plus ou moins de personnes. Linuen le calcule à partir des postes et de leurs dépendances : un poste est tenu par une personne à la fois et ne commence qu'une fois ses préalables terminés. La plus longue chaîne de postes dépendants (97,8 h) fixe le délai le plus court possible : au-delà de l'équipe « Rapide », une personne de plus ne l'accélérerait pas.

Chaque personne supplémentaire ajoute 5 % d'heures de coordination (au plus 30 %) : une équipe plus grande va plus vite et coûte un peu plus. Hypothèse : 40 h productives par personne et par semaine.

Valeurs centrales ; délais externes compris (7 semaines). Le délai annoncé plus haut est celui de l'hypothèse de capacité du dossier.

Phases ramenées par l'application dans la proportion de l'effort retenu (heures retenues ÷ heures de référence, basse / centrale / haute : 0,51 / 0,60 / 0,78). Les délais externes ne bougent pas.

| Phase | Référence (b / c / h) | Retenue (b / c / h) | Jalon |
|---|---|---|---|
| Cadrage | 0,66 / 0,97 / 1,4 sem. | 0,3 / 0,6 / 1,1 sem. | Spécifications détaillées validées et périmètre figé (vérification d'âge et son acteur à la remise, échange bidirectionnel avec la caisse, fournisseur de paiement avec remboursement, politique d'annulation, conservation des données) |
| Conception | 0,58 / 0,85 / 1,23 sem. | 0,3 / 0,5 / 1 sem. | Architecture du monolithe modulaire, modèle de données (incluant conservation) et stockage objet des images approuvés |
| Réalisation | 5,34 / 7,86 / 11,39 sem. | 2,7 / 4,7 / 8,8 sem. | Catalogue, comptes, commandes avec annulation et remboursement, vérification d'âge, suivi et réconciliation bidirectionnelle de stock livrés en environnement de test |
| Intégrations | 1,4 / 2,05 / 2,98 sem. | 0,7 / 1,2 / 2,3 sem. | Connecteurs paiement (avec remboursement) et caisse du comptoir (flux bidirectionnel) fonctionnels de bout en bout |
| Recette | 1,81 / 2,66 / 3,85 sem. | 0,9 / 1,6 / 3 sem. | Recette client complétée, revue de sécurité ASVS des flux de paiement close et parcours d'annulation validé |
| Mise en production | 1,23 / 1,81 / 2,63 sem. | 0,6 / 1,1 / 2 sem. | Environnement de production configuré au Québec avec résidence vérifiée chez les fournisseurs tiers, catalogue et stock de départ chargés |
| Stabilisation | 0,49 / 0,73 / 1,05 sem. | 0,2 / 0,4 / 0,8 sem. | Période de stabilisation post-lancement terminée sans anomalie critique ouverte sur le paiement, le remboursement ou le stock bidirectionnel |

- Ouverture et validation du compte marchand chez le fournisseur de paiement : 2 semaine(s) — Les fournisseurs de paiement par carte exigent une vérification d'identité et de conformité, incluant la capacité de remboursement, avant d'activer un compte marchand ; ce délai dépend du fournisseur, pas du rythme de développement.
- Obtention d'un accès exploitable et bidirectionnel à la caisse du comptoir : 1.5 semaine(s) — Le fournisseur du système de caisse doit confirmer et fournir une interface ou un export permettant non seulement de lire le stock mais aussi d'y répercuter les ventes en ligne ; délai hors du contrôle de l'équipe de réalisation.
- Confirmation de la résidence des données chez les fournisseurs tiers (paiement, courriel, surveillance) : 1 semaine(s) — Chaque fournisseur externe doit confirmer la région où il traite et stocke ses propres données avant que le choix d'hébergement et de services auxiliaires ne soit arrêté pour toute la chaîne.
- Boucles de validation client sur les règles métier et les maquettes : 1 semaine(s) — La brasserie doit valider les règles de vérification d'âge, de remise, d'annulation/remboursement et l'apparence du catalogue avant que la conception ne soit figée.
- Disponibilité du personnel du comptoir pour la recette et la formation : 1 semaine(s) — Le personnel doit être libéré de ses tâches courantes pour tester le suivi de commande, la remise, l'annulation et suivre la formation.

Ce délai est un plan de réalisation sous hypothèse de capacité, non un engagement de livraison.

## Ce qui n'est pas compris

- contenus et médias — La brasserie fournit textes et photos ; seule l'intégration technique du stockage des images est chiffrée (P-3). Aucune dépense de photographie ni de rédaction n'est prévue.
- référencement — Aucune prestation de référencement ou de campagne d'acquisition n'est mentionnée au dossier ni chiffrée.
- traduction — Exclusion explicite déclarée à l'ouverture du dossier.
- reprise de données historiques — Aucun système de vente en ligne préexistant à migrer : seul un chargement initial restreint du catalogue et du stock de départ est prévu, comme poste distinct.
- accessibilité — Aucune exigence d'accessibilité formulée dans le dossier ; à chiffrer en variante si elle devient requise.
- conseil juridique ou réglementaire — Exclusion explicite déclarée à l'ouverture. Le mécanisme de vérification d'âge en cas de remise par un transporteur externe, et sa validité légale, restent à valider par vous avec votre propre conseil.
- licences tierces — Les services externes (paiement, courriel, hébergement, surveillance) sont des coûts d'usage récurrents, pas des licences ; aucune licence propriétaire additionnelle n'est prévue.
- support après stabilisation — Seule une période de stabilisation de deux à trois semaines suivant le lancement est incluse ; un contrat de support continu ferait l'objet d'une entente distincte.
- évolutions fonctionnelles — Seul le périmètre actuellement décrit, incluant l'annulation/remboursement et la synchronisation bidirectionnelle du stock, est chiffré ; toute évolution ultérieure fera l'objet d'une estimation distincte.

Compris dans l'évaluation : formation.

## À préciser ensemble

Écart de fourchette (haute − basse) qui dépend de chaque réponse, classé par écart en jeu. Une réponse qui sort de l'hypothèse retenue peut déplacer une ligne au-delà de ses bornes : voir « Ce qui ferait bouger le budget ».

| Question | Réponse retenue (hypothèse) | Lignes concernées | Écart en jeu (haute − basse) |
|---|---|---|---|
| Q-4 — Quel est le système de caisse du comptoir, et offre-t-il une interface ou une API pour synchroniser le stock dans les deux sens ? | Le modèle de conservation des données peut être fixé avant la fin de la conception. ; La caisse peut recevoir un flux entrant, pas seulement en émettre un. ; Le système de caisse expose au moins un export exploitable ; un flux retour est possible sans développement côté caisse. | P-2, P-8, P-11 | 15 627,00 CAD |
| Q-3 — Existe-t-il une date de lancement souhaitée (ex. saison, événement) ? | Le client est disponible pour trois ateliers courts. ; L'équipe du comptoir est restreinte et disponible pour une séance groupée. ; Le nombre de décisions à trancher en cours de route reste comparable à celui identifié dans ce dossier révisé. | P-1, P-17, P-18 | 12 895,00 CAD |
| Q-8 — L'exigence que les données restent au Québec est-elle une obligation légale ou contractuelle, ou une préférence de gestion ? | Aucune certification ou audit externe n'est exigé à ce stade. ; Les fournisseurs de paiement et de courriel retenus peuvent être vérifiés sans changement d'architecture. ; Domaine simple (.com ou.ca), certificat SSL géré automatiquement et gratuitement par l'hébergeur (ex. Let's Encrypt). ; Surveillance de base sans rétention étendue ni alerte avancée ; la localisation précise de ce service reste à confirmer pour que la résidence au Québec couvre aussi les journaux (Q-8). | P-13, P-15, D-2, D-16 | 11 445,00 CAD + 385,00 CAD de dépenses sur l'horizon |
| Q-1 — Le volume mensuel de commandes est-il mieux cerné que la fourchette de 100 à 1000, ou faut-il dimensionner sur l'hypothèse haute ? | Le client fournit les fiches produit dans un format simple à importer. ; Le volume de test de charge reste dans la fourchette de 100 à 1000 commandes/mois. ; Le volume réel de commandes au lancement reste proche de l'hypothèse retenue. ; Charge moyenne modeste, mise à l'échelle automatique pour les pics, une seule région Québec, pas de haute disponibilité multi-zone exigée. ; Environ 2000 à 3000 courriels/mois, service standard sans fonction avancée ; la résidence des données du fournisseur retenu reste à confirmer avec vous (Q-8). ; Panier moyen d'environ 90 CAD, à valider selon le prix réel des caisses ; fournisseur de paiement à taux standard, sans négociation de volume ; résidence du fournisseur au Québec ou au Canada à confirmer. | P-12, P-14, P-19, D-12, D-13, D-14 | 7 510,50 CAD + 37 740,00 CAD de dépenses sur l'horizon |
| Q-2 — Le client a-t-il une fourchette budgétaire, même approximative, pour ce projet ? | Pas d'exigence de double authentification ou de rôles multiples. ; Pas de personnalisation poussée des modèles de courriel. ; Pas de manuel utilisateur détaillé au-delà de la documentation opérationnelle. | P-4, P-9, P-16 | 6 240,00 CAD |
| Q-5 — Un service de paiement par carte est-il déjà choisi ou imposé, ou reste-t-il à sélectionner ? | Le fournisseur retenu propose une documentation et un SDK standards couvrant le remboursement. ; Le fournisseur de paiement et l'hébergeur retenus suivent ce modèle sans frais fixe d'ouverture ; leur résidence exacte reste à confirmer (Q-8). | P-10, D-1 | 5 291,00 CAD + 0,00 CAD de dépenses sur l'horizon |
| Q-10 — Quelle politique d'annulation et de remboursement souhaitez-vous appliquer (délai, remboursement intégral, frais retenus) ? | La politique d'annulation retenue par défaut est un remboursement intégral simple. | P-5 | 4 524,00 CAD |
| Q-13 — La brasserie fournit-elle elle-même les textes et photos des fiches produits, ou faut-il prévoir leur production dans le mandat ? | Le catalogue reste simple : un seul type de produit (caisses), sans variantes multiples. ; La brasserie fournit textes et photos pour un catalogue initial limité (environ 10 à 15 produits). | P-3, D-9 | 4 290,00 CAD + 0,00 CAD de dépenses sur l'horizon |
| Q-7 — La livraison est-elle assurée par un transporteur externe avec suivi, ou par le personnel de la brasserie avec mise à jour manuelle ? | Pas de notification en temps réel (push). | P-7 | 2 808,00 CAD |
| Q-6 — Comment l'âge doit-il être vérifié en ligne avant le paiement, et à la livraison lors de la remise, notamment si un transporteur externe est utilisé ? | Aucun service tiers de vérification d'identité ni transporteur externe n'est requis. ; Le client accepte une déclaration en ligne complétée d'un contrôle visuel à la remise par son personnel, sans transporteur externe. | P-6, D-15 | 1 560,00 CAD + 0,00 CAD de dépenses sur l'horizon |
| Q-11 — Quelles durées de conservation souhaitez-vous appliquer aux comptes clients, aux adresses et au journal des vérifications d'âge ? | Rétention de quelques semaines pour la base et les fichiers, sans exigence réglementaire de conservation prolongée ; restauration conjointe base+fichiers testée périodiquement. | D-17 | 300,00 CAD de dépenses sur l'horizon |
| Q-12 — Quelles règles de frais de livraison et de taxes doivent s'appliquer au panier (taux, zones, franco de port) ? | hypothèses des lignes concernées | aucune ligne chiffrée n'en dépend | aucune ligne chiffrée n'en dépend |
| Q-9 — Quel délai maximal est acceptable entre une vente au comptoir et son reflet dans le stock en ligne ? | hypothèses des lignes concernées | aucune ligne chiffrée n'en dépend | aucune ligne chiffrée n'en dépend |
| Hypothèses à confirmer sans question liée | Certificat SSL renouvelé automatiquement sans frais distinct. | D-3 | 24,00 CAD de dépenses sur l'horizon |

## État de la revue IA et réserves

État de la revue : résultat assisté par IA — proposition, revue critique par un second modèle et contrôles automatiques effectués ; aucune validation professionnelle.
La revue automatique a porté sur l'intégralité du périmètre présenté (23 éléments).

- **défaut démontré** (besoin E-6) : Les flux et le parcours stock-synchronise ne vont que de la caisse vers la boutique. Une caisse vendue en ligne n'est pas retirée du stock du comptoir, et le système qui fait foi pour le stock n'est pas désigné. — Le comptoir peut vendre une caisse déjà payée en ligne : on retombe dans la survente que le dossier veut éviter, mais dans l'autre sens. — modifié dans la révision : Le besoin, le service de synchronisation, le connecteur caisse et les flux d'architecture intègrent maintenant un sens boutique → caisse en plus du sens caisse → boutique, avec un flux dédié « répercussion vers la caisse ». Une nouvelle décision désigne explicitement le système qui doit faire foi pour le niveau de stock, à confirmer avec vous, et prévoit une réservation applicative de repli si la caisse ne peut recevoir aucun flux retour. Le poste de réconciliation de stock et le poste d'intégration caisse sont augmentés en conséquence, et la couverture de l'objectif de stock fiable passe à « à confirmer » avec une note explicite sur cette dépendance.
- **risque** (poste Logique de réconciliation du stock partagé) : Le poste suppose que les mouvements arrivent « au moins toutes les quelques minutes », mais l'hypothèse par défaut admet un export périodique. Aucun délai maximal de synchronisation n'est fixé. — Avec un export espacé, une caisse vendue au comptoir reste vendable en ligne entre deux synchronisations. — modifié dans la révision : Une question dédiée demande maintenant le délai maximal acceptable entre une vente au comptoir et son reflet en ligne. La décision sur la synchronisation bidirectionnelle intègre ce délai et prévoit une marge de sécurité si la caisse ne peut le garantir. Le risque correspondant (fenêtre de survente entre deux synchronisations) est ajouté à la liste des risques, et une contrainte d'architecture rappelle explicitement qu'aucun délai maximal n'est encore fixé.
- **défaut démontré** (couverture E-13) : La résidence au Québec est marquée « couverte », alors que : - l'hébergement vise « Canada (centre de données canadien) » ; - les services de paiement et de courriel peuvent traiter des données hors du Québec (risque déjà relevé dans la proposition) ; - le service de surveillance et de journaux n'est pas localisé. Pourtant, la résidence doit couvrir toute la chaîne, y compris les journaux et les services auxiliaires. — Des coordonnées ou des journaux pourraient être stockés hors du territoire exigé, alors que la couverture affichée laisse croire le contraire. — modifié dans la révision : La couverture de la résidence des données passe de « couverte » à « à confirmer », avec une note précisant que l'hébergement principal est couvert mais que les sauvegardes, les journaux/surveillance, le paiement et le courriel restent à vérifier fournisseur par fournisseur. La décision d'hébergement passe au statut « partiel » pour la même raison. Un nouveau composant d'architecture (surveillance et journalisation) est ajouté avec sa localisation marquée à confirmer, et le poste de mise en production inclut désormais un inventaire de la localisation de chaque service.
- **information manquante** (composant Service commandes) : Aucun parcours d'annulation ni de remboursement n'est prévu. Les statuts se limitent à créée, préparée, expédiée/remise, et le connecteur de paiement ne couvre que l'autorisation et la capture. Or un refus au contrôle d'âge à la remise, ou une survente, impose d'annuler une commande déjà payée. — Le personnel ne peut pas traiter un refus de remise dans l'outil, ce qui mène à des remboursements manuels hors système et à un suivi client incohérent. — modifié dans la révision : Une exigence d'annulation et de remboursement est ajoutée, couvrant le refus au contrôle d'âge à la remise et la survente détectée après paiement. Le service commandes gère désormais les statuts d'annulation/remboursement, le connecteur de paiement porte le flux de remboursement vers le fournisseur externe, le service de notifications ajoute un courriel d'annulation, et une nouvelle décision fixe l'hypothèse par défaut (remboursement intégral automatique, politique à confirmer avec vous). Les postes commandes, paiement et notifications sont chiffrés en conséquence, avec une question dédiée sur la politique souhaitée.
- **risque** (question Q-7) : Le contrôle d'âge à la remise repose sur la confirmation, dans l'interface interne, par le personnel de la brasserie. Si un transporteur externe livre, cette confirmation n'a plus d'acteur. Par ailleurs, le conseil juridique étant exclu, l'aptitude d'une simple déclaration de date de naissance à satisfaire la loi n'est pas établie. — L'exigence légale de contrôle à la remise peut rester sans mécanisme réel pour les livraisons. — modifié dans la révision : Une nouvelle décision traite spécifiquement le mécanisme de vérification d'âge à la remise selon le mode de livraison : par défaut, contrôle visuel par le personnel de la brasserie ; si un transporteur externe est retenu, le mécanisme devra être revu et validé avec votre propre conseil juridique, le conseil réglementaire restant hors mandat. La question sur la vérification d'âge est explicitement reliée à celle sur le transporteur, et l'exigence correspondante rappelle cette dépendance.
- **défaut démontré** (proposition) : Les frais de transaction (1 750 $/mois) reposent sur un panier moyen de 50 $, alors que la volumétrie retient 90 $. Aucune de ces deux valeurs n'a de source au dossier. — Le coût récurrent de paiement est incohérent entre les sections (environ 2 900 $/mois avec 90 $), et le client décide sur un chiffre non fondé. — modifié dans la révision : Une seule valeur de panier moyen est désormais retenue et utilisée de façon cohérente entre la volumétrie et les frais de transaction récurrents, présentée comme une hypothèse à confirmer avec vous (prix des caisses, composition type du panier). Le montant des frais de transaction est recalculé sur cette base unique plutôt que sur deux valeurs différentes.
- **défaut démontré** (décision Dimensionnement de l'hébergement sur la demande moyenne, pas sur un pic non mesuré) : La décision écarte le fait de « provisionner d'emblée pour 1000 commandes/mois ». Pourtant, l'hypothèse de volume, la volumétrie, l'infrastructure et les contraintes d'architecture retiennent justement 1 000 commandes par mois pour le dimensionnement. — On ne sait pas sur quelle base le coût récurrent de 220 $/mois est établi. — modifié dans la révision : La décision sur les coûts récurrents précise maintenant explicitement que le dimensionnement se fait sur la demande moyenne, avec un test de charge ponctuel simulant le plafond de 1000 commandes/mois plutôt qu'un provisionnement permanent à ce niveau. Cette même base (moyenne pour le récurrent, plafond pour le test) est désormais appliquée de façon cohérente à la volumétrie, à l'infrastructure et au chiffrage récurrent, pour éviter que le coût affiché ne repose sur une hypothèse implicite différente de celle citée ailleurs.
- **défaut démontré** (proposition) : Les exclusions indiquent que la brasserie fournit textes et photos, et que leur production n'est pas chiffrée. Or une dépense de 800 $ est prévue pour la photographie et la rédaction des fiches. — Le périmètre et le coût ponctuel se contredisent : l'engagement réel est ambigu. — modifié dans la révision : L'exclusion sur la fourniture des textes et photos devient une hypothèse explicite à confirmer avec vous (« la brasserie fournit le contenu »), assortie d'une question dédiée. La couverture correspondante passe à « à confirmer » plutôt qu'à une exclusion ferme. La dépense de production de contenu est alignée sur cette hypothèse : elle n'est retenue que comme option conditionnelle, à activer si vous confirmez que la brasserie ne produit pas elle-même ce contenu, ce qui lève la contradiction entre périmètre déclaré et dépense chiffrée.
- **défaut démontré** (poste Tests et recette) : Le poste de tests suppose des tests « majoritairement manuels », alors que les choix techniques prévoient une suite de tests automatisés sur le paiement, le stock et la vérification d'âge. Aucun poste n'en porte explicitement l'effort. — Les tests automatisés annoncés sur les zones à risque légal et financier peuvent ne pas être réalisés, ou ne pas être chiffrés. — modifié dans la révision : Le poste de tests distingue maintenant explicitement une sous-tâche d'automatisation ciblant les trois zones à risque légal et financier (paiement et remboursement, synchronisation de stock, vérification d'âge), avec des heures dédiées. La décision sur la sécurité applicative mentionne aussi ces tests automatisés comme partie de la vérification prévue, ce qui aligne les choix techniques annoncés et l'effort réellement chiffré.
- **défaut démontré** (décision Stockage objet pour les photos de produits plutôt que dans la base) : L'hébergement prévoit une réplication du stockage des fichiers seulement « si un stockage de fichiers est ajouté ». Or le stockage des photos est décidé et chiffré. La restauration conjointe de la base et des fichiers n'est pas prévue. — Une restauration de la base seule laisserait le catalogue sans images, ou avec des références orphelines. — modifié dans la révision : La décision sur le stockage objet des images retient désormais, de façon non conditionnelle, la sauvegarde du stockage de fichiers dès la mise en production, avec un test de restauration conjointe base de données et fichiers. Le poste de mise en production reprend explicitement cette tâche, et la décision sur la base relationnelle mentionne aussi une sauvegarde testée conjointement avec les fichiers, pour éviter le risque de catalogue sans images ou de références orphelines.
- **information manquante** (proposition) : Aucune durée de conservation ni règle de suppression n'est fixée pour les comptes, les adresses, les dates de naissance déclarées et le journal des vérifications d'âge. La date de naissance est une donnée personnelle absente du questionnaire d'ouverture. — Des renseignements personnels risquent d'être conservés sans limite, y compris dans les sauvegardes et les journaux. — modifié dans la révision : Une contrainte dédiée sur les durées de conservation est ajoutée, couvrant comptes, adresses, dates de naissance déclarées et journal des vérifications d'âge, y compris dans les sauvegardes et journaux. Une décision fixe l'hypothèse par défaut (conservation tant que le compte est actif, sans purge automatisée) à confirmer avec vous, et une question dédiée est posée. Les postes de cadrage, de conception et de documentation intègrent désormais ce travail de définition et de documentation par catégorie de données.
- **information manquante** (besoin E-5) : Le panier ne calcule qu'un total. Ni les frais de livraison à domicile ni les taxes applicables ne sont traités dans les postes ou les composants. — Le montant payé risque d'être incorrect, ou il faudra ajouter une fonction non chiffrée en cours de réalisation. — modifié dans la révision : L'exigence de choix du mode de remise précise maintenant explicitement que les frais de livraison à domicile et les taxes applicables ne sont pas encore traités dans le calcul du panier. La couverture correspondante passe à « partielle », et une question dédiée demande les règles de frais et de taxes à appliquer, avec l'hypothèse par défaut d'un total sans ces éléments en attendant votre confirmation.
- **risque** (proposition) : La surveillance (30 $), les sauvegardes (20 $) et le domaine (2 $ par mois, 25 $ à l'ouverture) figurent à la fois dans les dépenses et dans l'infrastructure. — Si les deux listes sont additionnées, le coût récurrent affiché est gonflé. — modifié dans la révision : Les rubriques d'infrastructure (surveillance, sauvegardes, domaine) sont désormais présentées comme le détail des dépenses récurrentes correspondantes plutôt que comme des montants distincts à additionner, avec une note explicite en ce sens, afin que le coût récurrent total affiché ne soit pas gonflé par un double comptage entre les deux sections.
- **information manquante** (proposition) : Le dossier liste « api » et « backup » comme approches refusées, mais S-1 ne contient aucune exclusion de ce genre. Ces mentions semblent venir d'une détection de mots-clés. La proposition emploie à juste titre des sauvegardes et une interface avec la caisse. — Si ces refus étaient réels, les sauvegardes et l'intégration de la caisse seraient remises en cause. — information manquante selon la révision : Le dossier qui nous a été transmis ne fait apparaître aucun champ listant des « approches refusées » de type API ou sauvegarde ; notre proposition n'exclut d'ailleurs ni l'un ni l'autre, puisqu'elle repose justement sur des sauvegardes et sur des connecteurs (API ou export) avec la caisse et le fournisseur de paiement. Nous ne pouvons donc pas confirmer nous-mêmes l'origine de cette mention ni la retirer d'un champ que nous ne voyons pas : il faudrait vérifier avec vous, dans le dossier source, si une telle exclusion existe réellement avant de la nettoyer.

---

Calcul n° 25, moteur 2.3 — chiffres du calcul retenu à la revue ; aucune valeur inventée lorsque tout est inconnu.