# Rapport client — Service d'expédition des commandes (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** : Service d'expédition des commandes (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

Construire un nouveau service interne qui orchestre la préparation des expéditions — réception des commandes payées, réservation en entrepôt, demande d'étiquette au transporteur et retour du numéro de suivi — pour réduire le travail manuel actuel, avec une résilience qui couvre toute la chaîne sortante, pas seulement la demande d'étiquette.

Dossier fictif d'exemple public. Une entreprise de vente en ligne automatise aujourd'hui manuellement la préparation de ses expéditions. Le service à construire n'a pas d'écran destiné au client final ; le choix du transporteur et la négociation tarifaire restent de la responsabilité de la direction, hors mandat. Le volume quotidien de commandes n'est pas connu, une croissance forte est annoncée sans chiffre vérifié, et le budget n'a pas été discuté au préalable. La revue a précisé que la reprise après incident (sauvegarde et restauration testées) fait partie du périmètre retenu, indépendamment de la reprise des demandes d'étiquette, et que la résilience doit aussi couvrir l'accusé de réception à la boutique et la libération d'une réservation en cas d'échec définitif de l'étiquette.

## Recommandation

Service d'orchestration d'expédition sur mesure, intégré à la boutique, à l'entrepôt et au transporteur — Construire un service back-office léger et sur mesure qui reçoit les commandes payées par API, accuse réception avant tout traitement différé, orchestre la réservation en entrepôt et la demande d'étiquette au transporteur avec une reprise idempotente sur toute la chaîne sortante (réservation, étiquette, retour de suivi), et offre un écran interne de suivi. La sauvegarde et la restauration testées font partie du périmètre retenu, indépendamment de la reprise des appels au transporteur. Les trois systèmes externes restent inchangés : on s'y intègre par leurs interfaces existantes plutôt que de les remplacer.

Aucun produit du marché ne couvre cette logique d'orchestration propre à l'entreprise (idempotence, reprise sur toute la chaîne sortante, écran interne). La valeur du mandat est la logique métier elle-même : elle doit être construite. Les trois échanges externes s'appuient sur les API déjà en place chez ces tiers : on intègre, on ne recrée pas ces systèmes. La revue a montré que la résilience ne pouvait pas se limiter à la seule demande d'étiquette : l'accusé de réception à la boutique et la libération de réservation après échec définitif entrent désormais dans le périmètre décrit. Proportionné à un volume encore inconnu et à un périmètre resserré (pas d'écran client, pas de choix de transporteur).

Conditions :
- Les API de la boutique en ligne, de l'entrepôt et du transporteur existent et sont accessibles au moment de la réalisation.
- Le personnel de l'entrepôt est identifié comme utilisateur de l'écran de suivi et dispose d'un accès réseau à l'application.
- La sauvegarde et la restauration testées font partie du périmètre retenu ; la suppression après trois ans couvre aussi les sauvegardes, les journaux et les étiquettes stockées, avec une fenêtre de sauvegarde technique distincte de la conservation métier de trois ans.
- Le volume de commandes reste dans une fourchette modérée au démarrage, avec une capacité à ajuster l'infrastructure si la croissance annoncée se confirme.

## Périmètre inclus

| Code | Nature | Élément | État |
|---|---|---|---|
| E-1 | Objectif | Automatiser la préparation des expéditions pour réduire le travail manuel | à confirmer |
| E-2 | Exigence | Réception des commandes payées depuis la boutique en ligne par API | à confirmer |
| E-3 | Exigence | Accusé de réception de la commande avant traitement différé | à confirmer |
| E-4 | Exigence | Réservation des articles commandés dans l'entrepôt | à confirmer |
| E-5 | Exigence | Libération de la réservation après échec définitif de l'étiquette | à confirmer |
| E-6 | Exigence | Demande d'étiquette d'expédition au transporteur | à confirmer |
| E-7 | Exigence | Reprise automatique des demandes d'étiquette échouées sans doublon d'expédition | à confirmer |
| E-8 | Exigence | Retour du numéro de suivi à la boutique en ligne | à confirmer |
| E-9 | Exigence | Traitement idempotent d'une commande transmise deux fois par la boutique | à confirmer |
| E-10 | Exigence | Écran de suivi interne pour le personnel de l'entrepôt | à confirmer |
| E-11 | Exigence | Tableaux de bord et rapports sur les expéditions | à confirmer |
| E-12 | Exigence | Conservation des commandes traitées trois ans puis suppression complète | à confirmer |
| E-13 | Contrainte | Trois intégrations externes obligatoires : boutique en ligne, entrepôt, transporteur | à confirmer |
| E-17 | Hypothèse | Volume quotidien de commandes inconnu ; croissance annoncée non chiffrée | à confirmer |
| E-18 | Hypothèse | Budget non discuté au préalable | à confirmer |
| E-19 | Hypothèse | Données traitées limitées à des coordonnées et identifiants clients | à confirmer |
| E-20 | Hypothèse | Les trois systèmes tiers exposent des API exploitables pour l'intégration | à confirmer |
| E-21 | Hypothèse | Sauvegarde et restauration testées retenues comme acquises | à confirmer |
| E-22 | Hypothèse | Usage de l'étiquette après son obtention à confirmer | à confirmer |
| E-23 | Hypothèse | Niveau ASVS 1 retenu comme base de la revue de sécurité applicative | à confirmer |

E-14 figure à la section « Exclusions ».
E-15 figure à la section « Exclusions ».
E-16 figure à la section « Exclusions ».

## Exclusions

- E-14 : Choix du transporteur et négociation des tarifs hors mandat
- E-15 : Aucun écran ou portail destiné au client final
- E-16 : Aucune notification par courriel dans ce périmètre

- Ne couvre pas le choix du transporteur ni la négociation tarifaire, hors mandat ; le nombre de transporteurs à intégrer dès le démarrage reste à confirmer avec vous (hypothèse : un seul).
- Aucun écran ni notification destinés au client final ; aucune notification par courriel n'est incluse tant qu'elle n'est pas demandée.
- Suppose que les trois systèmes tiers exposent des API exploitables, y compris un moyen d'éviter un doublon d'étiquette après un délai dépassé côté transporteur ; sans confirmation, l'effort d'intégration est une hypothèse.
- L'usage de l'étiquette après son obtention (impression, téléchargement, transmission à l'entrepôt) reste à confirmer avec vous.
- Ne prévoit pas de portail multi-entreprise ni de gestion de plusieurs boutiques en l'absence d'indication en ce sens.
- Le dimensionnement repose sur un volume hypothétique tant que le volume réel n'est pas fourni.

## Principales hypothèses

- Deux à trois ateliers suffisent avec un seul interlocuteur métier disponible.
- Aucune adaptation majeure (fichier plat, portail manuel) n'est nécessaire chez les tiers.
- Authentification par jeton simple, sans certificat mutuel.
- Une seule opération de réservation par commande ; la libération annule simplement la réservation existante.
- Un seul transporteur intégré au démarrage, désigné par la direction (voir question dédiée).
- Une file en base de données suffit au volume attendu, sans courtier de messages dédié.
- Aucune compensation complexe au-delà de la libération de réservation décrite.
- PostgreSQL ou équivalent transactionnel, sans besoin de stockage spécialisé.
- Suppression physique simple, sans anonymisation intermédiaire ni archivage séparé.
- Téléchargement depuis l'écran de suivi retenu comme hypothèse par défaut.
- Fenêtre de restauration de quelques heures, perte de données tolérée d'au plus une journée.
- Un seul rôle d'accès (personnel entrepôt), sans gestion fine de permissions.
- Aucune exigence d'accessibilité ou de prise en charge multilingue avancée.
- Trois à cinq indicateurs agrégés suffisent pour une première version.
- Authentification par jeton/clé API standard sur les trois intégrations, sans certificats mutuels.
- Des environnements de test (bac à sable) sont disponibles chez les trois systèmes tiers.
- Hébergement infonuagique géré, un seul environnement de production avec un environnement de test réduit.
- Un seul document par volet, sans révision multiple approfondie.
- Une seule session de formation pour un petit groupe d'utilisateurs de l'entrepôt.
- Un seul chargé de projet suffit, sans comité de gouvernance élargi.
- Coordination estimée à environ 12 % du reste des heures de réalisation.
- Une période de stabilisation de deux à trois semaines suffit avec un volume de commandes modéré.

## Architecture proposée

Construire un service back-office léger et sur mesure qui reçoit les commandes payées par API, accuse réception avant tout traitement différé, orchestre la réservation en entrepôt et la demande d'étiquette au transporteur avec une reprise idempotente sur toute la chaîne sortante (réservation, étiquette, retour de suivi), et offre un écran interne de suivi. La sauvegarde et la restauration testées font partie du périmètre retenu, indépendamment de la reprise des appels au transporteur. Les trois systèmes externes restent inchangés : on s'y intègre par leurs interfaces existantes plutôt que de les remplacer.

**Acteurs**

- Personnel de l'entrepôt (personnel) — Employé qui suit l'état des commandes à préparer et à expédier depuis l'écran interne.
- Boutique en ligne (système existant) (système externe) — Système de vente en ligne qui transmet les commandes payées et reçoit un accusé de réception puis le numéro de suivi.
- Système d'entrepôt (existant) (système externe) — Système qui gère les stocks et confirme, refuse ou libère la réservation des articles commandés.
- Système du transporteur (existant) (système externe) — Système externe qui émet les étiquettes d'expédition et les numéros de suivi, parfois indisponible.

**Composants**

- API de réception des commandes (Intégration) — Reçoit chaque commande payée de la boutique, vérifie sa clé d'idempotence en base, accuse réception immédiatement puis met la commande en file pour un traitement différé (réservation, étiquette, retour de suivi).
- File durable des traitements sortants (Infrastructure) — Porte chaque étape sortante (réservation entrepôt, demande d'étiquette, retour de suivi) avec reprise automatique et idempotente en cas d'échec transitoire, sans dupliquer une expédition ni perdre un envoi.
- Orchestrateur d'expédition (Service) — Coordonne le cycle de vie de l'expédition depuis la file : réservation, demande d'étiquette, libération de réservation en cas d'échec définitif, retour de suivi ; tient l'état de la commande sans jamais dupliquer une expédition.
- Connecteur système d'entrepôt (Intégration) — Traduit vers l'API de l'entrepôt les demandes de réservation et, après un échec définitif de l'étiquette, les demandes de libération des articles réservés.
- Connecteur système du transporteur (Intégration) — Demande une étiquette au transporteur, reçoit le numéro de suivi, et vérifie l'existence d'une expédition avant toute nouvelle tentative pour éviter un doublon si un délai a été dépassé alors que l'étiquette existait déjà (hypothèse à confirmer avec vous selon les capacités réelles du transporteur).
- Base de données des commandes et expéditions (Données) — Stocke l'état de chaque commande et expédition, les clés d'idempotence et l'historique des statuts ; applique la conservation de trois ans, distincte de la fenêtre technique de sauvegarde.
- Stockage des étiquettes d'expédition (Données) — Conserve le fichier d'étiquette obtenu du transporteur, associé à la commande, pour un usage au poste d'emballage encore à confirmer (impression, téléchargement ou transmission à l'entrepôt) ; couvert par la même conservation de trois ans.
- Service de sauvegarde et restauration (Infrastructure) — Sauvegarde régulièrement la base et le stockage des étiquettes, avec restauration testée, sur une fenêtre technique courte indépendante de la conservation métier de trois ans, retenue comme acquise pour l'exigence de reprise après incident.
- Journalisation et supervision (Infrastructure) — Centralise les journaux d'étapes, d'erreurs et de tentatives pour le diagnostic et la surveillance, sans y écrire de coordonnées client en clair, avec une rétention courte propre.
- Tâche planifiée de purge des commandes (Service) — Supprime automatiquement, à échéance des trois ans, les commandes en base et les étiquettes stockées associées ; les sauvegardes et journaux ne survivent pas au-delà grâce à leur propre fenêtre courte.
- Écran de suivi interne et tableaux de bord (Interface) — Présente au personnel de l'entrepôt la liste des commandes (en attente, expédiées, en erreur), des indicateurs agrégés, et si confirmé, le téléchargement de l'étiquette associée.
- Boutique en ligne (système existant) (Externe) — Transmet les commandes payées, reçoit un accusé de réception immédiat puis le numéro de suivi ; système existant, non modifié par ce mandat.
- Système d'entrepôt (existant) (Externe) — Confirme ou refuse la réservation des articles, et traite les demandes de libération ; système existant, non modifié par ce mandat.
- Système du transporteur (existant) (Externe) — Émet les étiquettes d'expédition et les numéros de suivi ; parfois indisponible ; système existant, non modifié par ce mandat.

**Flux**

- (1) Boutique en ligne (système existant) → API de réception des commandes (appel) : Transmission d'une commande payée avec ses articles et les coordonnées du client
- (2) API de réception des commandes → Base de données des commandes et expéditions (appel) : Vérification de la clé d'idempotence pour détecter une commande déjà reçue
- (3) API de réception des commandes → Boutique en ligne (système existant) (appel) : Accusé de réception immédiat de la commande valide, avant tout traitement différé
- (4) API de réception des commandes → File durable des traitements sortants (événement) : Mise en file de la commande acceptée pour traitement différé (réservation, étiquette, retour de suivi)
- (5) File durable des traitements sortants → Orchestrateur d'expédition (traitement planifié) : Traitement différé et reprise idempotente de chaque étape sortante en échec transitoire
- (6) Orchestrateur d'expédition → Base de données des commandes et expéditions (appel) : Création et mise à jour de l'état de la commande et de l'expédition
- (7) Orchestrateur d'expédition → Connecteur système d'entrepôt (appel) : Demande de réservation des articles commandés
- (8) Connecteur système d'entrepôt → Système d'entrepôt (existant) (appel) : Réservation des articles dans l'entrepôt
- (9) Orchestrateur d'expédition → Connecteur système du transporteur (appel) : Demande d'étiquette d'expédition pour la commande réservée
- (10) Connecteur système du transporteur → Système du transporteur (existant) (appel) : Demande d'étiquette, avec vérification préalable de l'existence d'une expédition avant toute nouvelle tentative
- (11) Connecteur système du transporteur → File durable des traitements sortants (événement) : Remise en file d'une demande d'étiquette en échec transitoire pour nouvelle tentative
- (12) Orchestrateur d'expédition → Connecteur système d'entrepôt (appel) : Libération de la réservation après échec définitif et non récupérable de la demande d'étiquette
- (13) Connecteur système d'entrepôt → Système d'entrepôt (existant) (appel) : Libération des articles précédemment réservés
- (14) Connecteur système du transporteur → Stockage des étiquettes d'expédition (fichier) : Dépôt du fichier d'étiquette obtenu, associé à la commande
- (15) Orchestrateur d'expédition → Boutique en ligne (système existant) (appel) : Retour du numéro de suivi une fois l'étiquette obtenue, avec reprise en cas d'indisponibilité temporaire de la boutique
- (16) Écran de suivi interne et tableaux de bord → Base de données des commandes et expéditions (appel) : Lecture des commandes par statut et des indicateurs agrégés
- (17) Écran de suivi interne et tableaux de bord → Stockage des étiquettes d'expédition (appel) : Téléchargement de l'étiquette associée à une commande (usage à confirmer avec vous)
- (18) Tâche planifiée de purge des commandes → Base de données des commandes et expéditions (traitement planifié) : Suppression des commandes et de leur historique dont la conservation de trois ans est échue
- (19) Tâche planifiée de purge des commandes → Stockage des étiquettes d'expédition (traitement planifié) : Suppression des étiquettes associées aux commandes dont la conservation est échue
- (20) Service de sauvegarde et restauration → Base de données des commandes et expéditions (traitement planifié) : Sauvegarde régulière et restauration testée, sur une fenêtre technique courte distincte de la conservation métier
- (21) Service de sauvegarde et restauration → Stockage des étiquettes d'expédition (traitement planifié) : Sauvegarde du stockage des étiquettes, sur la même fenêtre technique courte
- (22) Orchestrateur d'expédition → Journalisation et supervision (événement) : Journalisation des étapes, erreurs et tentatives, sans coordonnées client en clair

**Parcours utilisateurs**

- Expédier automatiquement une commande payée (Boutique en ligne (système existant)) — 1. Boutique en ligne (système existant) → API de réception des commandes : transmet la commande payée ; 2. API de réception des commandes → Base de données des commandes et expéditions : vérifie que la commande n'a pas déjà été reçue ; 3. API de réception des commandes → Boutique en ligne (système existant) : accuse réception de la commande ; 4. API de réception des commandes → File durable des traitements sortants : met la commande en file pour traitement ; 5. File durable des traitements sortants → Orchestrateur d'expédition : déclenche le traitement de la commande ; 6. Orchestrateur d'expédition → Connecteur système d'entrepôt : demande la réservation des articles ; 7. Connecteur système d'entrepôt → Système d'entrepôt (existant) : réserve les articles commandés ; 8. Orchestrateur d'expédition → Connecteur système du transporteur : demande une étiquette d'expédition ; 9. Connecteur système du transporteur → Système du transporteur (existant) : obtient l'étiquette et le numéro de suivi ; 10. Orchestrateur d'expédition → Boutique en ligne (système existant) : renvoie le numéro de suivi
- Reprendre une demande d'étiquette après un échec temporaire du transporteur (Système du transporteur (existant)) — 1. Orchestrateur d'expédition → Connecteur système du transporteur : demande une étiquette d'expédition ; 2. Connecteur système du transporteur → Système du transporteur (existant) : transmet la demande d'étiquette ; 3. Système du transporteur (existant) → Connecteur système du transporteur : signale une indisponibilité temporaire ; 4. Connecteur système du transporteur → File durable des traitements sortants : remet la demande en file pour une nouvelle tentative ; 5. File durable des traitements sortants → Connecteur système du transporteur : déclenche la nouvelle tentative ; 6. Connecteur système du transporteur → Système du transporteur (existant) : vérifie qu'aucune étiquette n'a déjà été créée avant de redemander ; 7. Connecteur système du transporteur → Stockage des étiquettes d'expédition : dépose le fichier d'étiquette obtenu, sans doublon ; 8. Orchestrateur d'expédition → Boutique en ligne (système existant) : renvoie le numéro de suivi
- Libérer les articles réservés après un échec définitif de l'étiquette (Système du transporteur (existant)) — 1. Système du transporteur (existant) → Connecteur système du transporteur : signale un nouvel échec de la demande d'étiquette ; 2. Connecteur système du transporteur → File durable des traitements sortants : enregistre l'échec après épuisement des tentatives prévues ; 3. File durable des traitements sortants → Orchestrateur d'expédition : signale l'échec définitif de la demande d'étiquette ; 4. Orchestrateur d'expédition → Connecteur système d'entrepôt : demande la libération de la réservation ; 5. Connecteur système d'entrepôt → Système d'entrepôt (existant) : libère les articles précédemment réservés ; 6. Orchestrateur d'expédition → Base de données des commandes et expéditions : marque la commande comme en erreur
- Suivre l'état des commandes et récupérer une étiquette depuis l'entrepôt (Personnel de l'entrepôt) — 1. Personnel de l'entrepôt → Écran de suivi interne et tableaux de bord : ouvre l'écran de suivi ; 2. Écran de suivi interne et tableaux de bord → Base de données des commandes et expéditions : demande la liste des commandes et les indicateurs ; 3. Base de données des commandes et expéditions → Écran de suivi interne et tableaux de bord : renvoie les états et les indicateurs ; 4. Écran de suivi interne et tableaux de bord → Personnel de l'entrepôt : affiche les commandes en attente, expédiées et en erreur ; 5. Personnel de l'entrepôt → Écran de suivi interne et tableaux de bord : consulte le détail d'une commande en erreur ; 6. Personnel de l'entrepôt → Écran de suivi interne et tableaux de bord : demande le téléchargement de l'étiquette d'une commande expédiée ; 7. Écran de suivi interne et tableaux de bord → Stockage des étiquettes d'expédition : récupère le fichier d'étiquette associé ; 8. Stockage des étiquettes d'expédition → Écran de suivi interne et tableaux de bord : renvoie le fichier pour téléchargement (usage à confirmer avec vous)

**Intégrations**

- Intégration entrante boutique en ligne : Recevoir chaque commande payée, en accuser réception immédiatement, puis renvoyer le numéro de suivi avec reprise en cas d'indisponibilité de la boutique.
- Intégration système d'entrepôt : Réserver les articles commandés et libérer la réservation en cas d'échec définitif de l'étiquette.
- Intégration système du transporteur : Demander une étiquette et un numéro de suivi, reprendre automatiquement les échecs transitoires, et vérifier l'existence d'une expédition avant chaque nouvelle tentative.

**Contraintes**

- Les trois systèmes externes restent inchangés ; le service s'y intègre sans les remplacer ni dupliquer leurs données maîtresses.
- Toute étape sortante (réservation, demande d'étiquette, retour de suivi) passe par la file durable avec reprise idempotente ; aucune répétition ne doit produire deux expéditions ni perdre un numéro de suivi.
- Un échec définitif et non récupérable de la demande d'étiquette libère la réservation correspondante en entrepôt.
- La conservation métier de trois ans s'applique aux commandes, aux étiquettes stockées et à leurs sauvegardes ; la fenêtre de sauvegarde technique reste courte et distincte de cette conservation.
- La journalisation applicative évite toute coordonnée client en clair et suit une rétention courte propre.
- La vérification d'existence d'une expédition avant nouvelle tentative auprès du transporteur reste une hypothèse tant que sa capacité d'idempotence n'est pas confirmée.
- Le dimensionnement de l'infrastructure part d'un volume de commandes hypothétique et modéré, faute de chiffre confirmé par le client.
- Le choix du ou des transporteurs et la négociation tarifaire restent hors architecture ; chaque transporteur additionnel dès le départ requiert un connecteur propre.
- L'API de réception des commandes n'accepte que des appels authentifiés de la boutique en ligne et vérifie l'idempotence avant d'accuser réception ; aucun accès anonyme.
- L'écran de suivi et les tableaux de bord sont réservés au personnel authentifié de l'entrepôt ; aucune interface ni notification par courriel n'est prévue pour le client final.
- Les connecteurs vers l'entrepôt et le transporteur utilisent des identifiants propres à chaque système tiers, distincts des comptes internes ; un connecteur distinct est prévu par transporteur additionnel.
- La base de données des commandes et expéditions n'est accessible qu'aux composants internes du service, jamais directement de l'extérieur.
- Le stockage des étiquettes n'est accessible qu'aux composants internes et, en lecture, au personnel authentifié via l'écran de suivi, par lien à durée limitée si le téléchargement est confirmé.
- Aucune donnée de paiement n'est reçue ni stockée ; seules les coordonnées nécessaires à l'expédition transitent et sont conservées.
- La journalisation ne conserve pas les coordonnées client en clair et suit sa propre fenêtre de rétention courte, indépendante de la conservation métier de trois ans.

## 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 (exécution serveur) (hypothèse) — Écosystème mature pour API REST et connecteurs HTTP vers trois systèmes tiers ; bon support de traitements asynchrones pour la file de traitements sortants, dont le périmètre couvre désormais l'accusé de réception, la réservation, l'étiquette et le retour de suivi. Hypothèse de chiffrage, proportionnée à une équipe unique et à un monolithe modulaire. · Écarté : Python ; .NET / C# ; Java
- Cadriciel applicatif : Cadriciel web modulaire orienté API et injection de dépendances (ex. NestJS) (hypothèse) — Structure en modules alignée sur l'orchestrateur, les connecteurs (boutique, entrepôt, transporteur), la file durable élargie et l'écran de suivi du monolithe modulaire retenu ; frontières claires sans exiger plusieurs équipes. · Écarté : Cadriciel Python (ex. FastAPI ou Django) ; ASP.NET Core ; Spring Boot
- Interface utilisateur : Application web interne monopage pour l'écran de suivi et les tableaux de bord (ex. React) (hypothèse) — Un seul écran interne réservé au personnel de l'entrepôt, sans portail public ; suffit pour lister les commandes par statut, présenter les indicateurs agrégés et, si confirmé, permettre le téléchargement de l'étiquette. · Écarté : Rendu côté serveur classique ; Vue.js ; Intégration à un outil de tableau de bord existant du client
- Base de données : Base de données relationnelle gérée (PostgreSQL) (hypothèse) — Modèle transactionnel (commandes, statuts, clés d'idempotence sur chaque étape sortante), volumes bornés et rapports attendus : stockage relationnel classique avec sauvegarde et restauration éprouvées. · Écarté : Base NoSQL orientée documents ; Autre moteur relationnel géré (ex. MySQL)
- Stockage de fichiers : Stockage objet compatible S3 pour les étiquettes d'expédition (à confirmer) — Utile si le fichier d'étiquette doit être téléchargeable depuis l'écran de suivi ou transmis à l'entrepôt ; dépend directement de la réponse attendue sur l'usage de l'étiquette après son obtention. Couvert par la même conservation de trois ans et la même fenêtre de sauvegarde technique que la base. · Écarté : Conservation de l'étiquette en base si le fichier est très petit ; Aucun stockage si seul le numéro de suivi est conservé
- File de tâches de fond : File de tâches adossée à la base de données pour l'ensemble des traitements sortants (accusé de réception, réservation, étiquette, retour de suivi) (hypothèse) — Le périmètre de la file s'est élargi à toute la chaîne sortante, plus seulement la reprise transporteur ; volume de commandes encore inconnu, donc une file en base suffit au démarrage sans exploitation supplémentaire, migrable vers un courtier dédié si le volume confirmé ou la vérification préalable d'idempotence auprès du transporteur (question Q-7) alourdissent le débit. · Écarté : Courtier de messages dédié ; Planificateur de tâches simple sans file dédiée
- Authentification : Authentification par jeton (clé API) pour les appels entrants et sortants ; accès du personnel de l'entrepôt via un fournisseur d'identité (à confirmer) — Aucun mécanisme n'est précisé dans le dossier ; le jeton est standard pour des intégrations système à système, et un fournisseur d'identité évite de gérer des mots de passe pour l'écran interne. Dépend de la réponse attendue sur le mécanisme exact par intégration (question Q-4). · Écarté : Authentification mutuelle par certificat (mTLS) ; Réseau privé virtuel dédié par intégration ; Compte applicatif interne sans fournisseur d'identité externe
- Observabilité : Journalisation centralisée et indicateurs de santé applicatifs, sans coordonnées client en clair (hypothèse) — La disponibilité exigée et l'élargissement de la reprise à toute la chaîne sortante imposent de détecter rapidement les échecs de réservation, d'étiquette ou de retour de suivi ; les journaux excluent les coordonnées de clients pour ne pas contredire la purge à trois ans, avec une rétention propre et courte. · Écarté : Journalisation locale minimale sans agrégation centralisée ; Outil d'observabilité auto-hébergé
- Intégration continue : Chaîne d'intégration et de déploiement continue (ex. GitHub Actions ou équivalent) (hypothèse) — Service déployé d'un bloc (monolithe modulaire) ; une chaîne automatisée limite les erreurs de déploiement manuel et soutient l'excellence opérationnelle attendue pour ce dossier. · Écarté : Déploiement manuel scripté ; Autre chaîne d'intégration continue (ex. GitLab CI, Azure DevOps)
- Tests : Tests automatisés unitaires et d'intégration couvrant l'idempotence sur toute la chaîne sortante et une revue de sécurité de base au niveau ASVS 1 (hypothèse) — Les scénarios critiques (commande dupliquée, échec transporteur avec vérification préalable, libération de réservation) exigent des tests reproductibles ; le niveau 1 de l'ASVS 5.0.0 est retenu comme hypothèse de référentiel pour une revue de sécurité applicative, compte tenu des coordonnées de clients traitées. · Écarté : Tests manuels uniquement ; Tests de contrat automatisés avec chaque système tiers, si un environnement de test tiers est disponible ; Niveau ASVS supérieur si exigé par vous

**Hébergement**

- Modèle d'hébergement : Infonuagique gérée (plateforme) (hypothèse)
- Catégorie de fournisseur : Fournisseur d'infonuagique public généraliste offrant calcul applicatif géré, base de données relationnelle gérée, stockage objet et file de messages gérée
- Conservation des données : Amérique du Nord (Canada ou États-Unis)
- Sauvegardes et rétention : Sauvegarde régulière de la base et réplique du stockage des étiquettes, retenues comme principe indépendant de la reprise des demandes d'étiquette (exigence de reprise après incident déclarée indispensable). La fenêtre technique de rétention des sauvegardes reste courte et distincte de la conservation métier de trois ans, pour ne pas faire survivre des coordonnées de clients au-delà de l'échéance de purge. Cadence exacte et durée de rétention technique à confirmer.
- Reprise après incident : Reprise automatique et idempotente sur toute la chaîne sortante (réservation, demande d'étiquette, retour de suivi), avec limite de tentatives et file de rebut ; vérification de l'existence d'une expédition avant chaque nouvelle tentative auprès du transporteur (hypothèse, à confirmer selon ses capacités). Restauration testée de la base et du stockage des étiquettes à un point dans le temps. Cibles de délai d'interruption maximal et de perte de données tolérée non chiffrées par le dossier, à établir avec vous.
- Environnements : Développement · Test et recette (incluant l'accès sandbox aux API de la boutique, de l'entrepôt et du transporteur) · Production

- Aucun outil de programmation ni fournisseur d'hébergement n'est arrêté dans le dossier : l'ensemble de la pile technique est une hypothèse de chiffrage, pas un engagement contractuel.
- Les couches paiement, courriel/notifications et recherche ne sont pas retenues : aucune donnée de paiement n'est traitée, aucune notification par courriel n'est demandée et aucune fonction de recherche n'est décrite dans le dossier.
- Le périmètre de la file de traitements différés s'est élargi à toutes les étapes sortantes (accusé de réception, réservation, étiquette, retour de suivi) ; le choix entre file en base et courtier dédié dépend du volume réel, encore inconnu.
- La sauvegarde et la restauration testées sont retenues comme principe, indépendamment de la reprise des appels au transporteur ; leur cadence et leur fenêtre technique restent à confirmer avec vous, et doivent rester plus courtes que la conservation métier de trois ans.
- Aucune exigence de résidence n'est déclarée pour les coordonnées de clients ; l'hébergement en Amérique du Nord est une hypothèse à confirmer, notamment au regard des obligations applicables.
- Le stockage objet des étiquettes dépend de la réponse sur l'usage de l'étiquette après son obtention ; il reste à confirmer plutôt que retenu.
- Le niveau 1 de l'ASVS 5.0.0 est retenu comme hypothèse de référentiel pour les tests et la revue de sécurité applicative, compte tenu des coordonnées de clients traitées ; à confirmer avec vous avant la mise en production.
- La journalisation centralisée exclut les coordonnées de clients en clair et suit sa propre rétention courte, indépendante de la conservation métier de trois ans, pour ne pas contredire la purge.

## 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 — Portail interne**

- Écran 1 — Connexion (Authentification) — Authentifier le personnel de l'entrepôt avant l'accès au portail de suivi des expéditions. · Éléments cadrés servis : E-23
- Écran 2 — Suivi des commandes (Liste) — Lister les commandes en attente, expédiées ou en erreur avec filtres, pour repérer rapidement celles nécessitant une action. · Éléments cadrés servis : E-10, E-4, E-9
- Écran 3 — Détail de la commande (Détail) — Afficher les informations d'une commande, l'historique des tentatives d'étiquette et permettre une relance manuelle en cas d'erreur. · Éléments cadrés servis : E-10, E-6, E-7, E-5, E-8, E-9
- Écran 4 — Tableau de bord des expéditions (Tableau de bord) — Présenter les indicateurs et rapports globaux sur l'activité d'expédition pour le pilotage courant. · Éléments cadrés servis : E-11

## 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) | 253,85 h | 412,2 h | 759,3 h |
| Enveloppe de services | 35 562,50 CAD | 57 480,50 CAD | 105 386,75 CAD |
| Coût total client sur l'horizon | 44 578,50 CAD | 66 496,50 CAD | 114 402,75 CAD |
| Dont frais proportionnels à l'activité (D-16) | 0,00 CAD | 0,00 CAD | 0,00 CAD |
| Coût du projet hors frais proportionnels à l'activité | 44 578,50 CAD | 66 496,50 CAD | 114 402,75 CAD |

- **Dépenses initiales** : 3 700,00 CAD
- **Récurrent mensuel indicatif** : 443,00 CAD
- **Récurrent sur l'horizon** : 5 316,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** : 76 470,98 CAD (scénario central plus une provision pour imprévus de 9 974,48 CAD, soit 15 %)
- 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 : 90 845,00 CAD d'enveloppe de services et 22 semaines.**
- **34 % du budget (22 328,50 CAD sur 66 496,50 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) | 44 578,50 CAD | 66 496,50 CAD | 114 402,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 |
| 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 | 486 h | 253,85 h |
| Centrale | 664 h | 412,2 h |
| Haute | 963 h | 759,3 h |

- 5 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, 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 90 845,00 CAD au lieu de 57 480,50 CAD, et le délai de 22 semaines au lieu de 16 (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 fonctionnel détaillé et spécification des règles métier | Analyse, cadrage, conception | 20 / 30 / 50 h | 0,70 / 0,80 / 0,95 | 14 h | 24 h | 47,5 h | dépend de Q-6 | Scénario de réalisation type pour un cadrage de service back-office à trois intégrations et règles d'idempotence et de compensation explicites. |
| P-2 | Conception technique de l'architecture d'orchestration | Analyse, cadrage, conception | 28 / 42 / 70 h | 0,70 / 0,80 / 0,95 | 19,6 h | 33,6 h | 66,5 h | dépend de Q-2 | Scénario de conception élargi pour trois intégrations, une file couvrant toute la chaîne sortante, un stockage d'étiquettes et une sauvegarde testée, faute de confirmation des API tierces. |
| P-3 | Intégration entrante — réception des commandes, accusé de réception et retour de suivi | Intégration avec l'existant et les tiers | 28 / 36 / 50 h | 0,65 / 0,80 / 1,00 | 18,2 h | 28,8 h | 50 h | — | Décomposition : endpoint (6h), validation (4h), idempotence et accusé de réception (8h), mise en file (4h), retour de suivi avec reprise (6h), tests (8h) = 36h. |
| P-4 | Intégration — réservation et libération des articles en entrepôt | Intégration avec l'existant et les tiers | 23 / 30 / 40 h | 0,65 / 0,80 / 1,00 | 14,95 h | 24 h | 40 h | — | Décomposition : appel réservation (8h), gestion des échecs (6h), libération sur échec définitif (5h), mapping articles (5h), tests (6h) = 30h. |
| P-5 | Intégration — demande d'étiquette, suivi et vérification anti-doublon | Intégration avec l'existant et les tiers | 40 / 52 / 72 h | 0,65 / 0,80 / 1,00 | 26 h | 41,6 h | 72 h | — | Décomposition : appel étiquette (8h), traitement suivi (6h), détection échec transitoire/définitif (6h), vérification d'existence avant retry (8h), branchement file durable (6h), tests non-duplication (10h), tests bout en bout (8h) = 52h. |
| P-6 | File durable de traitements différés pour toute la chaîne sortante | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 29 / 38 / 52 h | 0,30 / 0,40 / 0,60 | 8,7 h | 15,2 h | 31,2 h | — | Décomposition : file en base (6h), politique de reprise bornée par type de tâche (8h), gestion de plusieurs types de tâches sortantes (6h), file de rebut (6h), supervision (4h), tests (8h) = 38h. |
| P-7 | Orchestrateur d'expédition — états, compensation et coordination via la file | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 34 / 44 / 62 h | 0,30 / 0,40 / 0,60 | 10,2 h | 17,6 h | 37,2 h | — | Décomposition : machine d'états (10h), idempotence globale (8h), coordination via file (8h), gestion erreurs et libération (10h), tests unitaires (8h) = 44h. |
| P-8 | Modèle de données des commandes, expéditions et métadonnées d'étiquettes | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 19 / 25 / 36 h | 0,30 / 0,40 / 0,60 | 5,7 h | 10 h | 21,6 h | — | Décomposition : schéma (6h), index idempotence (4h), historique statuts (4h), métadonnées étiquettes (3h), migrations (4h), tests (4h) = 25h. |
| P-9 | Tâche planifiée de purge des commandes et des étiquettes après trois ans | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 15 / 20 / 28 h | 0,30 / 0,40 / 0,60 | 4,5 h | 8 h | 16,8 h | — | Décomposition : job planifié (4h), règles de sélection (4h), suppression des étiquettes stockées (4h), journalisation (3h), tests (5h) = 20h. |
| P-10 | Stockage des fichiers d'étiquettes d'expédition | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 14 / 22 / 35 h | 0,30 / 0,40 / 0,60 | 4,2 h | 8,8 h | 21 h | dépend de Q-9 | Scénario de réalisation type pour un stockage de fichiers avec lien protégé, élargi faute de confirmation de l'usage réel de l'étiquette. |
| P-11 | Sauvegarde, restauration testée et journalisation à rétention courte | Infrastructure et déploiement | 18 / 24 / 34 h | 0,50 / 0,65 / 0,85 | 9 h | 15,6 h | 28,9 h | — | Décomposition : configuration sauvegarde base et étiquettes (6h), exercice de restauration testée (6h), rétention courte des journaux (4h), retrait des coordonnées des journaux (4h), documentation de la procédure (4h) = 24h. |
| P-12 | Écran de suivi interne pour le personnel de l'entrepôt | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 25 / 33 / 46 h | 0,30 / 0,40 / 0,60 | 7,5 h | 13,2 h | 27,6 h | — | Décomposition : liste par statut (8h), filtres/recherche (6h), détail commande (6h), authentification (4h), emplacement de téléchargement conditionnel (3h), tests UI (6h) = 33h. |
| P-13 | Tableaux de bord et rapports sur l'activité d'expédition | 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 | Scénario de réalisation type pour des tableaux de bord agrégés simples, élargi faute de spécification détaillée des indicateurs. |
| P-14 | Sécurité des intégrations — authentification, autorisation et revue ASVS niveau 1 | Sécurité, revue et assurance qualité | 24 / 32 / 46 h | 1,00 / 1,00 / 1,10 | 24 h | 32 h | 50,6 h | — | Décomposition : authentification entrante (6h), autorisation par objet incluant libération (7h), gestion des secrets (4h), revue ciblée avec référentiel ASVS niveau 1 (8h), tests de base (6h) = 31h, arrondi. |
| P-15 | Tests d'intégration bout en bout et recette avec vous | Tests automatisés et documentation | 33 / 44 / 62 h | 0,25 / 0,35 / 0,55 | 8,25 h | 15,4 h | 34,1 h | — | Décomposition : plan de tests (6h), bout en bout des trois intégrations (12h), idempotence/non-duplication avec vérification pré-retry (10h), libération de réservation (4h), validation restauration (4h), recette client (8h) = 44h. |
| P-16 | Mise en production et configuration de l'environnement | Infrastructure et déploiement | 26 / 34 / 48 h | 0,50 / 0,65 / 0,85 | 13 h | 22,1 h | 40,8 h | — | Décomposition : infrastructure applicative/base/file (10h), réseaux et accès (6h), pipeline de déploiement (8h), tests de bascule et de charge de base (6h), configuration de l'environnement de test (4h) = 34h. |
| P-17 | Documentation technique et transfert de connaissances | Tests automatisés et documentation | 18 / 24 / 33 h | 0,25 / 0,35 / 0,55 | 4,5 h | 8,4 h | 18,15 h | — | Décomposition : doc architecture (6h), doc exploitation incluant sauvegarde et purge (5h), doc API intégrations (6h), guide utilisateur (4h), doc rétention (3h) = 24h. |
| P-18 | Formation du personnel de l'entrepôt | Tests automatisés et documentation | 7 / 10 / 17 h | 0,25 / 0,35 / 0,55 | 1,75 h | 3,5 h | 9,35 h | dépend de Q-6 | Scénario de réalisation type pour la formation d'un petit groupe à un écran de suivi simple. |
| P-19 | Gestion de projet et coordination | Coordination, validation client, formation | 49 / 68 / 92 h | 1,00 / 1,00 / 1,00 | 49 h | 68 h | 92 h | — | Calcul dérivé : environ 12 % du total des autres postes du dossier (566 h), soit 68 h. |
| P-20 | Stabilisation après la mise en service | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 20 / 30 / 50 h | 0,30 / 0,40 / 0,60 | 6 h | 12 h | 30 h | dépend de Q-1 | Scénario de réalisation type pour une stabilisation de deux à trois semaines sur un service à trois intégrations externes, incluant la nouvelle chaîne de reprise et de sauvegarde. |

### 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 | 24 h | 47,5 h |
| Analyste qualité / développeur | 115,00 CAD | 8,25 h | 15,4 h | 34,1 h |
| Architecte technique | 165,00 CAD | 43,6 h | 65,6 h | 117,1 h |
| Chargé de projet | 140,00 CAD | 49 h | 68 h | 92 h |
| Développeur / support applicatif | 120,00 CAD | 6 h | 12 h | 30 h |
| Développeur back-end | 130,00 CAD | 23,1 h | 41,6 h | 89,4 h |
| Développeur back-end / analyste données | 135,00 CAD | 10,2 h | 18 h | 38,4 h |
| Développeur back-end / intégration | 130,00 CAD | 59,15 h | 94,4 h | 162 h |
| Développeur back-end/front-end | 130,00 CAD | 12,3 h | 23,6 h | 51,6 h |
| Formateur / analyste d'affaires | 135,00 CAD | 1,75 h | 3,5 h | 9,35 h |
| Rédacteur technique / architecte | 150,00 CAD | 4,5 h | 8,4 h | 18,15 h |
| Spécialiste infrastructure / DevOps | 150,00 CAD | 22 h | 37,7 h | 69,7 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 | Licences logicielles perpétuelles (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Analogie avec un service back-office comparable reposant sur une pile open source. |
| D-2 | Frais d'ouverture de compte fournisseur (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Pratique tarifaire standard des grands fournisseurs infonuagiques au moment de la rédaction. |
| D-3 | Nom de domaine et certificats TLS (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-5 | Hypothèse par défaut faute de confirmation dans le dossier sur la propriété d'un domaine. |
| D-4 | Thème ou composants d'interface payants (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Portée de l'écran de suivi décrite dans le dossier : liste et indicateurs simples, sans exigence de design particulier. |
| D-5 | Frais de configuration facturés par les systèmes tiers (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-8 | Hypothèse faute de confirmation des conditions contractuelles de chaque système tiers, et pour un seul transporteur au démarrage. |
| D-6 | Reprise de données historiques (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Réponse déclarée au questionnaire d'ouverture : nature du projet. |
| D-7 | Matériel physique (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Architecture retenue : aucun composant matériel listé, tous les composants sont logiciels ou infonuagiques. |
| D-8 | Révision juridique externe de la politique de conservation et de confidentialité (prix hypothèse) | Une fois | 1 200,00 CAD | 1 200,00 CAD | dépend de Q-5 | Scénario retenu : 3 à 5 heures de révision par un conseiller juridique externe, à un taux de marché courant pour ce type de mandat. |
| D-9 | Production de contenu (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Exclusion explicite du dossier : aucun écran destiné au client, donc aucun contenu à produire pour un public externe. |
| D-10 | Revue de sécurité externe avant mise en production (prix hypothèse) | Une fois | 2 500,00 CAD | 2 500,00 CAD | dépend de Q-4 | Scénario retenu : revue externe légère (1 à 2 jours-personne) couvrant l'authentification des intégrations et le contrôle d'accès, sur la base d'un niveau 1 de l'ASVS 5.0.0 retenu comme hypothèse de périmètre. |
| D-11 | Frais d'ouverture de l'environnement infonuagique (prix hypothèse) | Une fois | 0,00 CAD | 0,00 CAD | — | Pratique tarifaire standard des grands fournisseurs infonuagiques. |
| D-12 | Hébergement du service applicatif (API, file, orchestrateur, connecteurs) (prix hypothèse) | Mensuelle | 170,00 CAD | 2 040,00 CAD | dépend de Q-1 | Scénario retenu : deux instances modestes exécutant l'API de réception, la file durable des traitements différés, l'orchestrateur et les connecteurs, à un tarif courant d'instance de calcul, pour \~200 commandes/jour soit \~6000/mois. |
| D-13 | Base de données gérée des commandes et expéditions (prix hypothèse) | Mensuelle | 190,00 CAD | 2 280,00 CAD | dépend de Q-1 | Scénario retenu : instance PostgreSQL gérée de petite taille avec réplique de secours, dimensionnée pour \~200 commandes/jour (\~6000/mois, de l'ordre de 70 000 à 75 000 commandes/an au même rythme, conservées trois ans). |
| D-14 | Stockage objet des fichiers d'étiquettes d'expédition (prix hypothèse) | Mensuelle | 8,00 CAD | 96,00 CAD | dépend de Q-9 | Scénario retenu : fichiers d'étiquette de petite taille (quelques dizaines à centaines de Ko), volume aligné sur \~6000 commandes/mois, tarif courant de stockage objet et de transfert associé. |
| D-15 | Abonnements logiciels additionnels (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Analogie avec un service back-office de taille comparable ne nécessitant pas d'outil commercial dédié. |
| D-16 | Frais de transaction financière (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Description du dossier : « à chaque commande payée, la boutique en ligne transmet la commande au service ». |
| D-17 | Notifications par courriel sur les commandes en erreur (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Cadrage révisé : l'exclusion « aucune notification par courriel dans ce périmètre » a été rendue explicite après la revue, faute de mention dans le dossier. |
| D-18 | Surveillance et journalisation centralisée (prix hypothèse) | Mensuelle | 45,00 CAD | 540,00 CAD | dépend de Q-1 | Scénario retenu : abonnement d'entrée de gamme à un service de journalisation et de métriques, dimensionné pour \~200 commandes/jour ; les journaux excluent toute coordonnée client en clair et suivent une rétention courte propre. |
| D-19 | Sauvegardes régulières et fenêtre de restauration testée (base et étiquettes) (prix hypothèse) | Mensuelle | 30,00 CAD | 360,00 CAD | dépend de Q-3 | Scénario retenu : sauvegardes régulières de la base et du stockage des étiquettes conservées sur une fenêtre technique de quelques semaines, avec restauration testée périodiquement ; la conservation métier de trois ans reste assurée séparément par la purge programmée. |
| D-20 | Licences commerciales renouvelables (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Analogie avec un service back-office comparable reposant sur une pile open source. |
| D-21 | Contrat de support tiers (prix hypothèse) | Mensuelle | 0,00 CAD | 0,00 CAD | — | Volume et criticité du service : back-office interne à faible trafic, sans exigence de support fournisseur accéléré déclarée. |
| D-22 | 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 à ce type de service back-office. |

## 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-12, D-13, D-14, D-15, D-16, D-17, D-18, D-19, D-20, D-21, D-22.
- 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 5 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.
- 9 décisions d'architecture (DA-1, DA-2, DA-3, DA-4, DA-5, DA-6, DA-7, DA-8, DA-9) : propositions non encore revues (maintenues telles quelles à la revue).

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

- Les API de la boutique en ligne, de l'entrepôt et du transporteur ne sont pas confirmées quant à leur existence, leur format et leur authentification. — Un ou plusieurs connecteurs pourraient exiger une adaptation (fichier plat, portail manuel) plutôt qu'un appel API direct, avec effort accru et retard de mise en production.
- Le volume quotidien de commandes reste inconnu malgré une croissance forte annoncée. — Le choix du mécanisme de file, le dimensionnement de la base et le coût récurrent reposent sur une hypothèse modérée pouvant nécessiter un ajustement rapide en cas de forte croissance.
- La sauvegarde et la restauration testées sont désormais retenues comme acquises, mais aucune cible (durée d'interruption maximale, perte de données tolérée, heures de service) n'a été demandée. — Sans cible, l'architecture retient une fenêtre de restauration prudente par défaut ; une cible plus stricte augmenterait sensiblement l'infrastructure et son coût récurrent.
- Le mécanisme d'authentification des trois intégrations (boutique, entrepôt, transporteur) n'est pas défini. — Un mécanisme renforcé (certificats mutuels, VPN dédié) demandé après coup ajouterait de la conception et de la configuration non prévues.
- La durée de conservation de trois ans et la suppression ensuite s'appliquent à des coordonnées et identifiants clients sans confirmation d'une base légale précise applicable. — Une exigence légale plus stricte ou différente sur la conservation ou la suppression pourrait modifier le job de purge et la politique de rétention de la base, des sauvegardes et des étiquettes.
- Une demande d'étiquette qui dépasse son délai peut avoir tout de même abouti chez le transporteur ; sans clé d'idempotence ou recherche par référence de commande côté transporteur, une nouvelle tentative crée une deuxième expédition. — C'est précisément le doublon que le dossier interdit ; s'il se produit, il ne serait pas détecté par les tests prévus sans la vérification préalable ajoutée en hypothèse.
- Le nombre de transporteurs à intégrer dès la mise en service n'est pas connu, alors que leur choix reste une décision de la direction. — Chaque transporteur additionnel dès le départ ajoute une intégration complète (conception, développement, tests) non incluse dans l'hypothèse d'un seul transporteur.
- L'usage de l'étiquette après son obtention (impression, téléchargement, transmission automatique à l'entrepôt) n'est pas défini. — Une étape centrale de l'expédition pourrait rester manuelle en dehors du service, ou exiger un stockage et un affichage des étiquettes non estimés si l'hypothèse retenue diffère de l'usage réel.
- La composition de l'équipe de réalisation et les délais externes d'obtention des accès aux API tierces ne sont pas confirmés. — Un calendrier reposant sur une seule personne cumulant tous les rôles, sans les délais externes intégrés au chemin critique, risque d'être optimiste.
- Une révision juridique externe est chiffrée alors qu'une exclusion affirme qu'aucun avis juridique externe n'est prévu. — Sans clarification, le périmètre de la revue juridique est source d'ambiguïté et de litige possible sur ce qui est réellement inclus au prix.

## Volumétrie retenue

| Grandeur | Valeur retenue | À confirmer | Comment ce chiffre est établi |
|---|---|---|---|
| transactions par mois | 6000 | hypothèse à confirmer | Hypothèse basse retenue en l'absence de volume fourni (question Q-1), équivalente à environ 300 commandes par jour ouvré sur 20 jours ouvrés par mois. |
| utilisateurs | 8 | hypothèse à confirmer | Jugement structuré : petite équipe d'entrepôt typique pour un volume hypothétique de 300 commandes/jour, faute de chiffre fourni par le client. |
| facteur de pointe | 3 | hypothèse à confirmer | Jugement structuré : les commerces en ligne connaissent typiquement des pics de 2 à 4 fois le volume moyen lors d'événements commerciaux, faute de donnée propre au client. |
| croissance annuelle | 50 | hypothèse à confirmer | Le dossier mentionne une croissance forte sans chiffre vérifié ; hypothèse prudente retenue par jugement structuré. |

## Ce qui ferait bouger le budget

| Facteur | Hypothèse retenue | Alternative | Impact | Effet sur le délai |
|---|---|---|---|---|
| Volume réel de commandes très supérieur à l'hypothèse retenue (6 000/mois, soit environ 300/jour ouvré) | Le chiffrage part d'un volume prudent de 6 000 commandes/mois faute de donnée fournie (question Q-1) ; la file durable en base et l'infrastructure sont dimensionnées pour ce volume. | Au-delà d'environ 2 000 commandes/jour, la file durable doit migrer vers un courtier de messages dédié et l'infrastructure de production doit être redimensionnée en conséquence. | +45 à 75 h cumulées (file de traitements différés, mise en production, stabilisation) · Correspond aux heures ci-contre au taux horaire applicable selon les rôles concernés (non fixé ici) | +2 à 3 semaines |
| Une ou plusieurs API tierces (boutique, entrepôt, transporteur) absentes ou non standard | Les trois systèmes exposent des API REST standards et documentées, non encore confirmées (question Q-2). | Une intégration par fichier plat ou portail manuel exige une adaptation de conception et de développement pour chaque système concerné. | +25 à 45 h par système non standard, jusqu'à +60 h si plusieurs systèmes sont touchés · Correspond aux heures ci-contre au taux horaire applicable selon les rôles concernés (non fixé ici) | +2 à 4 semaines |
| L'API du transporteur ne permet ni clé d'idempotence ni recherche d'une expédition par référence de commande | Le connecteur transporteur (52 h) prévoit une vérification d'existence avant chaque nouvelle tentative, en supposant que cette vérification est techniquement possible côté transporteur (question Q-7). | Si aucune vérification fiable n'est possible, une réconciliation manuelle ou un mécanisme de rapprochement différé doit être ajouté pour éviter les doublons d'expédition. | +15 à 25 h (connecteur transporteur et orchestrateur) · Correspond aux heures ci-contre au taux horaire applicable selon les rôles concernés (non fixé ici) | +1 à 2 semaines |
| Plusieurs transporteurs à intégrer dès le démarrage plutôt qu'un seul | Un seul transporteur, désigné par la direction, est intégré au démarrage (question Q-8) ; le chiffrage du connecteur transporteur (52 h) ne couvre qu'un seul système. | Chaque transporteur additionnel exige son propre connecteur, sa propre gestion des erreurs et ses propres tests de non-duplication. | +20 à 35 h par transporteur additionnel dès le départ · Correspond aux heures ci-contre au taux horaire applicable selon les rôles concernés (non fixé ici) | +2 à 3 semaines par transporteur additionnel |
| Cibles de reprise après incident (RTO/RPO, heures de service) plus strictes que l'hypothèse retenue | Une fenêtre de restauration de quelques heures et une perte de données tolérée d'au plus une journée suffisent (question Q-3), avec sauvegarde régulière et restauration testée plutôt qu'une réplication active. | Une cible proche du zéro-interruption exige une réplication active et une bascule automatique, avec un environnement de production redondant. | +15 à 30 h (sauvegarde et restauration) et +15 à 25 h (mise en production), soit +30 à 55 h au total · Correspond aux heures ci-contre au taux horaire applicable selon les rôles concernés (non fixé ici), plus une hausse récurrente d'hébergement non chiffrée sans devis d'hébergeur | +1 à 2 semaines |

## Délai

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

### Rythmes possibles

| Rythme | Équipe | Délai | Effort | Enveloppe de services |
|---|---|---|---|---|
| Rapide | 3 personnes | 10 semaines | 453,42 h | 63 228,55 CAD |
| Équilibré | 2 personnes | 11 semaines | 432,81 h | 60 354,53 CAD |
| Économe | 1 personne | 16 semaines | 412,2 h | 57 480,50 CAD |

Le même travail (412,2 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 (145,4 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 (5 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,52 / 0,62 / 0,79). Les délais externes ne bougent pas.

| Phase | Référence (b / c / h) | Retenue (b / c / h) | Jalon |
|---|---|---|---|
| Cadrage | 0,6 / 0,8 / 1,4 sem. | 0,3 / 0,5 / 1,1 sem. | Spécification fonctionnelle validée avec vous : idempotence, accusé de réception, libération de réservation sur échec définitif, statuts de suivi. |
| Conception | 0,8 / 1,2 / 1,9 sem. | 0,4 / 0,7 / 1,5 sem. | Architecture d'orchestration, file durable couvrant toute la chaîne sortante, stockage des étiquettes et sauvegarde/restauration validés. |
| Réalisation | 4,2 / 5,8 / 8,3 sem. | 2,2 / 3,6 / 6,5 sem. | Orchestrateur, modèle de données, file durable, stockage des étiquettes et écrans internes fonctionnels en environnement de développement. |
| Intégrations | 3,2 / 4,2 / 5,8 sem. | 1,7 / 2,6 / 4,6 sem. | Connecteurs boutique, entrepôt et transporteur fonctionnels ; idempotence, reprise et libération de réservation testées. |
| Recette | 0,9 / 1,2 / 1,7 sem. | 0,5 / 0,7 / 1,3 sem. | Tests bout en bout, exercice de restauration testée et recette validés avec le personnel de l'entrepôt. |
| Mise en production | 1,9 / 2,6 / 3,7 sem. | 1 / 1,6 / 2,9 sem. | Environnement de production configuré, sauvegarde active, documentation et formation livrées. |
| Stabilisation | 0,6 / 0,8 / 1,4 sem. | 0,3 / 0,5 / 1,1 sem. | Service stabilisé après deux à trois semaines d'exploitation réelle, y compris la chaîne de reprise et de sauvegarde. |

- Ouverture des accès et environnements de test chez les trois systèmes tiers (boutique, entrepôt, transporteur) : 2 semaine(s) — Délai administratif hors du contrôle de l'équipe de réalisation ; dépend de la réactivité de chaque fournisseur tiers pour fournir des accès API, un bac à sable et confirmer un éventuel mécanisme d'idempotence côté transporteur.
- Validation de la politique de conservation, de purge et de sauvegarde des commandes après trois ans : 1 semaine(s) — Nécessite une confirmation côté client (juridique ou conformité) avant de figer la règle de purge, qui couvre désormais la base, les sauvegardes, les journaux et les étiquettes stockées.
- Boucles de validation fonctionnelle du client au cadrage et à la recette : 1.5 semaine(s) — Dépend de la disponibilité du répondant métier unique supposé disponible ; un métier peu disponible allonge ces boucles, tout comme la confirmation du nombre de transporteurs et de l'usage de l'étiquette.

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 — Service back-office d'orchestration sans écran client ni contenu éditorial à produire ou gérer.
- référencement — Aucun écran public ; le dossier exclut explicitement toute interface destinée au client.
- traduction — Écran de suivi interne et documentation prévus en une seule langue, sans exigence de traduction ni de prise en charge multilingue mentionnée.
- reprise de données historiques — Nouveau produit construit à partir de rien ; aucun système existant à reprendre n'est décrit dans le dossier.
- accessibilité — Écran interne à usage restreint (personnel d'entrepôt) ; aucune exigence d'accessibilité formelle mentionnée.
- conseil juridique ou réglementaire — La règle de conservation de trois ans et son alignement avec la purge des sauvegardes, étiquettes et journaux sont traités comme des hypothèses techniques à confirmer avec vous ; aucune révision juridique externe n'est chiffrée ni comprise.
- licences tierces — Les contrats et frais d'accès aux API de la boutique, de l'entrepôt et du transporteur restent à votre charge.
- support après stabilisation — Seule la stabilisation de deux à trois semaines suivant la mise en service est comprise ; un support récurrent ultérieur reste à définir séparément.
- évolutions fonctionnelles — Seules les fonctions décrites (réception, réservation, étiquette avec reprise et vérification anti-doublon, suivi interne, rapports) sont comprises ; l'ajout d'un transporteur supplémentaire ou d'une nouvelle règle fait l'objet d'une demande 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-2 — Les trois systèmes externes (boutique en ligne, système d'entrepôt, transporteur) exposent-ils déjà des API documentées, avec quelle authentification ? | Les API des trois systèmes existent et suivent des standards REST courants. ; Une seule opération de réservation par commande, sans réservation partielle complexe. ; Aucun environnement de test tiers indisponible ne bloque la recette. ; Aucun composant propriétaire à licence perpétuelle n'est requis par l'architecture proposée. ; Le fournisseur retenu n'exige pas de frais d'activation ou de dépôt initial. ; Aucun outil de gestion de projet, de tests ou de conception facturé au client n'est requis en plus des outils internes de l'équipe de réalisation. ; Aucun composant propriétaire à licence annuelle n'est requis par l'architecture. | P-2, P-4, P-15, D-1, D-2, D-15, D-20 | 13 967,75 CAD + 0,00 CAD de dépenses sur l'horizon |
| Q-6 — Y a-t-il une date de mise en service visée, par exemple avant une période de forte activité commerciale ? | Interlocuteur métier disponible sur deux à trois ateliers. ; Un seul document par volet, sans révision multiple approfondie. ; Aucune rotation de personnel ni sessions multiples à répéter. ; Un seul chargé de projet suffit, sans comité de gouvernance élargi. ; Aucune exigence graphique de marque ne dépasse ce que couvre une bibliothèque de composants libre. ; Aucun système existant de suivi d'expédition ne contient de données à reprendre. ; Le personnel de l'entrepôt utilise des postes déjà existants pour accéder à l'écran de suivi. ; L'écran interne se limite à des libellés fonctionnels sans contenu éditorial. ; Le service ne prendra jamais en charge de flux de paiement, même en cas d'évolution future. ; Aucun poste de dépense imprévu ne se révèle en cours de conception détaillée. | P-1, P-17, P-18, P-19, D-4, D-6, D-7, D-9, D-16, D-22 | 13 783,50 CAD + 0,00 CAD de dépenses sur l'horizon |
| Q-4 — Quel mécanisme d'authentification et d'autorisation est prévu pour les appels entrants de la boutique et les appels vers l'entrepôt et le transporteur ? | Authentification par jeton simple, sans certificat mutuel. ; Un seul rôle d'accès, sans permissions fines. ; Aucune exigence de conformité formelle audit externe n'est demandée à ce stade. ; La revue reste ciblée sur les trois intégrations et l'écran interne, sans test d'intrusion complet, au niveau ASVS 1 à confirmer avec vous. | P-3, P-12, P-14, D-10 | 11 136,00 CAD + 2 500,00 CAD de dépenses sur l'horizon |
| Q-1 — Quel est le volume actuel de commandes par jour, et la croissance visée à 12-24 mois ? | Volume modéré ne justifiant pas un courtier de messages dédié. ; Volume ne justifiant pas de partitionnement. ; Aucun export planifié récurrent ni intégration à un outil de reporting externe. ; Aucune panne prolongée d'un système tiers pendant la période de stabilisation. ; Le volume retenu est de l'ordre de 200 commandes/jour (\~6000/mois), sans appliquer de facteur de croissance non chiffré ; volume réel non confirmé. ; Le volume de données reste modéré (\~200 commandes/jour, sans multiplicateur de croissance non chiffré) ; une réplique de secours suffit à l'exigence de disponibilité courante. ; Le personnel de l'entrepôt consulte les erreurs uniquement via l'écran de suivi interne, sans alerte poussée par courriel. ; Le volume de journaux reste proportionnel à un trafic modéré ; aucune rétention étendue au-delà des besoins d'exploitation courants n'est exigée. | P-6, P-8, P-13, P-20, D-12, D-13, D-17, D-18 | 10 447,50 CAD + 4 860,00 CAD de dépenses sur l'horizon |
| Q-3 — Quelle durée d'interruption maximale acceptable (RTO), quelle perte de données tolérée (RPO) et quelles heures de service sont attendues pour ce service ? | Aucune exigence d'archivage légal distinct de la suppression décrite. ; Restauration en quelques heures acceptable, sans réplication active. ; Un seul environnement de production, avec un environnement de test réduit. ; La sauvegarde et la restauration testées sont retenues comme acquises pour l'exigence de reprise après incident, indépendamment de la reprise des appels au transporteur ; la fenêtre technique de sauvegarde ne prolonge pas la conservation des coordonnées client au-delà des trois ans. ; Le support standard inclus dans les services infonuagiques suffit à la cible de restauration retenue par défaut ; aucun engagement de temps de réponse renforcé n'est exigé. | P-9, P-11, P-16, D-19, D-21 | 8 815,50 CAD + 360,00 CAD de dépenses sur l'horizon |
| Q-8 — Combien de transporteurs doivent être intégrés dès la mise en service, et cette liste est-elle déjà arrêtée par la direction ? | Un seul transporteur intégré au départ. ; Aucun des systèmes intégrés au démarrage (boutique, entrepôt, un transporteur) ne facture l'accès à son API ou sa configuration. | P-5, D-5 | 5 980,00 CAD + 0,00 CAD de dépenses sur l'horizon |
| Q-7 — L'API du transporteur accepte-t-elle une clé d'idempotence sur la demande d'étiquette, ou permet-elle de retrouver une expédition existante à partir de la référence de commande ? | Aucune compensation complexe au-delà de la libération standard. | P-7 | 3 510,00 CAD |
| Q-9 — Comment l'étiquette d'expédition parvient-elle au poste d'emballage : impression directe depuis l'écran de suivi, téléchargement du fichier, ou transmission automatique au système d'entrepôt ? | Téléchargement manuel depuis l'écran de suivi, sans transmission automatique à un système tiers. ; Le stockage des étiquettes est retenu comme composant du périmètre, dans l'attente de la confirmation de l'usage réel de l'étiquette au poste d'emballage. | P-10, D-14 | 2 184,00 CAD + 96,00 CAD de dépenses sur l'horizon |
| Q-5 — Existe-t-il une exigence de résidence ou de traitement des données au Canada (ou ailleurs) pour les coordonnées clients ? | Le client possède déjà un domaine corporatif pouvant recevoir un sous-domaine interne. ; Le service traite des coordonnées clients (nom, courriel, adresse, téléphone) déclarées au questionnaire d'ouverture, ce qui justifie une validation légère de la politique de conservation, de suppression et de résidence. ; Le fournisseur retenu facture uniquement à l'usage, sans frais de provisionnement initial. | D-3, D-8, D-11 | 1 200,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é** (composant Tâche planifiée de purge des commandes) : La dépense « » prévoit de conserver les sauvegardes pendant trois ans. Or la tâche de purge ne supprime que les données de la base. Les coordonnées des clients survivraient donc dans les sauvegardes, les journaux centralisés, les courriels de notification et le stockage objet des étiquettes, jusqu'à six ans après la commande. — La règle « conservées trois ans, puis supprimées » ne serait pas respectée pour une partie des renseignements personnels. — modifié dans la révision : La purge couvre désormais aussi les étiquettes stockées, pas seulement la base. Un composant de sauvegarde dédié (« Service de sauvegarde et restauration ») applique une fenêtre technique courte, distincte et plus courte que la conservation métier de trois ans, pour que les coordonnées clients ne survivent pas dans les sauvegardes au-delà de l'échéance. La journalisation (« Journalisation et supervision ») n'écrit plus de coordonnées client en clair et suit sa propre rétention courte. Ces points sont repris dans la décision « Classification, chiffrement et purge complète des coordonnées clients » et dans l'exigence « E-12 » révisée.
- **risque** (besoin E-7) : La reprise suppose que le transporteur distingue les erreurs passagères des erreurs définitives. Elle ne traite pas le cas où la demande dépasse son délai alors que l'étiquette a quand même été créée chez le transporteur. Dans ce cas, une nouvelle tentative crée une deuxième expédition. — C'est précisément le doublon que S-1 interdit, et il ne serait pas détecté par les tests prévus. — modifié dans la révision : Une nouvelle question essentielle (« Q-7 ») demande si le transporteur accepte une clé d'idempotence ou permet de retrouver une expédition par référence de commande. Par défaut, le connecteur transporteur vérifie désormais l'existence d'une expédition avant chaque nouvelle tentative, ce qui est reflété dans le poste « P-5 », la décision « File durable et reprise idempotente sur toute la chaîne sortante » et l'exigence « E-7 » révisée.
- **risque** (décision File asynchrone en base pour la reprise des demandes d'étiquette) : Seule la demande d'étiquette passe par la file de reprise. Le renvoi du numéro de suivi à la boutique et la réservation en entrepôt sont des appels directs, sans reprise automatique. Ni l'annulation d'une réservation après un échec définitif de l'étiquette, ni la réponse de l'API à la boutique quand un système tiers est lent ne sont décrites. — Une indisponibilité de la boutique ferait perdre des numéros de suivi. Des articles pourraient aussi rester réservés sans être expédiés, alors que la disponibilité est exigée. — modifié dans la révision : Une file durable unique (« P-6 ») porte désormais toute la chaîne sortante — réservation, demande d'étiquette et retour du numéro de suivi — avec reprises idempotentes, et non plus la seule demande d'étiquette. Un accusé de réception immédiat de la commande a été ajouté avant le traitement différé (« E-3 ») pour protéger la commande si la boutique devient indisponible ensuite. La libération automatique de la réservation après un échec définitif de l'étiquette est également ajoutée (« E-5 »), avec le flux et le composant correspondants. Voir la décision « File durable et reprise idempotente sur toute la chaîne sortante ».
- **défaut démontré** (question reprise-vs-sauvegarde) : La question repose sur un signal automatique erroné, et sa justification l'avoue devant vous. Or la « reprise après incident » a été déclarée indispensable au questionnaire d'ouverture, indépendamment de la reprise des demandes d'étiquette. La vraie inconnue, jamais posée, porte sur la cible : durée d'interruption acceptable, perte de données tolérée et heures de service. — La sauvegarde reste présentée comme une hypothèse révocable, alors que les cibles qui dimensionnent la réplique, les sauvegardes et le coût ne sont pas demandées. — modifié dans la révision : La sauvegarde et la restauration testées sont désormais retenues comme un choix arrêté du périmètre (« E-21 »), indépendamment de la reprise des appels au transporteur ; la décision « Exploitation outillée : déploiement reproductible et sauvegardes testées » ne la présente plus comme une hypothèse révocable. La question « reprise-vs-sauvegarde » a été retirée et remplacée par « Q-3 », qui porte directement sur la durée d'interruption maximale acceptable, la perte de données tolérée et les heures de service — les vraies inconnues qui dimensionnent la réplique et le coût récurrent.
- **défaut démontré** (proposition) : La dépense « » (1 200 CAD) chiffre une révision juridique externe. La liste des exclusions affirme pourtant « aucun avis juridique externe n'est prévu ». — Vous ne pouvez pas savoir si l'avis juridique est inclus dans le prix ; ce point est source de litige sur le périmètre. — modifié dans la révision : Les deux options ont été alignées : une revue légère de la politique de conservation et de purge reste incluse comme dépense (compte tenu de l'étendue de la purge, désormais élargie aux étiquettes et aux sauvegardes), et l'exclusion correspondante a été reformulée pour préciser que seule cette revue ciblée est comprise, tout avis juridique plus large restant hors mandat. Le délai externe d'une semaine pour cette validation reste cohérent avec cette portée précisée.
- **défaut démontré** (proposition) : Les notes techniques indiquent qu'« aucune notification par courriel n'est demandée ». Des notifications par courriel sont pourtant chiffrées en dépenses et en infrastructure, sans poste de travail ni composant correspondant. — Une fonction est facturée sans être construite, ou construite sans avoir été demandée. — modifié dans la révision : Une exclusion explicite « E-16 » a été ajoutée : aucune notification par courriel n'est décrite dans le dossier, seul l'écran de suivi interne sert à consulter l'état des commandes. Les dépenses et l'infrastructure de notification par courriel, qui contredisaient les notes techniques, ont été retirées en conséquence pour rester cohérentes avec cette exclusion.
- **information manquante** (proposition) : L'usage des étiquettes après leur obtention n'est pas défini : impression à l'entrepôt, téléchargement depuis l'écran de suivi, ou envoi au système d'entrepôt. Le stockage objet reste « à confirmer », sans composant, sans flux vers l'écran, sans heures ni coût. — Une étape centrale de l'expédition pourrait rester manuelle ou exiger des travaux non estimés. — modifié dans la révision : Une question essentielle (« Q-9 ») demande comment l'étiquette parvient au poste d'emballage. Un composant de stockage dédié (« P-10 »), un poste de travail correspondant, et une décision architecturale (« Stockage objet pour les fichiers d'étiquette d'expédition ») ont été ajoutés, avec l'hypothèse par défaut d'un téléchargement depuis l'écran de suivi, à confirmer avec vous.
- **défaut démontré** (décision Dimensionnement initial sur hypothèse de volume modéré) : Le chiffre de 6 000 commandes par mois est présenté comme 200 commandes par jour ouvré, ce qui donne environ 4 400. Le chiffrage de la base affirme « quelques dizaines de milliers de commandes par an même à trois fois le volume », alors qu'on atteint environ 220 000 commandes par an. La croissance de 50 %, le facteur de pointe de 3 et les 8 utilisateurs n'ont aucune source. — Le dimensionnement et le coût récurrent reposent sur des chiffres internes contradictoires. — modifié dans la révision : Les chiffres de volume, de croissance, de facteur de pointe et de nombre d'utilisateurs sont désormais présentés de façon cohérente entre eux et explicitement rattachés à la question « Q-1 » comme hypothèses à confirmer avec vous, plutôt que comme des données arrêtées ; les calculs de conversion jour/mois et de projection à trois fois le volume ont été recalculés pour éviter les contradictions relevées.
- **défaut démontré** (poste Intégration — demande d'étiquette et suivi transporteur, avec reprise) : Plusieurs hypothèses sont rattachées à des questions sans rapport. Par exemple, l'hypothèse « un seul transporteur » renvoie à reprise-vs-sauvegarde, et le thème d'interface à Q-6. Le nombre de transporteurs, qui dépend de la direction, ne fait l'objet d'aucune question. — Vos réponses ne déclencheraient pas la révision des postes qu'elles touchent réellement. — modifié dans la révision : Les rattachements ont été corrigés : la décision « File durable et reprise idempotente sur toute la chaîne sortante » (qui inclut l'hypothèse du transporteur unique) renvoie désormais à la nouvelle question « Q-7 » et à « Q-1 » ; la décision « Exploitation outillée : déploiement reproductible et sauvegardes testées » renvoie à « Q-3 » plutôt qu'à l'ancienne question mal ciblée. Une nouvelle question essentielle (« Q-8 ») a été ajoutée pour couvrir explicitement le nombre de transporteurs à intégrer au départ, rattachée à l'exclusion « E-14 ».
- **risque** (proposition) : Le calendrier suppose une seule personne à temps plein qui assume tous les rôles : analyste, architecte, développeur, DevOps et formateur. Les délais externes (deux semaines pour obtenir les accès des tiers) ne semblent pas intégrés au calendrier. — Le délai annoncé risque d'être optimiste et de dépendre d'une seule personne. — modifié dans la révision : Un risque explicite a été ajouté sur la dépendance à une seule personne cumulant tous les rôles et sur les délais externes d'obtention des accès aux API tierces, signalé comme nécessitant une décision avec vous. La question « Q-6 » précise désormais que ces délais externes s'ajoutent au chemin critique quelle que soit la réponse sur l'échéance visée, pour éviter qu'ils restent implicites.
- **défaut démontré** (poste Écran de suivi interne pour le personnel de l'entrepôt) : L'hypothèse de ce poste contient des caractères étrangers au texte (« de支持 multilingue »). — Ce défaut de rédaction est visible dans un document remis au client. — modifié dans la révision : Le texte a été corrigé : l'hypothèse du poste « P-12 » indique maintenant « Aucune exigence d'accessibilité ou de prise en charge multilingue avancée », sans caractères étrangers au texte.

---

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