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. Analyse assistée par des fournisseurs d'IA établis aux États-Unis.
Studio de yoga — espace fictif
Rapport client — Réservation de cours et forfaits d'un studio de yoga (exemple fictif)
L'essentiel
- Coût total client sur l'horizon
- 42 877,96 CAD fourchette 36 759,21 CAD – 56 056,21 CAD
- Enveloppe de services
- 16 281,00 CAD fourchette 10 162,25 CAD – 29 459,25 CAD
- Budget recommandé à autoriser
- 47 165,76 CAD Entre 40 435,13 CAD et 61 661,83 CAD
- Délai estimé
- 6 semaines fourchette 5 – 8 semaines
- Part du budget à confirmer
- 1 % repose sur des hypothèses que vos réponses peuvent confirmer — voir « À préciser ensemble »
Une estimation faite à ce stade comporte une marge : le montant final dépend de ce qui reste à préciser et de vos choix.
Solution proportionnée à une petite équipe, qui s'appuie sur des services de marché.
Sans l'accélération supposée par le mode de réalisation : 30 800,00 CAD d'enveloppe de services et 7 semaines.
Échéance déclarée au questionnaire : dans les trois mois (13 semaines). Délai calculé : 6 semaines : l'échéance est tenue au rythme retenu.
Besoin et objectifs
Remplacer l'horaire papier et les échanges par courriel du studio par un site où les membres réservent leurs cours et achètent leurs forfaits, avec les outils de gestion dont l'équipe et les professeurs ont besoin.
Studio de yoga de quartier. Aujourd'hui : horaire papier, réservations par téléphone et courriel. Volume déclaré : de 1 500 à 2 000 réservations par mois, de 500 à 5 000 utilisateurs au total. Données traitées : coordonnées et identification, paiement par carte. Client au Québec, hébergement souhaité au Canada (préférence négociable). Échéance visée : dans les trois mois. Budget non arrêté. Deux services externes déclarés : paiement par carte et envoi de courriels.
Recommandation
Application web sur mesure de réservation et de forfaits, appuyée sur des services gérés — Une seule application web adaptée aux téléphones, avec trois espaces : membres, professeurs, équipe du studio. Elle s'appuie sur des services du marché pour tout ce qui n'est pas le cœur du besoin : hébergement géré en région canadienne avec sauvegardes du fournisseur, base de données gérée, authentification gérée, page de paiement hébergée chez le prestataire (l'application ne reçoit qu'un jeton et un résultat), courriel transactionnel. Les règles du studio (douze places, annulation à douze heures, liste d'attente, décompte des séances), la gestion de l'horaire par l'équipe et le rapport mensuel sont construits dans l'application. Un environnement de test et un environnement de production, déploiement scripté, technologies répandues et bien documentées. Style en un seul bloc découpé en modules (hypothèse, fiche non vérifiée).
Les règles de réservation, de liste d'attente et de décompte des séances sont propres au studio et se combineraient mal dans un outil générique ; le dossier ne demande pas de produit du marché et n'en possède pas à conserver. La fiche « acheter ou construire » (non vérifiée) retient construire par défaut et rien dans le dossier n'invoque une dérogation : un logiciel de réservation du marché n'est donc pas retenu. Un volume de 1 500 à 2 000 réservations par mois et une capacité d'une personne appellent un seul bloc applicatif, sans microservice ni courtier de messages. La page de paiement hébergée garde les numéros de carte chez le prestataire et réduit le périmètre PCI du studio. La sécurité (OWASP Top 10:2025, authentification gérée, chiffrement), la résidence au Canada et la protection des renseignements personnels (Loi 25) restent entières.
Conditions :
- Le studio désigne une personne pour valider les règles de réservation, de forfaits, de liste d'attente et de remboursement.
- Réponses aux questions sur l'outil existant, l'abonnement, la liste d'attente et les fournisseurs avant la conception technique.
- Un prestataire de paiement reconnu, avec page hébergée et attestation PCI à jour, est retenu avec le studio.
- Le studio nomme un responsable des renseignements personnels et fixe la durée de conservation des données.
- Le studio réserve au moins une semaine de recette et suit environ deux semaines de stabilisation après la mise en service.
- Leviers pour l'échéance : réduire ou phaser le périmètre (rapport mensuel, espace professeur), pilote sur quelques cours, ou équipe plus nombreuse.
Périmètre inclus
| Code | Nature | Élément | État |
|---|---|---|---|
| E-1 | Objectif | Remplacer l'horaire papier et les courriels par un site de réservation | à confirmer |
| E-2 | Exigence | Consulter l'horaire de la semaine et réserver une place (12 au plus par cours) | à confirmer |
| E-3 | Exigence | Gestion de l'horaire par l'équipe : création, modification et annulation des cours | à confirmer |
| E-4 | Exigence | Annulation jusqu'à 12 h avant le cours ; au-delà, la séance est comptée | à confirmer |
| E-5 | Exigence | Liste d'attente avec avis par courriel | à confirmer |
| E-6 | Exigence | Vente de forfaits payables par carte sur le site | à confirmer |
| E-7 | Exigence | Déduction automatique des séances à chaque réservation | à confirmer |
| E-8 | Exigence | Espace professeur : participants et annulation de cours | à confirmer |
| E-9 | Exigence | Outils de la réceptionniste : solde et réservation par téléphone | à confirmer |
| E-10 | Exigence | Rapport mensuel : fréquentation par cours et ventes de forfaits | à confirmer |
| E-11 | Exigence | Comptes personnels et rôles (membre, professeur, équipe) | à confirmer |
| E-12 | Exigence | Intégration d'un service de paiement par carte (page hébergée) | à confirmer |
| E-13 | Exigence | Intégration d'un service d'envoi de courriels transactionnels | à confirmer |
| E-14 | Contrainte | Hébergement des données au Canada (préférence négociable) | à confirmer |
| E-15 | Contrainte | Renseignements personnels : Loi 25 à considérer | à confirmer |
| E-16 | Contrainte | Paiement par carte : périmètre réduit, aucun numéro de carte conservé | à confirmer |
| E-17 | Contrainte | Sécurité applicative d'un site avec comptes et paiement | à confirmer |
| E-18 | Contrainte | Échéance visée : dans les trois mois | à confirmer |
| E-19 | Contrainte | Environ 700 membres actifs, 1 500 à 2 000 réservations par mois | à confirmer |
| E-20 | Contrainte | Budget non arrêté | à confirmer |
| E-26 | Hypothèse | Socle construit à neuf : comptes, horaire et soldes | à confirmer |
| E-27 | Hypothèse | Liste d'attente : avis à tous les membres en attente, sans réservation automatique | à confirmer |
| E-28 | Hypothèse | Abonnement mensuel renouvelé automatiquement par le prestataire de paiement | à confirmer |
| E-29 | Hypothèse | Exploitation par une personne du studio ou un fournisseur externe | à confirmer |
| E-30 | Hypothèse | Sauvegardes du service géré ; rétention et objectifs de reprise à confirmer | à confirmer |
| E-31 | Hypothèse | Accessibilité visée : WCAG 2.2 niveau AA sur les parcours essentiels | à confirmer |
E-21 figure à la section « Exclusions ».
E-22 figure à la section « Exclusions ».
E-23 figure à la section « Exclusions ».
E-24 figure à la section « Exclusions ».
E-25 figure à la section « Exclusions ».
Exclusions
- E-21 : Comptabilité hors mandat
- E-22 : Traduction et conseil juridique ou réglementaire
- E-23 : Aucune reprise de données existantes
- E-24 : Application mobile native et notifications par message texte
- E-25 : Test d'intrusion externe : hors de la base, variante chiffrée à part
Principales hypothèses
- Socle construit à neuf : comptes, horaire et soldes
- Liste d'attente : avis à tous les membres en attente, sans réservation automatique
- Abonnement mensuel renouvelé automatiquement par le prestataire de paiement
- Exploitation par une personne du studio ou un fournisseur externe
- Sauvegardes du service géré ; rétention et objectifs de reprise à confirmer
- Accessibilité visée : WCAG 2.2 niveau AA sur les parcours essentiels
Approches examinées
Les approches considérées avant de retenir celle qui est chiffrée. Une approche « à vérifier » ne l'a pas été : ses fonctions, ses intégrations et ses coûts restent à confirmer avant d'en faire une option.
| Approche | Statut | Ordre de grandeur | Motif |
|---|---|---|---|
| Application web sur mesure appuyée sur des services gérés (construction) | retenue et chiffrée | 166 à 309 h classiques · 10 162,25 CAD à 29 459,25 CAD | Les règles du studio (douze places, annulation à douze heures, liste d'attente, décompte des séances, ajustements de solde) se combinent mal dans un outil générique, et aucun outil à conserver n'est confirmé. Paiement par page hébergée, authentification et courriel viennent de services du marché. |
| Logiciel de réservation de studio du marché, paramétré (achat et paramétrage) | à vérifier | 40 à 100 h classiques · 2 831,48 CAD à 7 078,70 CAD | Ce type de produit couvre souvent horaire, forfaits et paiement, mais rien n'est vérifié ici : règles d'annulation et de liste d'attente, abonnement récurrent, rapport demandé, traitement des données au Canada, coûts d'abonnement. Heures de services : configuration, branchement du paiement et du courriel, formation. — ne couvre pas : Rapport mensuel exact (fréquentation par cours, ventes de forfaits) à valider ; Ajustement manuel des soldes et saisie au comptoir à valider ; Espace professeur avec annulation de cours et avis aux membres à valider ; Résidence des données au Canada et Loi 25 : région de traitement du fournisseur à vérifier |
| Première version réduite : réservation, forfaits et paiement, puis rapport et espace professeur (première version réduite) | possible | 140 à 260 h classiques · 9 910,17 CAD à 18 404,61 CAD | Même application que l'approche retenue, livrée en deux étapes. Le rapport mensuel et l'espace professeur viennent après la mise en service. Levier sur le périmètre de la première version ; la comparaison avec l'échéance est faite par le calcul du dossier. — ne couvre pas : Rapport mensuel absent de la première étape ; Espace professeur et avis d'annulation de cours absents de la première étape ; Annulations de cours saisies par la réception en attendant |
| Conserver l'outil du marché actuel et le compléter (réemploi de l'existant) | à vérifier | non dimensionnée | Le questionnaire parle d'un outil du marché devenu insuffisant, alors que la description décrit un horaire papier et des courriels. Si un outil existe et peut être prolongé, seule l'intégration serait chiffrée. À confirmer avec vous : son nom, ses limites et ses exports. — ne couvre pas : Fonctions manquantes qui rendent l'outil insuffisant, à nommer ; Compatibilité avec la page de paiement hébergée et les règles de solde à vérifier |
Ordre de grandeur des autres approches : leurs heures de réalisation classique au coût moyen d'une heure de référence de ce dossier (70,79 CAD) — une comparaison, pas un devis.
Architecture proposée
Une seule application web adaptée aux téléphones, avec trois espaces : membres, professeurs, équipe du studio. Elle s'appuie sur des services du marché pour tout ce qui n'est pas le cœur du besoin : hébergement géré en région canadienne avec sauvegardes du fournisseur, base de données gérée, authentification gérée, page de paiement hébergée chez le prestataire (l'application ne reçoit qu'un jeton et un résultat), courriel transactionnel. Les règles du studio (douze places, annulation à douze heures, liste d'attente, décompte des séances), la gestion de l'horaire par l'équipe et le rapport mensuel sont construits dans l'application. Un environnement de test et un environnement de production, déploiement scripté, technologies répandues et bien documentées. Style en un seul bloc découpé en modules (hypothèse, fiche non vérifiée).
Schémas dessinés par Linuen Studio à partir de ce que l'IA a décrit ; les numéros des flux renvoient au tableau sous le schéma.
Vue d'ensemble
Composants et flux
Traits : appel (plein), événement (tirets), traitement planifié (pointillés), fichier (tiret-point), action d'une personne (bleu). Contour épais : zone restreinte ; contour pointillé : hors système.
| N° | De | Vers | Mode | Ce qui passe |
|---|---|---|---|---|
| 1 | Site des membres (adapté aux téléphones) | Service d'authentification géré | action d'une personne | Connexion et création de compte ; le service émet une session. |
| 2 | Site des membres (adapté aux téléphones) | Application de réservation (un seul bloc, découpé en modules) | appel | Consultation de l'horaire, réservation, annulation, inscription en attente, demande d'achat. |
| 3 | Espaces professeurs et équipe du studio | Application de réservation (un seul bloc, découpé en modules) | appel | Actions des professeurs, de la réceptionniste et de l'équipe, selon le rôle. |
| 4 | Application de réservation (un seul bloc, découpé en modules) | Service d'authentification géré | appel | Vérification de la session et de l'identité à chaque requête. |
| 5 | Application de réservation (un seul bloc, découpé en modules) | Base de données relationnelle gérée | appel | Lectures et écritures transactionnelles ; la réservation et le décompte de séance se font dans une même transaction. |
| 6 | Application de réservation (un seul bloc, découpé en modules) | Service de paiement par carte (page hébergée) | appel | Création d'une session de paiement ; le membre est redirigé vers la page hébergée. |
| 7 | Service de paiement par carte (page hébergée) | Application de réservation (un seul bloc, découpé en modules) | événement | Résultat du paiement et jeton par signalement signé ; traitement idempotent avant activation du forfait. |
| 8 | Application de réservation (un seul bloc, découpé en modules) | Service de courriel transactionnel | événement | Envoi des avis : confirmation, place libérée, cours annulé, reçu ; reprise bornée en cas d'échec. |
| 9 | Tâches planifiées | Application de réservation (un seul bloc, découpé en modules) | traitement planifié | Expirations, renouvellements, avis différés et production du rapport mensuel. |
| 10 | Hébergement géré en région canadienne | Application de réservation (un seul bloc, découpé en modules) | appel | Exécution de l'application ; journaux et alertes de base. |
Parcours utilisateurs
Acheter un forfait par carte — Membre du studio
But : Obtenir une carte de dix séances ou un abonnement mensuel, payé en ligne, et le voir activé dans son solde.
- Membre du studio → Site des membres (adapté aux téléphones) : Choisit une carte de dix séances ou l'abonnement mensuel illimité
- Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) : Demande l'achat du forfait
- Application de réservation (un seul bloc, découpé en modules) → Service de paiement par carte (page hébergée) : Prépare le paiement et redirige le membre vers la page du prestataire
- Membre du studio → Service de paiement par carte (page hébergée) : Saisit sa carte sur la page du prestataire, jamais sur le site du studio
- Service de paiement par carte (page hébergée) → Application de réservation (un seul bloc, découpé en modules) : Signale le résultat du paiement avec un jeton
- Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Enregistre l'achat et crédite le solde, une seule fois
- Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Envoie le reçu par courriel, après l'enregistrement de l'achat
- Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Affiche le forfait activé, ou le refus du paiement sans rien créditer
Réserver une place ou s'inscrire en attente — Membre du studio
But : Obtenir une place dans un cours de la semaine, ou être placé en liste d'attente si le cours est complet.
- Membre du studio → Site des membres (adapté aux téléphones) : Consulte l'horaire de la semaine et choisit un cours
- Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) : Demande une place dans le cours
- Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Réserve la place et déduit une séance dans la même opération
- Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Confirme la réservation, après son enregistrement
- Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Envoie la confirmation par courriel
- Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Inscrit le membre sur la liste d'attente, par ordre d'arrivée
- Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Indique que le forfait est épuisé et propose l'achat
Annuler une place et aviser la liste d'attente — Membre du studio
But : Annuler sa réservation en sachant si la séance sera comptée, et permettre à un membre en attente de prendre la place.
- Membre du studio → Site des membres (adapté aux téléphones) : Demande l'annulation de sa réservation
- Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) : Transmet la demande ; le site précise si la séance sera comptée
- Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Libère la place et rétablit la séance
- Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Libère la place, la séance reste comptée
- Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Confirme l'annulation, après son enregistrement
- Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Avise par courriel les membres en attente qu'une place est libre
- Membre du studio → Site des membres (adapté aux téléphones) : Le membre avisé réserve la place par une réservation normale
Annuler un cours et aviser les inscrits — Professeur à la pige
But : Annuler un de ses cours et s'assurer que chaque inscrit est avisé et récupère sa séance.
- Professeur à la pige → Espaces professeurs et équipe du studio : Ouvre la liste de ses participants et choisit d'annuler son cours
- Espaces professeurs et équipe du studio → Application de réservation (un seul bloc, découpé en modules) : Demande l'annulation ; seul le professeur du cours peut l'annuler
- Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Marque le cours annulé et rétablit les séances des inscrits
- Application de réservation (un seul bloc, découpé en modules) → Espaces professeurs et équipe du studio : Confirme l'annulation, après son enregistrement
- Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Envoie un avis par courriel à chaque membre inscrit
- Tâches planifiées → Application de réservation (un seul bloc, découpé en modules) : Reprend les avis non envoyés et signale à l'équipe ceux qui restent à vérifier
Données
| Composant | Zone | Données conservées |
|---|---|---|
| Site des membres (adapté aux téléphones) | zone publique | Horaire des cours, Réservations et solde du membre, Coordonnées du membre |
| Espaces professeurs et équipe du studio | zone authentifiée | Listes de participants, Ajustements de solde, Rapport mensuel |
| Application de réservation (un seul bloc, découpé en modules) | zone interne | Règles de réservation et de soldes, Journal des ajustements et annulations |
| Tâches planifiées | zone interne | Échéances de cartes et d'abonnements |
| Service d'authentification géré | hors système (tiers) | Identifiants de connexion, Courriel du compte de tous les membres |
| Base de données relationnelle gérée | zone restreinte | Renseignements personnels (nom, courriel, téléphone, adresse), Historique des achats sans numéro de carte, Journal d'audit |
| Service de paiement par carte (page hébergée) | hors système (tiers) | Données de carte (chez le prestataire seulement), Jeton et résultat de paiement |
| Service de courriel transactionnel | hors système (tiers) | Adresse et contenu des avis |
| Hébergement géré en région canadienne | zone interne | Journaux d'application sans renseignements de carte, Secrets d'exploitation |
Lecture du schéma
Acteurs
- Membre du studio (utilisateur) — Environ 700 membres actifs (grand public) : consultent l'horaire, réservent, annulent, s'inscrivent en attente et achètent des forfaits.
- Professeur à la pige (personnel) — Une douzaine de professeurs : voient les participants de leurs cours seulement et peuvent annuler un de leurs cours. Second facteur d'accès.
- Réceptionniste (personnel) — Saisit au comptoir les réservations faites par téléphone et ajuste à la main le solde de séances d'un membre, avec motif.
- Équipe du studio (administration) (administration) — Gère les cours et l'horaire, consulte et exporte le rapport mensuel de fréquentation et de ventes. Second facteur d'accès.
- Prestataire de paiement par carte (système externe) — Encaisse sur sa page hébergée, renouvelle les abonnements, rembourse, et signale à l'application le résultat de chaque paiement.
- Service d'envoi de courriels (système externe) — Envoie confirmations, avis de place libérée, annulations de cours et reçus.
Composants
- Site des membres (adapté aux téléphones) (Interface) — Horaire de la semaine, réservation, annulation, liste d'attente, achat de forfaits, solde et historique du membre. Avertit clairement quand une annulation sera comptée.
- Espaces professeurs et équipe du studio (Interface) — Professeurs : participants de leurs cours et annulation d'un cours. Réceptionniste : saisie d'une réservation au comptoir et ajustement de solde avec motif. Équipe : gestion de l'horaire (création, modification, annulation des cours), rapport mensuel et export.
- Application de réservation (un seul bloc, découpé en modules) (Service) — Modules : horaire et cours, réservation (douze places, refus d'un cours plein), annulation (règle de douze heures), liste d'attente (avis simultané à tous les membres en attente, hypothèse à confirmer), forfaits et soldes (déduction, rétablissement, illimité), professeurs, réception, rapports, notifications. Applique les droits par rôle et par objet, valide toutes les entrées, tient le journal des gestes sensibles.
- Tâches planifiées (Service) — Dans l'application : expiration des cartes, suivi des renouvellements d'abonnement, avis différés et rapport mensuel. Aucun courtier de messages.
- Service d'authentification géré (Intégration) — Comptes, mots de passe, récupération de compte, limitation des tentatives, sessions ; second facteur obligatoire pour l'équipe et les professeurs. L'application garde les rôles. Détient la liste complète des membres : sa région de traitement se vérifie avant de le retenir.
- Base de données relationnelle gérée (Données) — Membres, cours, réservations, listes d'attente, forfaits, soldes, achats (jeton et résultat seulement), journal. Transactions pour la dernière place. Chiffrée au repos, sauvegardes du service géré, région canadienne.
- Service de paiement par carte (page hébergée) (Externe) — Encaisse sur sa propre page ; renvoie à l'application un résultat et un jeton (signalement signé). Gère le renouvellement d'abonnement et les remboursements. Aucun numéro de carte ne touche l'application ni les journaux.
- Service de courriel transactionnel (Externe) — Envoie confirmations, avis de place libérée, annulations de cours et reçus. Courriel seulement ; domaine d'envoi authentifié. Région de traitement à vérifier avant de le retenir.
- Hébergement géré en région canadienne (Infrastructure) — Exécute l'application, chiffre en transit, garde les secrets hors du code, tient journaux et alertes de base. Un environnement de test et un de production, déploiement scripté, mises à jour suivies.
Flux
- (1) Site des membres (adapté aux téléphones) → Service d'authentification géré (action d'une personne) : Connexion et création de compte ; le service émet une session.
- (2) Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) (appel) : Consultation de l'horaire, réservation, annulation, inscription en attente, demande d'achat.
- (3) Espaces professeurs et équipe du studio → Application de réservation (un seul bloc, découpé en modules) (appel) : Actions des professeurs, de la réceptionniste et de l'équipe, selon le rôle.
- (4) Application de réservation (un seul bloc, découpé en modules) → Service d'authentification géré (appel) : Vérification de la session et de l'identité à chaque requête.
- (5) Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée (appel) : Lectures et écritures transactionnelles ; la réservation et le décompte de séance se font dans une même transaction.
- (6) Application de réservation (un seul bloc, découpé en modules) → Service de paiement par carte (page hébergée) (appel) : Création d'une session de paiement ; le membre est redirigé vers la page hébergée.
- (7) Service de paiement par carte (page hébergée) → Application de réservation (un seul bloc, découpé en modules) (événement) : Résultat du paiement et jeton par signalement signé ; traitement idempotent avant activation du forfait.
- (8) Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel (événement) : Envoi des avis : confirmation, place libérée, cours annulé, reçu ; reprise bornée en cas d'échec.
- (9) Tâches planifiées → Application de réservation (un seul bloc, découpé en modules) (traitement planifié) : Expirations, renouvellements, avis différés et production du rapport mensuel.
- (10) Hébergement géré en région canadienne → Application de réservation (un seul bloc, découpé en modules) (appel) : Exécution de l'application ; journaux et alertes de base.
Parcours utilisateurs
- Acheter un forfait par carte (Membre du studio) — 1. Membre du studio → Site des membres (adapté aux téléphones) : Choisit une carte de dix séances ou l'abonnement mensuel illimité ; 2. Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) : Demande l'achat du forfait ; 3. Application de réservation (un seul bloc, découpé en modules) → Service de paiement par carte (page hébergée) : Prépare le paiement et redirige le membre vers la page du prestataire ; 4. Membre du studio → Service de paiement par carte (page hébergée) : Saisit sa carte sur la page du prestataire, jamais sur le site du studio ; 5. Service de paiement par carte (page hébergée) → Application de réservation (un seul bloc, découpé en modules) : Signale le résultat du paiement avec un jeton ; 6. [si le paiement est accepté] Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Enregistre l'achat et crédite le solde, une seule fois ; 7. [si le paiement est accepté] Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Envoie le reçu par courriel, après l'enregistrement de l'achat ; 8. Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Affiche le forfait activé, ou le refus du paiement sans rien créditer
- Réserver une place ou s'inscrire en attente (Membre du studio) — 1. Membre du studio → Site des membres (adapté aux téléphones) : Consulte l'horaire de la semaine et choisit un cours ; 2. Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) : Demande une place dans le cours ; 3. [si le cours compte moins de douze inscrits et que le membre a un forfait valide] Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Réserve la place et déduit une séance dans la même opération ; 4. [si la place a été réservée] Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Confirme la réservation, après son enregistrement ; 5. [si la place a été réservée] Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Envoie la confirmation par courriel ; 6. [si le cours est complet et que le membre choisit l'attente] Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Inscrit le membre sur la liste d'attente, par ordre d'arrivée ; 7. [si le membre n'a plus de séance ni d'abonnement valide] Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Indique que le forfait est épuisé et propose l'achat
- Annuler une place et aviser la liste d'attente (Membre du studio) — 1. Membre du studio → Site des membres (adapté aux téléphones) : Demande l'annulation de sa réservation ; 2. Site des membres (adapté aux téléphones) → Application de réservation (un seul bloc, découpé en modules) : Transmet la demande ; le site précise si la séance sera comptée ; 3. [si le cours commence dans plus de douze heures] Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Libère la place et rétablit la séance ; 4. [si le cours commence dans moins de douze heures] Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Libère la place, la séance reste comptée ; 5. Application de réservation (un seul bloc, découpé en modules) → Site des membres (adapté aux téléphones) : Confirme l'annulation, après son enregistrement ; 6. [si une liste d'attente existe pour ce cours] Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Avise par courriel les membres en attente qu'une place est libre ; 7. [si la place est encore libre] Membre du studio → Site des membres (adapté aux téléphones) : Le membre avisé réserve la place par une réservation normale
- Annuler un cours et aviser les inscrits (Professeur à la pige) — 1. Professeur à la pige → Espaces professeurs et équipe du studio : Ouvre la liste de ses participants et choisit d'annuler son cours ; 2. Espaces professeurs et équipe du studio → Application de réservation (un seul bloc, découpé en modules) : Demande l'annulation ; seul le professeur du cours peut l'annuler ; 3. Application de réservation (un seul bloc, découpé en modules) → Base de données relationnelle gérée : Marque le cours annulé et rétablit les séances des inscrits ; 4. Application de réservation (un seul bloc, découpé en modules) → Espaces professeurs et équipe du studio : Confirme l'annulation, après son enregistrement ; 5. Application de réservation (un seul bloc, découpé en modules) → Service de courriel transactionnel : Envoie un avis par courriel à chaque membre inscrit ; 6. Tâches planifiées → Application de réservation (un seul bloc, découpé en modules) : Reprend les avis non envoyés et signale à l'équipe ceux qui restent à vérifier
Garanties de fonctionnement
- Un forfait payé est activé une seule fois, et jamais sans paiement — comment : L'achat est créé à l'état « en attente » avant la redirection. Chaque signalement du prestataire est vérifié (signature) puis traité avec l'identifiant de transaction comme clé d'idempotence, unique en base : un doublon ne crédite rien de plus. Le crédit du solde et le passage à « payé » se font dans une même écriture, avant tout reçu ou accusé. — si le résultat d'un tiers est inconnu : Si le signalement est en retard, perdu ou absent, l'achat reste « à vérifier » ; une tâche planifiée interroge le prestataire sur cette transaction avant toute nouvelle tentative, si son service le permet. Sinon, ou si le doute persiste, la réceptionniste vérifie sur le portail du prestataire. Aucune reprise épuisée ne vaut preuve d'un paiement non fait. — composants : Application de réservation (un seul bloc, découpé en modules), Service de paiement par carte (page hébergée), Base de données relationnelle gérée, Tâches planifiées (hypothèse)
- Jamais plus de douze inscrits par cours, ni séance déduite deux fois — comment : La réservation et la déduction de séance s'écrivent dans une seule transaction qui compte les places et verrouille le cours et le solde du membre. Une contrainte d'unicité (membre, cours) empêche une double réservation, et le solde ne peut descendre sous zéro. La confirmation à l'écran et par courriel suit l'écriture. — si le résultat d'un tiers est inconnu : Si la réponse se perd (coupure, délai dépassé), le membre ne voit pas de confirmation : il consulte « mes réservations », qui reflète l'état réel, et un nouvel essai n'a pas d'effet double grâce à la contrainte d'unicité. Aucun tiers n'est en cause. — composants : Application de réservation (un seul bloc, découpé en modules), Base de données relationnelle gérée (retenu)
- Chaque changement de solde est unique, explicable et daté — comment : Le rétablissement d'une séance, à l'annulation d'une place comme à celle d'un cours, se lie à la réservation annulée et ne se fait qu'une fois (changement d'état conditionnel dans la même transaction). Les ajustements de la réceptionniste s'écrivent dans le journal (qui, quand, pourquoi, ancien et nouveau solde) avant d'être confirmés à l'écran. La règle de douze heures se calcule côté serveur, à l'heure locale du studio. — si le résultat d'un tiers est inconnu : Si l'écriture d'un ajustement n'est pas confirmée, la réceptionniste relit le solde et le journal avant de recommencer, pour ne pas ajuster deux fois. Aucun tiers n'est en cause. — composants : Application de réservation (un seul bloc, découpé en modules), Base de données relationnelle gérée, Espaces professeurs et équipe du studio (retenu)
- Aucun avis envoyé pour un fait non enregistré, et chaque avis dû est suivi — comment : Les avis (confirmation, place libérée, cours annulé, reçu) sont inscrits en base dans la même écriture que le fait qu'ils annoncent, puis envoyés. Chaque avis porte une clé (événement, destinataire) pour n'être envoyé qu'une fois. Les reprises sont bornées et planifiées. — si le résultat d'un tiers est inconnu : Si le service de courriel ne répond pas ou si sa réponse est perdue, l'avis passe à « à vérifier » : on cherche d'abord chez le service s'il a été remis, si celui-ci le permet, sans renvoyer à l'aveugle. Sinon, l'équipe voit la liste des avis douteux et joint les membres concernés. Un doublon éventuel est possible et accepté plutôt qu'un avis perdu. — composants : Application de réservation (un seul bloc, découpé en modules), Service de courriel transactionnel, Base de données relationnelle gérée, Tâches planifiées (hypothèse)
- Un abonnement n'est ni coupé ni prolongé sans preuve de paiement — comment : Le prestataire renouvelle l'abonnement par jeton et signale chaque échéance ; le signalement est traité comme un achat (clé d'idempotence par échéance). Une tâche planifiée rapproche les échéances attendues et les paiements reçus. — si le résultat d'un tiers est inconnu : Si le résultat d'un renouvellement est inconnu, l'abonnement garde son état « à vérifier » avec un court délai de grâce, sans coupure automatique. La vérification se fait chez le prestataire, puis, au besoin, par l'équipe auprès du membre. — composants : Tâches planifiées, Service de paiement par carte (page hébergée), Application de réservation (un seul bloc, découpé en modules), Base de données relationnelle gérée (hypothèse)
Intégrations
- Service de paiement par carte : Encaissement par page hébergée, abonnement récurrent par jeton, remboursements ; signalement signé vers l'application.
- Service de courriel transactionnel : Avis de réservation, de liste d'attente, d'annulation de cours et reçus.
- Service d'authentification géré : Comptes, sessions, second facteur et récupération de compte, sans mots de passe stockés par l'application.
Contraintes
- Hébergement, base, sauvegardes et journaux en région canadienne (préférence négociable, retenue par défaut).
- La région de traitement des services d'authentification, de courriel et de paiement se vérifie avant de les retenir ; toute communication hors du Québec appelle une évaluation préalable (Loi 25).
- Un seul bloc applicatif, sans microservice ni courtier de messages.
- Sauvegardes du service géré ; durée de rétention et objectifs de reprise supposés (quelques jours, perte d'au plus une journée), à confirmer avec vous.
- Un environnement de test et un de production.
- La règle de douze heures se calcule à l'heure locale du studio, côté serveur.
- Chaque signalement de paiement est traité une seule fois (clé d'idempotence) ; toute reprise d'appel est bornée.
- Loi 25 et PCI à considérer : aucune conformité n'est affirmée ; les contrôles se vérifient hors du dossier.
- Un membre ne voit que ses propres réservations, soldes et achats ; contrôle par objet côté serveur à chaque requête.
- Un professeur ne voit que les participants de ses cours et peut annuler seulement ses propres cours.
- La réceptionniste ajuste un solde ou saisit une réservation ; chaque ajustement consigne qui, quand et pourquoi.
- Les administrateurs de l'équipe et les professeurs ont un second facteur ; les accès d'administration de l'hébergement sont séparés de ceux de l'application.
- Aucun numéro de carte, cryptogramme ni piste n'entre dans l'application, la base ou les journaux.
- Base et sauvegardes non exposées sur Internet ; accès par l'application seulement, secrets hors du code.
Où l'IA intervient
Aucune fonction de ce dossier ne gagnerait vraiment à utiliser l'IA : la solution n'en emploie pas.
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
| Couche | Choix | Statut | Pourquoi ce choix pour ce dossier |
|---|---|---|---|
| Langage et exécution | Python, version à support long, exécuté sur la plateforme d'hébergement gérée Écarté : TypeScript sur Node.js ; Ruby |
hypothèse | Langage répandu et bien documenté. Les règles du studio (douze places, annulation à douze heures, décompte des séances) sont des calculs transactionnels, sans besoin de performance particulier pour 1 500 à 2 000 réservations par mois. |
| Cadriciel applicatif | Cadriciel web complet de type Django, en une seule application découpée en modules Écarté : Cadriciel TypeScript de type Next.js ; Rails |
hypothèse | Un seul bloc applicatif suffit au volume et à la capacité d'une personne. Il fournit migrations, rôles, protections web courantes (injection, requêtes falsifiées) et une interface d'administration réutilisable pour la réceptionniste, ce qui couvre une bonne part des contrôles OWASP Top 10:2025 sans code écrit à la main. |
| Interface utilisateur | Pages rendues côté serveur, gabarits adaptés aux téléphones, composants libres standard, peu de JavaScript Écarté : Application monopage avec cadriciel JavaScript ; Application mobile native (hors périmètre) |
hypothèse | Les trois espaces (membres, professeurs, équipe) sont des formulaires, des listes et un horaire hebdomadaire. Une application monopage n'apporterait rien ici. Les composants standards facilitent la visée WCAG 2.2 AA sur inscription, connexion, réservation et paiement. |
| Base de données | Base relationnelle PostgreSQL gérée, en région canadienne, chiffrée au repos Écarté : Base de données NoSQL ; Base locale sur le serveur d'application |
hypothèse | La dernière place d'un cours et le décompte de séance doivent se faire dans une même transaction. Données structurées (membres, cours, réservations, soldes, journal) et rapport mensuel par requêtes. Volume modeste. |
| File de tâches de fond | Commandes planifiées par le planificateur de la plateforme d'hébergement, sans courtier de messages Écarté : File de tâches avec courtier de messages ; Fonctions sans serveur déclenchées par horaire |
hypothèse | Tâches de fond peu nombreuses : expiration des cartes, suivi des renouvellements, avis différés, rapport mensuel. Envois de courriel avec reprise bornée. À ce volume, un courtier de messages ne se justifie pas. |
| Authentification | Service d'authentification géré (comptes, récupération, limitation des tentatives, second facteur pour l'équipe et les professeurs) ; Auth0 supposé pour le chiffrage Écarté : Authentification intégrée au cadriciel avec extension de second facteur, hébergée avec l'application au Canada ; Connexion par un fournisseur d'identité tiers |
à confirmer | Trois publics, des achats liés aux comptes : l'application ne stocke pas de mots de passe. Ce fournisseur détiendrait les identifiants et courriels de tous les membres : sa région de traitement se vérifie avant de le retenir, et une communication hors du Québec appelle une évaluation préalable (Loi 25). Dépend de la réponse sur les fournisseurs et le Canada. |
| Paiement | Prestataire de paiement par carte reconnu, page de paiement hébergée par lui (par exemple Stripe Checkout, nom donné à titre d'hypothèse), jetons et signalements signés Écarté : Champs de paiement intégrés à nos pages (périmètre PCI élargi, écarté) ; Paiement au comptoir seulement |
à confirmer | Aucun numéro de carte ne touche l'application, la base ni les journaux, ce qui réduit le périmètre PCI du studio (SAQ A supposé, à confirmer avec son acquéreur). Le prestataire gère aussi renouvellement d'abonnement et remboursements. Le choix dépend des réponses sur l'abonnement et sur les fournisseurs. |
| Courriel et notifications | Service de courriel transactionnel avec domaine d'envoi authentifié, courriel seulement Écarté : Serveur de courriel exploité par le studio ; Messages texte (+15 à 35 h, si demandés) |
à confirmer | Confirmations, places libérées, cours annulés et reçus : environ 3 200 courriels par mois. Traitement canadien préféré si possible, à vérifier avant de retenir le fournisseur. Les messages texte ne sont pas retenus tant que le studio ne les demande pas. |
| Observabilité | Journaux et alertes de la plateforme d'hébergement et de la base gérée, sans outil d'observabilité dédié Écarté : Plateforme d'observabilité externe ; Service de suivi d'erreurs tiers |
hypothèse | Un seul bloc applicatif et un faible volume. Les journaux n'écrivent jamais de donnée de carte. Alertes sur erreurs d'application, échecs de signalement de paiement et échecs d'envoi de courriel. |
| Intégration continue | Dépôt de code avec revue des changements, intégration continue lancée sur les demandes de fusion et à la demande, déploiement scripté déclenché manuellement Écarté : Intégration continue à chaque poussée ; Déploiement continu automatique vers la production |
hypothèse | Suite de tests complète jouée en local avant chaque poussée, puis sur la demande de fusion : cela limite la consommation de minutes de calcul. Le déploiement manuel convient à une exploitation par une personne ou un fournisseur externe. Secrets hors du dépôt. |
| Tests | Tests automatisés (règles de réservation, annulation à douze heures, soldes, droits par rôle), tests de concurrence, vérifications d'accessibilité automatisées et au clavier, passage au lecteur d'écran sur les parcours essentiels, recette par le studio Écarté : Tests manuels seulement ; Tests de bout en bout complets sur navigateur |
hypothèse | Les risques principaux sont la dernière place réservée en double, le signalement de paiement traité deux fois et les droits par objet : des tests ciblés les couvrent. L'accessibilité vise WCAG 2.2 AA sur inscription, connexion, réservation et paiement. |
| Outillage de développement | Dépendances verrouillées, analyse automatique des vulnérabilités avec mise à jour suivie, gestion des secrets de la plateforme Écarté : Revue manuelle périodique des dépendances |
hypothèse | Un site avec comptes et paiement doit suivre sa chaîne d'approvisionnement logicielle (OWASP A03). Suivi léger, proportionné à une seule application exploitée par une personne ou un fournisseur externe. |
Hébergement
- Résidence : la préférence « Au Canada » est négociable. Application, base, sauvegardes et journaux restent en région canadienne par défaut. Le lieu de traitement des services d'authentification, de courriel et de paiement reste à confirmer avec vous.
- Loi 25 : toute communication de renseignements hors du Québec, y compris vers ces trois services, appelle une évaluation préalable. Aucune conformité n'est affirmée.
- Paiement : la fiche du corpus sur le paiement par carte n'est pas vérifiée, donc le questionnaire SAQ A reste une hypothèse. L'attestation est celle du studio, non du logiciel.
- Les noms de produits cités sont des hypothèses de chiffrage, non des engagements ; ils se confirment avec vous après les réponses sur l'outil existant, l'abonnement et les fournisseurs.
- Sauvegardes : celles du fournisseur d'hébergement, sans solution distincte. La rétention et les objectifs de reprise se fixent avec vous ; une rétention plus longue ajoute un faible coût récurrent.
- Pas de courtier de messages ni de microservice : un seul bloc applicatif suffit au volume déclaré.
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 — Horaire de la semaine
(Accueil) — Page d'entrée : les cours de la semaine avec places restantes. Un seul appel à l'action : réserver un cours.
Éléments cadrés servis : E-1, E-2 -
Écran 2 — Réserver ce cours
(Détail) — Fiche d'un cours : professeur, heure, places (12 au plus), règle d'annulation jusqu'à 12 h avant. Action : réserver ma place.
Éléments cadrés servis : E-2, E-4, E-7, E-19 -
Écran 3 — Cours complet : liste d'attente
(Formulaire) — Quand le cours est complet, le membre s'inscrit en attente. Un avis par courriel est envoyé à tous les membres en attente, sans réservation automatique.
Éléments cadrés servis : E-5, E-27, E-13 -
Écran 4 — Votre place est réservée
(Confirmation) — Confirme la réservation, la séance déduite du solde et la date limite d'annulation. Rappelle qu'au-delà, la séance est comptée.
Éléments cadrés servis : E-2, E-4, E-7, E-13 -
Écran 5 — Choisir un forfait
(Liste) — Présente les forfaits de séances et l'abonnement mensuel. Action : acheter le forfait choisi.
Éléments cadrés servis : E-6, E-28, E-16 -
Écran 6 — Paiement du forfait
(Formulaire) — Récapitulatif de l'achat puis passage vers la page de paiement hébergée par le prestataire. Aucun numéro de carte n'est conservé.
Éléments cadrés servis : E-6, E-12, E-16, E-17 -
Écran 7 — Connexion à mon compte
(Authentification) — Accès par compte personnel selon le rôle : membre, professeur ou équipe. Création de compte possible, avec mention sur les renseignements personnels.
Éléments cadrés servis : E-11, E-15, E-17 -
Écran 8 — Mes séances et réservations
(Détail) — Le membre voit son solde, ses réservations à venir et ses attentes. Action principale : annuler une réservation dans le délai.
Éléments cadrés servis : E-4, E-7, E-11, E-5 -
Écran 9 — Espace professeur
(Liste) — Le professeur voit ses cours, la liste des participants et peut annuler un cours. Action : annuler un cours.
Éléments cadrés servis : E-8, E-11, E-5 -
Écran 10 — Saisie au comptoir
(Recherche) — La réceptionniste cherche un membre, consulte son solde et réserve une place par téléphone. Action : réserver pour le membre.
Éléments cadrés servis : E-9, E-11, E-7, E-4 -
Écran 11 — Gestion de l'horaire
(Formulaire) — L'équipe crée, modifie ou annule des cours. Action : ajouter un cours.
Éléments cadrés servis : E-3, E-11, E-12 -
Écran 12 — Rapport du mois
(Tableau de bord) — Fréquentation par cours et ventes de forfaits pour le mois choisi, à l'usage de l'équipe.
Éléments cadrés servis : E-10, E-11, E-19
Registre des décisions d'architecture
Chaque décision d'architecture du dossier est consignée au format MADR (Markdown Architectural Decision Records) : son contexte, les options envisagées, la décision, ses conséquences, ses hypothèses, les vérifications prévues et les références d'architecture sur lesquelles elle s'appuie.
Décisions proposées par l'analyse et maintenues à la revue critique : elles orientent l'architecture chiffrée et se confirment avec vous avant la réalisation.
DA-1 — Construire l'application plutôt qu'adapter une plateforme ou acheter un logiciel de réservation
Contexte
Règles propres au studio (douze places, annulation à douze heures, liste d'attente, décompte de cartes et d'abonnement) et aucun outil à conserver selon l'hypothèse retenue.
- E-1 — Remplacer l'horaire papier et les courriels par un site de réservation
- E-2 — Consulter l'horaire de la semaine et réserver une place (12 au plus par cours)
- E-7 — Déduction automatique des séances à chaque réservation
- E-26 — Socle construit à neuf : comptes, horaire et soldes
- Q-1 — Utilisez-vous aujourd'hui un outil existant (liste de membres, logiciel de réservation) dont il faudrait conserver ou brancher les données, ou tout se construit-il à neuf ?
Options envisagées
- Adapter une plateforme du marché avec quelques composants spécifiques — Possible si une plateforme couvre déjà forfaits et liste d'attente ; aucune n'est nommée au dossier.
- Acheter un logiciel complet et adapter le processus à l'outil — Non retenu par défaut : le questionnaire parle d'un outil du marché, mais la description ne décrit qu'un horaire papier. À rouvrir selon la réponse sur l'outil existant.
Décision
Construire une application sur mesure, appuyée sur des services gérés (paiement, courriel, authentification, hébergement). Le sur-mesure ne porte que sur les règles du studio ; tout le reste vient de services du marché. C'est le choix par défaut de la fiche, qui n'est pas vérifiée : présenté comme hypothèse.
Conséquences
- Compromis : Règles exactes du studio contre un coût de réalisation initial et une maintenance à assurer.
- Compromis : Un abonnement de logiciel du marché serait récurrent mais éviterait la réalisation.
- Risque : Un logiciel du marché couvrant l'essentiel du besoin pourrait coûter moins cher à l'échelle de 700 membres.
Hypothèses
- Aucun outil existant à conserver ni à brancher ; tout est construit à neuf.
Vérifications prévues
- Faire confirmer par le studio qu'aucun outil actuel ne doit être conservé.
- Comparer sommairement un logiciel de réservation du marché avant la décision du studio.
Références
- Décision type — acheter ou construire : application sur mesure, plateforme du marché adaptée, ou logiciel complet acheté (v1 — référence à vérifier)
DA-2 — Une seule application découpée en modules, sans microservice
Contexte
Une personne à la réalisation, échéance de trois mois, 1 500 à 2 000 réservations par mois, règles transactionnelles liées (réservation, solde, annulation).
- E-18 — Échéance visée : dans les trois mois
- E-19 — Environ 700 membres actifs, 1 500 à 2 000 réservations par mois
- E-2 — Consulter l'horaire de la semaine et réserver une place (12 au plus par cours)
- E-7 — Déduction automatique des séances à chaque réservation
Options envisagées
- Microservices — Aucune équipe multiple ni besoin d'échelle différencié ; complexité d'exploitation disproportionnée.
- Assemblage de services gérés autour d'un noyau léger — Appliqué en partie pour le paiement, le courriel et l'authentification ; les règles de réservation restent dans le noyau.
Décision
Monolithe modulaire : modules horaire, réservation, forfaits et soldes, professeurs, réception, rapports, notifications, dans un seul déploiement. Les tâches planifiées vivent dans l'application ; aucun courtier de messages. Frontières de modules documentées pour une extraction éventuelle.
Conséquences
- Compromis : Simplicité, transactions locales et coût réduit contre mise à l'échelle sélective moins fine.
- Risque : Modules qui se mélangent avec le temps si les frontières ne sont pas tenues.
Hypothèses
- Le volume reste modeste ; la mise à l'échelle se fait en dupliquant l'application.
Vérifications prévues
- Revoir les frontières de modules à la recette.
Références
- Décision type — style d'architecture : monolithe modulaire, microservices ou assemblage de services gérés (v3 — référence à vérifier)
- Monolithe modulaire — une application déployée d'un bloc, structurée en modules (v2)
DA-3 — Base de données relationnelle gérée pour les données du studio
Contexte
Données structurées et liées (membres, cours, réservations, soldes, achats) avec une limite de douze places à garantir par transaction.
- E-2 — Consulter l'horaire de la semaine et réserver une place (12 au plus par cours)
- E-7 — Déduction automatique des séances à chaque réservation
- E-10 — Rapport mensuel : fréquentation par cours et ventes de forfaits
- E-19 — Environ 700 membres actifs, 1 500 à 2 000 réservations par mois
- E-30 — Sauvegardes du service géré ; rétention et objectifs de reprise à confirmer
- Q-6 — Combien de temps faut-il pouvoir remonter dans les sauvegardes (par exemple pour corriger un solde faussé découvert après une semaine) et quelle perte de données maximale acceptez-vous après un incident ?
Options envisagées
- Base documentaire — Peu de gain : les données sont fortement liées et le rapport mensuel demande des agrégats.
- Stockage clé-valeur géré — Aucun profil d'accès à très fort débit ; inutile à ce volume.
- Sauvegarde distincte du service géré — Non retenue à ce stade : les sauvegardes du fournisseur sont l'hypothèse, à réexaminer selon la rétention que vous souhaitez.
Décision
Base relationnelle gérée, chiffrée au repos, en région canadienne, avec migrations de schéma versionnées. Sauvegardes automatiques du service géré ; rétention et objectifs de reprise supposés (quelques jours, perte d'au plus une journée) et à confirmer avec vous. Un essai de restauration est fait avant la mise en service.
Conséquences
- Compromis : Intégrité et transactions contre mise à l'échelle horizontale des écritures, sans objet ici.
- Compromis : Rétention courte par défaut contre coût de stockage plus élevé si elle est allongée.
- Risque : Sauvegarde jamais restaurée en pratique.
- Risque : Une erreur de solde découverte après la fenêtre de rétention ne serait plus récupérable.
Hypothèses
- Rétention standard du service géré et perte maximale d'une journée, non déclarées : à valider avec le studio.
Vérifications prévues
- Restaurer une sauvegarde dans l'environnement de test avant la mise en production.
- Faire confirmer avec vous la durée de rétention et les objectifs de reprise.
Références
- Décision type — stockage principal des données : base relationnelle, base documentaire ou stockage clé-valeur géré (v2 — référence à vérifier)
- Base relationnelle transactionnelle comme stockage principal (v2)
DA-4 — Hébergement, base, sauvegardes et journaux en région canadienne
Contexte
Résidence au Canada déclarée comme préférence négociable ; renseignements personnels et paiement ; client au Québec.
- E-14 — Hébergement des données au Canada (préférence négociable)
- E-15 — Renseignements personnels : Loi 25 à considérer
- Exigence de qualité : Résidence des données
- Q-4 — Si le fournisseur d'authentification, de courriel ou de paiement que nous retenons traite des données hors du Canada, le studio l'accepte-t-il, ou préférez-vous des services avec traitement canadien ?
Options envisagées
- Hébergement au Québec, chaîne complète — Aucune obligation de résidence au Québec n'est déclarée ; limiterait le choix de services.
- Hébergement hors du Canada — Contredit la préférence déclarée ; possible en variante chiffrée seulement si le studio l'accepte.
Décision
Hébergement au Canada, région canadienne vérifiée, pour l'application, la base, les sauvegardes et les journaux. Aucune obligation de résidence au Québec n'est déclarée. Une préférence négociable se respecte par défaut ; une variante hors Canada pourra être chiffrée si le studio l'assouplit. Les services d'authentification (qui détient la liste des membres), de paiement et de courriel sont à inventorier : leur région de traitement se vérifie avant de les retenir.
Conséquences
- Compromis : Choix de services plus étroit contre résidence cohérente des données et moins d'évaluations de communication hors Québec.
- Risque : Les fournisseurs d'authentification, de paiement et de courriel peuvent traiter des données hors du Canada : une évaluation préalable est à examiner selon la Loi 25.
Hypothèses
- Le studio accepte un prestataire de paiement reconnu même si une partie du traitement est hors Canada.
Vérifications prévues
- Vérifier la région de chaque service (base, sauvegardes, journaux, authentification, courriel, paiement) avant de le retenir.
Références
- Décision type — lieu d'hébergement des données : au Québec, au Canada ou ailleurs, selon la nature des données (v3 — référence à vérifier)
- Classification, chiffrement et résidence des données (v2)
- Renseignements personnels au Canada et au Québec — Loi 25, LPRPDE, principes des autorités sur l'IA (v1)
DA-5 — Authentification par un fournisseur d'identité géré, avec second facteur pour l'équipe et les professeurs
Contexte
Public externe (membres) et personnel avec rôles sensibles ; données personnelles et gestes sur les soldes.
- E-11 — Comptes personnels et rôles (membre, professeur, équipe)
- Exigence de qualité : Sécurité
- Exigence de qualité : Confidentialité et renseignements personnels
Options envisagées
- Comptes gérés par l'application, second facteur pour les rôles sensibles — Convient à un volume modeste, mais l'authentification maison est sous-estimée et demande plus de vérification.
- Authentification unique par l'annuaire de l'organisation — Aucun annuaire commun ; les membres sont des externes.
Décision
Fournisseur d'identité géré : comptes, mots de passe, récupération de compte, limitation des tentatives et sessions. Second facteur obligatoire pour l'équipe et les professeurs ; l'application garde les rôles et applique les droits par objet. Fiche non vérifiée : hypothèse.
Conséquences
- Compromis : Moins de code sécuritaire à écrire contre une dépendance à un fournisseur et un coût récurrent.
- Risque : Récupération de compte qui contourne le second facteur.
- Risque : Le fournisseur détient courriels et identifiants de tous les membres : son lieu de traitement est à examiner.
Hypothèses
- Le second facteur pour les membres reste facultatif.
Vérifications prévues
- Tester récupération de compte, expiration et révocation de session.
- Vérifier la région de traitement du fournisseur avant de le retenir.
Références
- Décision type — authentification : comptes intégrés à l'application, fournisseur d'identité géré ou annuaire de l'organisation (v2 — référence à vérifier)
- Authentification et gestion des identités — NIST SP 800-63-4 (v2)
DA-6 — Paiement par page hébergée chez un prestataire certifié
Contexte
Vente de cartes et d'abonnement par carte ; numéros de carte déclarés dans les natures de données ; volonté de réduire le périmètre PCI.
- E-6 — Vente de forfaits payables par carte sur le site
- E-12 — Intégration d'un service de paiement par carte (page hébergée)
- E-16 — Paiement par carte : périmètre réduit, aucun numéro de carte conservé
- E-28 — Abonnement mensuel renouvelé automatiquement par le prestataire de paiement
- Q-2 — L'abonnement mensuel se renouvelle-t-il automatiquement sur la carte du membre ? Quelle durée de validité pour une carte de dix séances, et quelles règles de remboursement ?
Options envisagées
- Composants de paiement du prestataire intégrés à la page — Élargit le périmètre de conformité sans besoin démontré.
- Paiement hors de la solution (facture, virement, terminal) — Contredit le besoin d'achat en ligne et de déduction automatique.
Décision
Page de paiement hébergée par le prestataire : l'application ne reçoit qu'un jeton et un résultat par signalement signé, jamais un numéro de carte, et n'en journalise aucun. Renouvellement d'abonnement et remboursements passent par le prestataire. Questionnaire SAQ A supposé, à confirmer avec l'acquéreur du studio ; la conformité reste celle du studio. Fiches non vérifiées : hypothèse.
Conséquences
- Compromis : Périmètre et coût de conformité réduits contre une maîtrise moindre du parcours de paiement et des frais par vente.
- Risque : Questionnaire applicable non confirmé.
- Risque : Signalement de paiement en double ou perdu.
Hypothèses
- Le studio est le commerçant ; renouvellement automatique par jeton.
Vérifications prévues
- Confirmer le questionnaire avec l'acquéreur.
- Vérifier que les journaux n'écrivent aucune donnée de carte.
Références
- Décision type — paiement en ligne : page de paiement hébergée par le prestataire, composants intégrés du prestataire ou paiement hors de la solution (v2 — référence à vérifier)
- Paiement par carte — PCI DSS et périmètre réduit par page de paiement hébergée chez le prestataire (v2 — référence à vérifier)
DA-7 — Avis aux membres par courriel transactionnel seulement
Contexte
Liste d'attente, annulation de cours, confirmations et reçus ; seul un service de courriel est déclaré.
- E-13 — Intégration d'un service d'envoi de courriels transactionnels
- E-5 — Liste d'attente avec avis par courriel
- E-8 — Espace professeur : participants et annulation de cours
- E-24 — Application mobile native et notifications par message texte
- Q-9 — Les avis aux membres se font-ils par courriel seulement, ou souhaitez-vous aussi des messages texte ?
Options envisagées
- Texto par une passerelle — Utile pour un rappel de dernière minute ; service, consentement et frais récurrents en plus, non déclarés.
- Messages dans l'application — Un membre en attente ne se connecte pas forcément à temps.
Décision
Courriel transactionnel par un service spécialisé, domaine d'envoi authentifié. Messages texte exclus par défaut : branche conditionnelle chiffrée à part si le studio le demande, jamais un envoi doublé.
Conséquences
- Compromis : Simple et peu coûteux contre un délai de lecture variable pour une place libérée.
- Risque : Courriel en pourriel ou en retard : une place libérée peut être prise par un autre membre.
Hypothèses
- Les membres ont tous un courriel.
Vérifications prévues
- Tester la délivrabilité du domaine d'envoi avant l'ouverture.
Références
- Décision type — notifications aux utilisateurs : courriel transactionnel, texto, notification mobile ou messages dans l'application (v2 — référence à vérifier)
DA-8 — Site Web adaptatif aux téléphones, sans application mobile
Contexte
Public grand public qui réserve et paie ; aucun besoin de hors-ligne, de capteurs ni de magasin d'applications.
- E-24 — Application mobile native et notifications par message texte
- E-31 — Accessibilité visée : WCAG 2.2 niveau AA sur les parcours essentiels
- E-2 — Consulter l'horaire de la semaine et réserver une place (12 au plus par cours)
Options envisagées
- Application Web progressive installable — Pertinente seulement si des notifications poussées sont souhaitées ; non demandé.
- Native multiplateforme (une base de code) — Aucune exigence de magasin ; coût disproportionné.
Décision
Site Web adaptatif ; accessibilité visée WCAG 2.2 niveau AA sur inscription, connexion, réservation et paiement, vérifiée par outils automatisés, tests au clavier et avec un lecteur d'écran.
Conséquences
- Compromis : Coût minimal contre une présence moindre sur l'écran d'accueil du téléphone.
- Risque : Niveau AA non attesté ; correctifs coûteux si l'accessibilité vient en fin de projet.
Hypothèses
- Le studio n'est pas un organisme public ; le niveau AA est un choix.
Vérifications prévues
- Vérifier les parcours essentiels au clavier et avec un lecteur d'écran.
Références
- Décision type — application mobile : site adaptatif, application Web progressive ou native (v1 — référence à vérifier)
- Accessibilité des sites et applications Web — WCAG 2.2 et standard québécois SGQRI 008 3.0 (v2)
DA-9 — Intégrations paiement et courriel : appels documentés, signalements signés, reprises bornées
Contexte
Deux services externes sur le chemin de la réservation et de l'achat ; panne ou doublon possible.
- E-12 — Intégration d'un service de paiement par carte (page hébergée)
- E-13 — Intégration d'un service d'envoi de courriels transactionnels
- E-28 — Abonnement mensuel renouvelé automatiquement par le prestataire de paiement
Options envisagées
- Échange asynchrone (file, événements, rappel du tiers) — Retenu seulement pour le signalement de paiement ; une file dédiée est disproportionnée à ce volume.
- Saisie manuelle assumée (repli) — Repli de la réceptionniste en cas de panne du paiement, pas mode normal.
Décision
Appels d'API documentés et synchrones pour créer une session de paiement et envoyer un courriel, avec délai d'attente explicite et reprise bornée. Le résultat de paiement arrive par signalement signé, traité une seule fois (clé d'idempotence), avec un rapprochement planifié. Un échec de courriel n'annule jamais une réservation ; il se rejoue par tâche planifiée. Pas de courtier de messages.
Conséquences
- Compromis : Peu de pièces à exploiter contre des reprises à concevoir avec soin.
- Risque : Forfait activé deux fois ou non activé malgré le paiement.
Hypothèses
- Les deux prestataires offrent une API et des signalements signés stables.
Vérifications prévues
- Tester signalement en double, en retard et manquant.
- Valider la signature de chaque signalement reçu.
Références
- Décision type — intégration avec les systèmes existants : API synchrone, échange asynchrone, fichiers planifiés ou saisie manuelle (v2 — référence à vérifier)
- Intégrations par API explicites et contrats versionnés (v3)
- Résilience des appels externes — délai, reprise bornée, disjoncteur, cloison, idempotence (v1)
- Sécurité des API — OWASP API Security Top 10 (2023) (v1)
DA-10 — Réservation, décompte et annulation dans une même transaction
Contexte
Douze places au plus, déduction automatique de séances, annulation avec règle de douze heures, ajustements manuels.
- E-2 — Consulter l'horaire de la semaine et réserver une place (12 au plus par cours)
- E-4 — Annulation jusqu'à 12 h avant le cours ; au-delà, la séance est comptée
- E-7 — Déduction automatique des séances à chaque réservation
- E-9 — Outils de la réceptionniste : solde et réservation par téléphone
Options envisagées
- Contrôle côté interface seulement — Insuffisant : deux membres peuvent réserver la dernière place en même temps.
- File d'attente d'opérations par cours — Complexité inutile à ce volume.
Décision
Réservation et décompte de séance dans une même transaction avec verrou sur le cours, pour garantir la limite de douze places. Règle de douze heures calculée côté serveur à l'heure locale du studio. Chaque ajustement de solde ou saisie au comptoir est journalisé (qui, quand, pourquoi). L'abonnement illimité n'est pas décompté.
Conséquences
- Compromis : Cohérence garantie contre un léger verrouillage à l'ouverture des inscriptions.
- Risque : Règles de forfaits non arrêtées : reprises de règles de solde en cours de réalisation.
Hypothèses
- Délai d'annulation identique pour tous les cours.
Vérifications prévues
- Test de réservations simultanées sur la dernière place.
- Test des passages à l'heure d'été.
Références
- Base relationnelle transactionnelle comme stockage principal (v2)
DA-11 — Liste d'attente par ordre d'arrivée, avis sans réservation automatique
Contexte
La description prévoit un avis par courriel dès qu'une place se libère, sans préciser d'inscription automatique ni qui est avisé.
- E-5 — Liste d'attente avec avis par courriel
- E-27 — Liste d'attente : avis à tous les membres en attente, sans réservation automatique
- Q-3 — Quand une place se libère, tous les membres en attente sont-ils avisés en même temps (le premier qui réserve l'obtient), ou seulement le suivant, avec un délai pour confirmer avant de passer au membre suivant ?
Options envisagées
- Avis au suivant seulement, avec délai de confirmation — Évite la course entre membres mais ajoute des échéances automatiques et des relances (+10 à 25 h).
- Réservation automatique du premier de la liste — Plus de règles de solde et de délai de réponse ; non demandée.
Décision
Hypothèse retenue : tous les membres en attente sont avisés en même temps, dans l'ordre d'arrivée des inscriptions ; la place se prend par réservation normale, sans décompte ni paiement automatique. L'avis au suivant seulement, avec un délai de confirmation, est une variante chiffrée à part ; la réservation automatique du premier en est une autre.
Conséquences
- Compromis : Règle simple contre une course possible entre membres avisés.
- Risque : Plusieurs avisés pour une seule place : insatisfaction.
Hypothèses
- Règle d'avis simultané à tous les membres en attente, à confirmer avec vous.
Vérifications prévues
- Faire confirmer la règle d'avis avec vous et la valider avec la réceptionniste.
Références
- Décision type — notifications aux utilisateurs : courriel transactionnel, texto, notification mobile ou messages dans l'application (v2 — référence à vérifier)
- Base relationnelle transactionnelle comme stockage principal (v2)
DA-12 — Contrôles de sécurité applicative d'un site avec comptes et paiement
Contexte
Sécurité exigée (must) ; coordonnées, identification et paiement ; site public avec trois rôles.
- E-17 — Sécurité applicative d'un site avec comptes et paiement
- Exigence de qualité : Sécurité
- E-11 — Comptes personnels et rôles (membre, professeur, équipe)
- E-25 — Test d'intrusion externe : hors de la base, variante chiffrée à part
- Q-7 — Souhaitez-vous qu'un prestataire externe fasse un test d'intrusion avant la mise en production, en plus de la revue de sécurité interne ?
Options envisagées
- Niveau 1 de l'ASVS seulement — Insuffisant pour des soldes, des paiements et des données personnelles.
- Test d'intrusion externe avant lancement — Plus fort que la demande : variante chiffrée à part, à décider avec vous.
Décision
Contrôles prévus pour les catégories pertinentes de l'OWASP Top 10:2025 : contrôle d'accès par objet, validation des entrées, chiffrement en transit et au repos, secrets hors du code, dépendances suivies, journalisation des gestes sensibles. Niveau 2 de l'ASVS 5.0.0 visé sur authentification, sessions et contrôle d'accès, à confirmer. La base comprend une revue de sécurité interne avant la mise en production. Un test d'intrusion par un prestataire externe est une variante chiffrée à part, avec le suivi de ses correctifs (+8 à 20 h), si vous le souhaitez. Aucune conformité n'est affirmée.
Conséquences
- Compromis : Effort de conception et de tests contre délai serré.
- Compromis : Test externe : vérification indépendante contre dépense ponctuelle et temps de correction.
- Risque : Contrôle d'accès par objet oublié sur un espace (professeur, réception).
- Risque : Sans vérification indépendante, les failles non vues par la revue interne subsistent.
Hypothèses
- Niveau ASVS 2 sur les chapitres ciblés seulement.
- Pas de test d'intrusion externe dans la base, faute de demande.
Vérifications prévues
- Revue de sécurité interne avant la mise en production.
- Tests d'accès entre membres et entre professeurs.
- Faire confirmer si un test externe est souhaité.
Références
- Risques applicatifs de référence — OWASP Top 10 (édition 2025) (v2)
- Exigences de vérification de sécurité applicative — OWASP ASVS (v2)
- Sécurité intégrée à la conception (piliers Well-Architected) (v2)
- Cadre de cybersécurité NIST CSF 2.0 — fonctions de gouvernance (v1)
DA-13 — Gouvernance des renseignements personnels : inventaire, responsable, conservation
Contexte
Coordonnées et identification traitées ; client au Québec ; Loi 25 à considérer ; fournisseurs d'authentification, de paiement et de courriel.
- E-15 — Renseignements personnels : Loi 25 à considérer
- Exigence de qualité : Confidentialité et renseignements personnels
- Q-8 — Qui s'occupera du site après la mise en service : une personne du studio ou un fournisseur externe ? Qui sera le responsable des renseignements personnels ?
- Q-4 — Si le fournisseur d'authentification, de courriel ou de paiement que nous retenons traite des données hors du Canada, le studio l'accepte-t-il, ou préférez-vous des services avec traitement canadien ?
Options envisagées
- Aucun cadre formel — Écarté : des renseignements personnels et de paiement sont traités.
Décision
Inventaire des renseignements et de leurs flux (base, journaux, sauvegardes, trois services externes), responsable désigné par le studio, durée de conservation et destruction fixées, procédure d'incident, confidentialité par défaut. Évaluation des facteurs relatifs à la vie privée à examiner pour toute communication hors du Québec. Aucune conformité présumée ; aucun avis juridique.
Conséquences
- Compromis : Un peu d'effort de gouvernance contre un risque réduit.
- Risque : Aucun responsable désigné après la mise en service.
Hypothèses
- La direction du studio est responsable des renseignements personnels.
Vérifications prévues
- Faire nommer le responsable et la durée de conservation avant le lancement.
Références
- Renseignements personnels au Canada et au Québec — Loi 25, LPRPDE, principes des autorités sur l'IA (v1)
- Classification, chiffrement et résidence des données (v2)
DA-14 — Une seule organisation, sans modèle multi-locataire
Contexte
La solution sert un seul studio ; données personnelles à isoler par membre, pas par organisation.
- E-1 — Remplacer l'horaire papier et les courriels par un site de réservation
- Exigence de qualité : Confidentialité et renseignements personnels
Options envisagées
- Base partagée, cloisonnée par organisation — Utile seulement si la solution servait d'autres studios ; non demandé.
Décision
Une seule organisation : pas de cloisonnement par locataire. L'isolation se fait par rôle et par objet (membre, professeur, équipe).
Conséquences
- Compromis : Modèle simple contre une refonte si la solution est revendue à d'autres studios.
- Risque : Réutilisation future par d'autres studios exigeant une refonte.
Hypothèses
- Un seul studio, un seul lieu.
Vérifications prévues
- Confirmer qu'aucune autre succursale n'est prévue.
Références
- Décision type — plusieurs organisations dans une même solution : base partagée cloisonnée, base par organisation ou instance par client (v2 — référence à vérifier)
- Multi-locataire — modèles de partage des ressources entre clients (v2)
DA-15 — Rapport mensuel par requêtes sur la base, sans cache ni entrepôt
Contexte
Rapport mensuel de fréquentation et de ventes ; 1 500 à 2 000 réservations par mois.
- E-10 — Rapport mensuel : fréquentation par cours et ventes de forfaits
- E-19 — Environ 700 membres actifs, 1 500 à 2 000 réservations par mois
- E-21 — Comptabilité hors mandat
Options envisagées
- Cache de lecture — Aucune mesure ne le justifie et les soldes doivent être strictement à jour.
- Entrepôt de données ou outil d'analyse — Disproportionné pour un rapport mensuel.
Décision
Rapport calculé par requêtes sur la base relationnelle, tâche planifiée mensuelle, avec export pour la comptable. Aucun cache de lecture ni entrepôt de données : le volume est trop faible et les soldes doivent être exacts.
Conséquences
- Compromis : Simplicité contre un rapport figé à son calcul.
- Risque : Pointe à l'ouverture des inscriptions non mesurée.
Hypothèses
- Un seul rapport mensuel suffit au studio.
Vérifications prévues
- Mesurer la charge à l'ouverture des inscriptions en test.
Références
- Base relationnelle transactionnelle comme stockage principal (v2)
- Cache de lecture (Cache-Aside) pour les données lues souvent (v1)
DA-16 — Livraison scriptée, deux environnements, exploitation sur les services gérés
Contexte
Une personne à la réalisation, exploitation par une personne du studio ou un fournisseur externe, sécurité exigée.
- E-29 — Exploitation par une personne du studio ou un fournisseur externe
- Q-8 — Qui s'occupera du site après la mise en service : une personne du studio ou un fournisseur externe ? Qui sera le responsable des renseignements personnels ?
- Exigence de qualité : Sécurité
- E-18 — Échéance visée : dans les trois mois
Options envisagées
- Chaîne complète avec observabilité dédiée — Disproportionnée pour ce volume et cette équipe.
- Déploiement manuel — Non reproductible et sujet aux erreurs.
Décision
Dépôt de code avec revue, tests automatisés à chaque demande de fusion, dépendances suivies, secrets hors du code, déploiement scripté déclenché manuellement vers un environnement de test puis de production, retour arrière possible. Surveillance limitée aux journaux et alertes du service d'hébergement. Compte d'hébergement au nom du studio.
Conséquences
- Compromis : Mise en place initiale contre livraisons sûres et réversibles.
- Risque : Personne désignée pour les correctifs après la stabilisation.
Hypothèses
- Fournisseur externe pour les correctifs ; responsable d'exploitation à nommer.
Vérifications prévues
- Faire nommer le responsable d'exploitation avant la mise en production.
- Répéter un retour arrière en test.
Références
- Livraison continue et chaîne d'approvisionnement logicielle — DORA, SLSA, NIST SSDF (v2)
- Excellence opérationnelle et observabilité (v2)
- Optimisation des coûts et récurrent explicite (v2)
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) | 73,85 h | 118,6 h | 216,05 h |
| Enveloppe de services | 10 162,25 CAD | 16 281,00 CAD | 29 459,25 CAD |
| Coût total client sur l'horizon | 36 759,21 CAD | 42 877,96 CAD | 56 056,21 CAD |
- Dépenses initiales : 10 000,00 CAD
- Récurrent mensuel indicatif : 1 383,08 CAD
- Récurrent sur l'horizon : 16 596,96 CAD
- Montants hors taxes. TPS et TVQ applicables selon le statut fiscal du client et la nature des prestations.
- Convention du récurrent annuel : toute période entamée sur l'horizon est comptée entière.
- Budget recommandé à autoriser : entre 40 435,13 CAD et 61 661,83 CAD, environ 47 165,76 CAD (scénario central plus une provision pour imprévus de 4 287,80 CAD, soit 10 %)
La provision suit la part du budget à confirmer : 10 % jusqu'à 15 %, 15 % jusqu'à 40 %, 20 % au-delà.
Coût total de possession
| Résultat | Basse | Centrale | Haute |
|---|---|---|---|
| Coût total (construction, dépenses initiales et récurrent sur l'horizon) | 36 759,21 CAD | 42 877,96 CAD | 56 056,21 CAD |
Le coût récurrent sur l'horizon dépasse le coût de construction : l'essentiel de la dépense se situe après la mise en service.
Hypothèse de réalisation
Mode : Réalisation assistée par l'IA. Réalisation en mode accéléré par une personne expérimentée qui emploie des outils d'IA de développement à chaque étape — génération de code et de tests, configuration de services gérés, rédaction des spécifications —, sur une application unique qui s'appuie sur des services de marché répandus, sous une revue humaine maintenue. 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, et ce que coûterait la réalisation si l'accélération ne se matérialisait pas.
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,25 / 0,30 / 0,50 | Mode accéléré : une personne expérimentée génère le code, les gabarits et les cadriciels répandus avec des outils d'IA et relit le résultat. Sous les essais en entreprise publiés (0,79–0,81) et sous le cas isolé de Peng 2023 (0,44) ; 0,25 est le plancher normatif. Pari déclaré, non mesuré sur nos dossiers. | Peng et al. 2023, arXiv 2302.06590 ; Cui, Demirer et al., Management Science 2025 ; décisions de Linuen des 27 septembre, 9 et 10 octobre 2026, 2026-10-11 |
| Tests automatisés et documentation | 0,25 / 0,30 / 0,45 | Mode accéléré : tests et documentation produits par l'IA puis relus, les artefacts les plus générables. Pari déclaré, non mesuré sur nos dossiers. | Extrapolation des facteurs du code standard ; décisions de Linuen des 27 septembre, 9 et 10 octobre 2026, 2026-10-11 |
| Infrastructure et déploiement | 0,35 / 0,45 / 0,65 | Mode accéléré : services gérés et configuration générée ; les pièges propres à chaque fournisseur demeurent. Pari déclaré, non mesuré sur nos dossiers. | Jugement structuré ; décisions de Linuen des 27 septembre, 9 et 10 octobre 2026, 2026-10-11 |
| Intégration avec l'existant et les tiers | 0,55 / 0,65 / 0,90 | Mode accéléré : connecteurs du marché et code d'appel générés ; l'API d'un tiers reste une inconnue (zone du ralentissement mesuré par METR 2025). Pari déclaré, non mesuré sur nos dossiers. | METR, juillet 2025, arXiv 2507.09089 ; décisions de Linuen des 27 septembre, 9 et 10 octobre 2026, 2026-10-11 |
| Analyse, cadrage, conception | 0,50 / 0,60 / 0,80 | Mode accéléré : le dossier Linuen est déjà l'analyse ; spécifications, variantes et rédaction assistées, décisions humaines maintenues. Pari déclaré, non mesuré sur nos dossiers. | Jugement structuré ; décisions de Linuen des 27 septembre, 9 et 10 octobre 2026, 2026-10-11 |
| Coordination, validation client, formation | 0,80 / 0,90 / 1,00 | Mode accéléré : temps HUMAIN avec le client — réunions, validations, calendriers de personnes — peu accélérable, et c'est dit ; seuls les comptes rendus et la préparation s'accélèrent. | Jugement structuré ; décisions de Linuen des 27 septembre, 9 et 10 octobre 2026, 2026-10-11 |
| 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). La sécurité reste entière en mode accéléré : une revue humaine ne se divise pas. | Faros AI 2025 ; DORA 2024 et 2025 ; Denisov-Blanch (Stanford) 2025, 2026-09-27 |
| Borne | Référence | Retenue |
|---|---|---|
| Basse | 166 h | 73,85 h |
| Centrale | 230 h | 118,6 h |
| Haute | 309 h | 216,05 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, Intégration avec l'existant et les tiers, Analyse, cadrage, conception, Coordination, validation client, formation.
Si l'accélération ne se matérialisait pas, l'enveloppe de services serait de 30 800,00 CAD au lieu de 16 281,00 CAD, et le délai de 7 semaines au lieu de 6 (scénario central).
Plus tard (phase 2)
Ces éléments ne sont pas compris dans le budget ; ils sont chiffrés à titre indicatif pour une étape suivante.
- Messages texte pour les avis aux membres — Le courriel suffit aux avis décrits ; le texto ajoute un service externe et un consentement à recueillir. · de 15 à 35 h de référence
- Réservation automatique de la place libérée depuis la liste d'attente — La première version avise par courriel et la place se prend par réservation normale. · de 12 à 28 h de référence
- Tableaux de bord interactifs et rapports additionnels — Le rapport mensuel avec export répond au besoin déclaré ; des analyses plus poussées peuvent suivre l'usage réel. · de 12 à 30 h de référence
- Intégration avec l'outil comptable de la comptable — La comptabilité est hors mandat ; l'export du rapport suffit au démarrage. · de 20 à 45 h de référence
- Application mobile native — Le site adapté aux téléphones couvre les parcours essentiels. · de 80 à 200 h de référence
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 des règles du studio et conception technique | Analyse, cadrage, conception | 13 / 18 / 24 h | 0,50 / 0,60 / 0,80 | 6,5 h | 10,8 h | 19,2 h | — | Décomposition en quatre sous-tâches (5 + 5 + 5 + 3 h) pour un besoin à trois rôles, une dizaine de règles et deux services externes. |
| P-2 | Environnements, hébergement canadien et mise en production | Infrastructure et déploiement | 13 / 18 / 26 h | 0,35 / 0,45 / 0,65 | 4,55 h | 8,1 h | 16,9 h | — | Décomposition en cinq sous-tâches (5 + 3 + 3 + 4 + 3 h) sur services gérés standards. |
| P-3 | Parcours des membres : horaire, réservation, liste d'attente, forfaits et soldes | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 36 / 50 / 65 h | 0,25 / 0,30 / 0,50 | 9 h | 15 h | 32,5 h | — | Décomposition en six sous-tâches (6 + 9 + 6 + 8 + 13 + 8 h) selon les règles décrites au dossier, avec cas limites de concurrence et d'annulation. |
| P-4 | Espaces professeurs, réception et équipe : rôles, ajustements et rapport mensuel | Code standard (écrans, formulaires, CRUD, API internes, logique courante) | 27 / 38 / 49 h | 0,25 / 0,30 / 0,50 | 6,75 h | 11,4 h | 24,5 h | — | Décomposition en cinq sous-tâches (8 + 7 + 10 + 5 + 8 h) selon les trois rôles décrits. |
| P-5 | Intégrations : paiement par page hébergée et courriel transactionnel | Intégration avec l'existant et les tiers | 22 / 30 / 42 h | 0,55 / 0,65 / 0,90 | 12,1 h | 19,5 h | 37,8 h | — | Décomposition en six sous-tâches (4 + 6 + 7 + 2 + 8 + 3 h) sur deux intégrations à SDK standards. |
| P-6 | Tests automatisés des règles critiques et aide-mémoire d'utilisation | Tests automatisés et documentation | 19 / 26 / 35 h | 0,25 / 0,30 / 0,45 | 4,75 h | 7,8 h | 15,75 h | — | Décomposition en cinq sous-tâches (9 + 5 + 5 + 4 + 3 h), environ 13 % des heures de réalisation. |
| P-7 | Revue de sécurité applicative et vérifications de protection des renseignements | Sécurité, revue et assurance qualité | 7 / 10 / 14 h | 1,00 / 1,00 / 1,10 | 7 h | 10 h | 15,4 h | — | Décomposition en quatre sous-tâches (4 + 2 + 2 + 2 h) sur une application d'un seul bloc. |
| P-8 | Gestion de projet, formation, recette avec le studio et stabilisation | Coordination, validation client, formation | 29 / 40 / 54 h | 0,80 / 0,90 / 1,00 | 23,2 h | 36 h | 54 h | — | Décomposition en quatre sous-tâches (22 + 5 + 5 + 8 h), gestion à 12 % des autres postes. |
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 | 6,5 h | 10,8 h | 19,2 h |
| Analyste qualité / développeur | 115,00 CAD | 4,75 h | 7,8 h | 15,75 h |
| Architecte technique | 165,00 CAD | 7 h | 10 h | 15,4 h |
| Chargé de projet | 140,00 CAD | 23,2 h | 36 h | 54 h |
| Développeur back-end / intégration | 130,00 CAD | 12,1 h | 19,5 h | 37,8 h |
| Développeur back-end/front-end | 130,00 CAD | 15,75 h | 26,4 h | 57 h |
| Spécialiste infrastructure / DevOps | 150,00 CAD | 4,55 h | 8,1 h | 16,9 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 | Hébergement de production : application et base de données gérées, région canadienne | Mensuelle | 179,00 CAD | 2 148,00 CAD | — | Référence tarifaire d'Azure Canada Central lue le 2026-10-16 : App Service S1 (64,24 $ US) + PostgreSQL B2S (54,02 $ US) + 64 Go (8,10 $ US) = 126,36 $ US × 1,4196 = 179 $ CA. Hors trafic sortant, surveillance et domaine, chiffrés à part. Comprend les sauvegardes automatiques de la base. |
| D-2 | Environnement de test unique, même nature que la production, plus petit | Mensuelle | 61,00 CAD | 732,00 CAD | — | Référence tarifaire d'Azure Canada Central lue le 2026-10-16 : App Service B2 (25,55 $ US) + PostgreSQL B1MS (13,51 $ US) + 32 Go (4,05 $ US) = 43,10 $ US × 1,4196 = 61 $ CA, en fonctionnement permanent. |
| D-3 | Service d'authentification géré (comptes, second facteur, récupération de compte) | Mensuelle | 99,00 CAD | 1 188,00 CAD | — | Palier de 1 000 utilisateurs actifs du plan Essentials d'Auth0, lu le 2026-10-16 : 70 $ US × 1,4196 = 99 $ CA par mois. Environ 700 membres et une quinzaine de comptes de professeurs et d'employés tombent dans ce palier. |
| D-4 | Service de courriel transactionnel : forfait d'entrée avec domaine d'envoi authentifié prix hypothèse | Mensuelle | 28,00 CAD | 336,00 CAD | dépend de Q-9 | Scénario : 20 $ US × 1,4196 = 28 $ CA par mois pour un forfait d'entrée ; le volume prévu de 3 200 courriels par mois (confirmations, avis de place libérée, annulations, reçus) reste très sous le quota inclus. |
| D-5 | Nom de domaine du site (certificat TLS géré par l'hébergement) prix hypothèse | Mensuelle | 2,08 CAD | 24,96 CAD | dépend de Q-1 | Calcul : 25 $ CA par an ÷ 12 = 2,08 $ par mois pour un domaine ; le certificat géré par l'hébergeur est supposé gratuit. Les enregistrements d'authentification du courriel (SPF, DKIM) se font dans la zone du domaine, sans frais. |
| D-6 | Journaux d'application et alertes de base (sans renseignements de carte) prix hypothèse | Mensuelle | 14,00 CAD | 168,00 CAD | dépend de Q-8 | Calcul : 4 Go par mois × 3,50 $ CA par Go = 14 $ par mois, pour les journaux d'application et d'accès, les alertes d'erreur et de disponibilité du service d'hébergement ; aucun service d'observabilité dédié. |
| D-7 | Maintenance après la mise en service : correctifs, dépendances, sécurité, support | Mensuelle | 1 000,00 CAD | 12 000,00 CAD | — | Valeur centrale de la référence : 24 % par an du coût de réalisation, ramené au mois, soit 1 000 $ par mois pour une réalisation typique de 50 000 $ (repère de référence, non un coût calculé pour ce dossier). Fourchette publiée : 400 à 2 000 $ par mois. Comprend correctifs de sécurité, mises à jour de dépendances, suivi des journaux et petit support. |
| D-8 | Test d'intrusion de l'application avant la mise en production | Une fois | 10 000,00 CAD | 10 000,00 CAD | — | écart de la référence : l'application a trois rôles (membre, professeur, équipe) avec contrôle d'accès par objet et une intégration de paiement, plus étendue qu'une application à un seul rôle ; retenu 10 000 $ dans la bande publiée de 5 000 à 12 000 $ (milieu à 8 500 $). Source : page d'un prestataire (Stingrai, 2026-06-05), ordre de grandeur. Dépense comprise dans l'enveloppe de base, car le site traite identifiants, coordonnées et paiement. |
| D-9 | Conseil juridique (renseignements personnels, conditions d'utilisation) | Une fois | 0,00 CAD | 0,00 CAD | — | Exclusion déclarée par le client à la question « Qu'est-ce qui est explicitement hors périmètre ? » : traduction, conseil juridique ou réglementaire. — montant nul : coût possible laissé hors de l'enveloppe présentée, à prévoir par vous |
| D-10 | Sauvegardes de la base de données (service géré, région canadienne) | Mensuelle | 0,00 CAD | 0,00 CAD | dépend de Q-6 | Approche retenue : sauvegardes du fournisseur uniquement. La référence d'hébergement chiffre la base et son stockage ; la rétention courte par défaut est supposée incluse. — montant nul : compris dans D-1 |
| D-11 | Frais d'ouverture des comptes de services | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-4 | Pratique courante des services de marché retenus (abonnement mensuel, aucun frais d'adhésion) ; non vérifiée auprès de fournisseurs retenus. — montant nul : sans objet dans ce dossier |
| D-12 | Thème, gabarits et composants d'interface payants | Une fois | 0,00 CAD | 0,00 CAD | hypothèse à confirmer | Approche retenue : technologies répandues et composants du marché libres de droits ; aucun gabarit payant requis par les fonctions décrites. — montant nul : sans objet dans ce dossier |
| D-13 | Configuration des services tiers (paiement, courriel, authentification) | Une fois | 0,00 CAD | 0,00 CAD | — | Le poste de travail « Intégrations : paiement par page hébergée et courriel transactionnel » porte la configuration et les essais de ces services. — montant nul : compris dans P-5 |
| D-14 | Reprise de données existantes | Une fois | 0,00 CAD | 0,00 CAD | — | Réponse déclarée au questionnaire d'ouverture : aucune donnée existante à reprendre. — montant nul : coût possible laissé hors de l'enveloppe présentée, à prévoir par vous |
| D-15 | Matériel informatique | Une fois | 0,00 CAD | 0,00 CAD | hypothèse à confirmer | Approche retenue : application web sans appareil dédié ni terminal de paiement physique. — montant nul : sans objet dans ce dossier |
| D-16 | Production de contenu (textes, photos, descriptions de cours) | Une fois | 0,00 CAD | 0,00 CAD | hypothèse à confirmer | La description ne demande ni rédaction ni photographie ; les textes d'interface sont compris dans les postes de réalisation. — montant nul : sans objet dans ce dossier |
| D-17 | Services facturés à l'acte | Mensuelle | 0,00 CAD | 0,00 CAD | dépend de Q-9 | Forfait d'entrée du courriel avec quota inclus d'environ 50 000 courriels par mois, contre 3 200 prévus à la volumétrie ; aucun autre service facturé à l'acte. — montant nul : compris dans D-4 |
| D-18 | Licences logicielles renouvelables | Mensuelle | 0,00 CAD | 0,00 CAD | hypothèse à confirmer | Approche retenue : cadriciel et composants libres répandus, sans licence commerciale. — montant nul : sans objet dans ce dossier |
| D-19 | Autres dépenses | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-4 | Revue des catégories de dépenses de l'approche retenue : hébergement, authentification, courriel, domaine, journaux, maintenance et audit sont chiffrés ; rien d'autre n'est décrit au dossier. — montant nul : sans objet dans ce dossier |
| D-20 | Usage de modèles d'intelligence artificielle | Mensuelle | 0,00 CAD | 0,00 CAD | — | Architecture du dossier : aucun composant avec ; les fonctions déclarées (comptes, paiement, notifications, tableaux de bord) n'en demandent pas. — montant nul : sans objet dans ce dossier |
| D-21 | Stockage de fichiers — activation prix hypothèse | Une fois | 0,00 CAD | 0,00 CAD | — | Architecture du dossier : composants limités à l'application, à la base et aux services tiers ; aucun stockage de fichiers. |
| D-22 | Trafic sortant de l'hébergement ; pas de réseau de diffusion de contenu — activation prix hypothèse | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-1 | Calcul : environ 20 000 visites par mois × 1 Mo ≈ 20 Go, contre une franchise supposée de 100 Go ; franchise non revérifiée à cette date. |
| D-23 | Sauvegardes automatiques du service de base de données gérée, région canadienne — activation prix hypothèse | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-6 | Sauvegardes du fournisseur seulement ; stockage de sauvegarde supposé inclus jusqu'à la taille de la base, non revérifié auprès du fournisseur. |
| D-24 | Reprise après sinistre — activation prix hypothèse | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-6 | Un seul bloc applicatif, une seule région canadienne, sauvegardes du service géré ; aucun objectif de reprise déclaré. |
| D-25 | Dépôt de code et déploiement scripté vers l'hébergement géré ; aucun registre d'images — activation prix hypothèse | Une fois | 0,00 CAD | 0,00 CAD | dépend de Q-8 | Un seul bloc applicatif, déploiement scripté, aucune image à stocker ; offre gratuite de dépôt supposée. |
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-4, D-5, D-6, D-21, D-22, D-23, D-24, D-25.
- 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.
- Les frais prélevés par votre prestataire de paiement sur vos ventes ne sont pas compris dans cette estimation.
- Juridiction du client : Québec. Lois de protection des renseignements personnels à considérer : Loi 25 (Commission d'accès à l'information du Québec) — nommées d'après le registre de Linuen ; ce n'est ni un avis juridique ni une conformité.
- 16 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, DA-14, DA-15, DA-16) : proposées par l'analyse et maintenues à la revue critique, à confirmer avec vous avant la réalisation.
Risques et dépendances utiles à la décision
- Deux membres réservent la dernière place au même moment, ou une annulation et une réservation se croisent. — Cours en surnombre ou solde de séances faux, avec litiges avec les membres. Atténué par la transaction unique en base.
- Le signalement de paiement arrive en double, en retard ou jamais ; le renouvellement d'abonnement échoue. — Forfait activé deux fois ou non activé malgré le paiement ; soldes erronés. Traitement idempotent et rapprochement planifié prévus.
- Les règles de forfaits (validité des cartes, renouvellement, remboursements, abonnement illimité) et la règle d'avis de la liste d'attente ne sont pas arrêtées. — Règles de solde et de liste d'attente à reprendre en cours de réalisation : de +10 à 25 h pour l'avis au suivant avec délai, variation de plusieurs dizaines d'heures pour les forfaits.
- Le service d'authentification, de paiement ou de courriel traite des données hors du Canada ; la Loi 25 demande d'examiner toute communication de renseignements hors du Québec, y compris pour la liste complète des membres. — Évaluation à documenter ; un traitement strictement canadien limiterait le choix des fournisseurs (+8 à 20 h).
- Le questionnaire PCI applicable n'est pas confirmé avec l'acquéreur du studio. — Si la page de paiement n'était pas entièrement hébergée, le périmètre et le coût de conformité augmenteraient.
- Les sauvegardes sont celles des services gérés ; la durée de rétention et les objectifs de reprise sont supposés, non confirmés, et la restauration n'est pas éprouvée. — Une erreur découverte tardivement (solde faussé remarqué après une semaine) pourrait ne pas être récupérable ; un essai de restauration avant la mise en service et une rétention plus longue (+2 à 6 h, faible coût récurrent) réduisent ce risque.
- Aucune vérification indépendante de la sécurité n'est incluse : seule la revue interne est prévue pour un site avec comptes et paiement. — Des failles pourraient échapper à la revue interne ; un test externe se chiffre en variante, avec +8 à 20 h de suivi des correctifs.
- Un seul responsable technique après la mise en service, ou personne désignée pour les correctifs et les demandes d'accès aux renseignements. — Correctifs de sécurité tardifs ; sécurité et vie privée dégradées avec le temps.
- Échéance de trois mois avec une seule personne à la réalisation, un périmètre complet et des fenêtres de recette (une semaine au moins) et de stabilisation (environ deux semaines) qui dépendent de la disponibilité du studio. — Dérapage du calendrier si la recette tarde ; leviers : phaser le rapport et l'espace professeur (−20 à 45 h), pilote sur quelques cours, équipe élargie.
Limites de l'approche retenue :
- Aucune conformité n'est affirmée : Loi 25, PCI DSS et OWASP restent à démontrer par le studio ou par une vérification indépendante.
- L'attestation PCI (hypothèse SAQ A) est celle du studio, à confirmer avec son acquéreur.
- Sauvegardes du service géré d'hébergement et de base de données ; durée de rétention et objectifs de reprise à confirmer avec vous.
- Revue de sécurité interne seulement : un test d'intrusion externe est une variante chiffrée à part.
- La région de traitement des services d'authentification, de courriel et de paiement se vérifie avant leur choix (préférence canadienne négociable).
- Courriels seulement ; ni messages texte, ni application mobile native, ni intégration comptable.
- Pas de reprise de données : les membres créent leur compte.
- Un seul environnement de test ; aucun service d'observabilité dédié, seulement les journaux et alertes du service d'hébergement.
Volumétrie retenue
| Grandeur | Valeur retenue | À confirmer | Comment ce chiffre est établi |
|---|---|---|---|
| Réservations par mois (borne haute retenue) | 2 000 réservations/mois | hypothèse à confirmer | La description donne de 1 500 à 2 000 réservations par mois ; la borne haute est retenue par prudence pour dimensionner courriels et hébergement. — déclaré : de 1 000 à 10 000 ; valeur choisie dans l'intervalle déclaré — à confirmer |
| Valeur moyenne d'un paiement (forfait) | 162 CAD par paiement | hypothèse à confirmer | Prix supposés (non fournis) : carte de dix à 180 CAD, abonnement mensuel à 120 CAD ; moyenne pondérée (140 × 180 + 60 × 120) ÷ 200 = 162. — hypothèse — à confirmer |
| Facteur de pointe à l'ouverture des inscriptions | 10 fois la charge moyenne | hypothèse à confirmer | Scénario : à l'ouverture de l'horaire de la semaine, une partie des 700 membres se connecte dans la même heure, soit environ dix fois la charge moyenne. — hypothèse — à confirmer |
| Croissance annuelle de l'activité | 10 % par an | hypothèse à confirmer | Hypothèse de croissance modérée pour un studio de quartier de 700 membres ; aucune donnée de tendance fournie. — hypothèse — à confirmer |
| Courriels transactionnels par mois | 3 200 courriels/mois | hypothèse à confirmer | Calcul : 2 000 réservations × 1,5 courriel (confirmation, annulation, liste d'attente, annulation de cours) = 3 000, plus 200 reçus de paiement = 3 200. Les réinitialisations de mot de passe sont comprises dans l'arrondi. — dérivée d'une donnée fournie |
| Membres actifs du studio | 700 membres | — | La description indique « environ 700 membres actifs » ; cohérent avec la fourchette de 500 à 5 000 utilisateurs du questionnaire. — donnée fournie |
| Paiements par carte par mois (cartes vendues + renouvellements) | 200 paiements/mois | hypothèse à confirmer | Calcul : 140 cartes de dix vendues + 60 renouvellements d'abonnement = 200, soit environ un dixième des réservations, non toutes les réservations. — dérivée d'une donnée fournie |
| Abonnements mensuels illimités actifs (renouvelés chaque mois) | 60 abonnements | hypothèse à confirmer | Scénario : 200 réservations d'abonnés sur 2 000 environ, soit environ 6 à 7 séances par abonné et par mois, donc une soixantaine d'abonnés. — hypothèse — à confirmer |
| Cartes de dix séances vendues par mois | 140 cartes/mois | hypothèse à confirmer | Calcul : 2 000 réservations × 0,7 ÷ 10 séances par carte = 140. — dérivée d'une donnée fournie |
| Taux de frais proportionnels du prestataire de paiement | 2,9 % du montant | hypothèse à confirmer | Taux courant supposé pour un paiement par carte en ligne (2,9 %), non vérifié auprès d'un tarif daté ni d'un prestataire retenu. — hypothèse — à confirmer |
| Frais fixes par paiement du prestataire | 0,3 CAD par paiement | hypothèse à confirmer | Frais fixes courants supposés (0,30 CAD par transaction), non vérifiés auprès d'un tarif daté. — hypothèse — à confirmer |
| Part des réservations déduites d'une carte de dix séances | 70 % des réservations | hypothèse à confirmer | Scénario : 70 % des réservations passent par une carte de dix, le reste par abonnement illimité (environ 20 %) ou saisie au comptoir et séances d'essai (environ 10 %). — hypothèse — à confirmer |
Ce qui ferait bouger le budget
| Facteur | Hypothèse retenue | Alternative | Impact | Effet sur le délai |
|---|---|---|---|---|
| Outil existant à conserver ou à brancher | Rien n'est à conserver : comptes, horaire et soldes sont construits à neuf, sans reprise de données. | Un outil du marché est conservé : intégration, reprise des membres et des soldes, moins le socle qu'on ne construit pas. | +20 à 60 h, avant déduction du socle non construit · Proportionnel aux heures, au taux du rôle développeur back-end | +0,5 à 1,5 semaine |
| Phasage du rapport mensuel et de l'espace professeur | Toutes les fonctions décrites sont livrées ensemble dans la première version. | Rapport mensuel et espace professeur livrés dans une seconde étape, après la mise en service des réservations et des forfaits ; annulations de cours saisies par la réception en attendant. | -20 à 45 h dans la première version, reportées ensuite · Proportionnel aux heures, au taux du rôle développeur back-end/front-end | -0,5 à 1,1 semaine avant la mise en service |
| Exigence stricte de traitement canadien chez tous les fournisseurs | Hébergement, base, sauvegardes et journaux au Canada ; authentification et courriel choisis avec traitement canadien si possible ; paiement chez un prestataire reconnu, après évaluation. | Le studio exige un traitement canadien pour l'authentification, le paiement et le courriel : choix restreint, vérifications et configuration supplémentaires. | +8 à 20 h · Proportionnel aux heures ; abonnements de courriel et d'authentification possiblement plus élevés | +0,2 à 0,5 semaine |
| Liste d'attente : avis au suivant avec délai de confirmation | Avis simultané à tous les membres en attente ; la place va au premier qui réserve. | Seul le membre suivant est avisé et dispose d'un délai pour confirmer avant de passer au suivant : échéances automatiques et relances. | +10 à 25 h · Proportionnel aux heures, au taux du rôle développeur back-end | +0,25 à 0,6 semaine |
| Avis par message texte en plus du courriel | Courriel uniquement pour tous les avis aux membres. | Ajout des messages texte : service externe, recueil du consentement, gabarits et suivi des envois. | +15 à 35 h · Proportionnel aux heures ; frais d'envoi récurrents en plus | +0,4 à 0,9 semaine |
Délai
6 semaines depuis le démarrage (5 à 8 semaines). Hypothèse de capacité : 1,00 personne(s) à 40,00 h productives par semaine, plus une coordination à temps partiel. Dont 1 semaine(s) de délais externes non compressibles. Le délai compte 2 semaine(s) d'attente incompressible (Cadrage, Recette, Stabilisation) : une fenêtre d'observation ou un cycle ne raccourcissent pas avec l'effort.
Phases ramenées par l'application dans la proportion de l'effort retenu (heures retenues ÷ heures de référence, basse / centrale / haute : 0,44 / 0,52 / 0,70). Les délais externes ne bougent pas.
| Phase | Référence | Retenue | Jalon |
|---|---|---|---|
| Cadrage | 0,5 / 0,55 / 0,8 sem. | 0,5 / 0,5 / 0,6 sem. | Règles de réservation, de forfaits et de remboursement validées par la personne désignée du studio ; conception technique et choix des services arrêtés avec vous. — durée minimale 0,50 sem. |
| Réalisation | 2 / 2,8 / 3,75 sem. | 0,9 / 1,4 / 2,6 sem. | Environnements en région canadienne prêts ; parcours des membres, espaces professeur, réception et équipe, et rapport mensuel démontrables en test. |
| Intégrations | 0,6 / 0,8 / 1,1 sem. | 0,3 / 0,4 / 0,8 sem. | Paiement par page hébergée (achat, renouvellement, remboursement constaté) et courriels transactionnels fonctionnels en mode test. |
| Recette | 1 / 1,1 / 1,5 sem. | 1 / 1 / 1 sem. | Tests automatisés réussis, revue de sécurité interne faite, recette du studio d'au moins une semaine terminée et anomalies bloquantes corrigées. — durée minimale 1 sem. |
| Mise en production | 0,15 / 0,2 / 0,3 sem. | 0,1 / 0,1 / 0,2 sem. | Site en production, essai de restauration d'une sauvegarde réussi, formation de la réception, des professeurs et de l'équipe donnée. |
| Stabilisation | 2 / 2 / 2,5 sem. | 2 / 2 / 2 sem. | Environ deux semaines d'observation des réservations réelles : journaux suivis, règles ajustées, passage au responsable d'exploitation. — durée minimale 2 sem. |
- Ouverture du compte marchand et approbation du prestataire de paiement : 2 semaine(s) — Le compte de production du studio exige une vérification de l'entreprise par le prestataire et son acquéreur. Elle court pendant la réalisation (bac à sable en attendant) ; elle bloque la mise en production seulement si elle tarde. (en parallèle du travail, non ajouté au délai)
- Authentification du domaine d'envoi des courriels : 0.5 semaine(s) — Les enregistrements DNS (SPF, DKIM) demandent l'accès au domaine du studio et un délai de propagation avant des envois fiables. (en parallèle du travail, non ajouté au délai)
- Questionnaire PCI avec l'acquéreur et examen Loi 25 par le studio : 1 semaine(s) — Le studio désigne son responsable des renseignements personnels et confirme avec son acquéreur le questionnaire applicable ; démarches du studio, menées en parallèle du travail. (en parallèle du travail, non ajouté au délai)
- Réponses du studio aux questions essentielles : 1 semaine(s) — Outil existant, abonnement, liste d'attente, fournisseurs et échéance ferme sont à trancher avant la conception technique ; sans réponse, les valeurs par défaut du dossier s'appliquent.
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 — Le studio fournit ses contenus ; la réalisation prévoit les emplacements, pas leur rédaction ni la prise de photos.
- référencement — Aucune stratégie ni optimisation n'est chiffrée ; seules les bonnes pratiques de base des pages publiques s'appliquent.
- traduction — Exclue par le studio. Le site et les courriels sont livrés dans une seule langue.
- reprise de données historiques — Aucune donnée à reprendre : les membres créent leur compte. À revoir si un outil existant est conservé (+20 à 60 h, voir la sensibilité).
- conseil juridique ou réglementaire — Exclu par le studio : conditions d'utilisation, politique de confidentialité et analyse Loi 25 relèvent de son conseiller. Les vérifications techniques de protection des renseignements restent comprises dans la revue de sécurité.
- évolutions fonctionnelles — Non comprises : messages texte, réservation automatique depuis la liste d'attente, application mobile native, intégration comptable, règles d'annulation par type de cours.
Compris dans le mandat : formation, accessibilité, licences tierces, support après stabilisation.
À 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 — L'abonnement mensuel se renouvelle-t-il automatiquement sur la carte du membre ? Quelle durée de validité pour une carte de dix séances, et quelles règles de remboursement ? | Renouvellement automatique mensuel, validité de la carte de dix séances fixée par le studio, remboursement sur le portail du prestataire. | P-5 | 3 341,00 CAD |
| Q-3 — Quand une place se libère, tous les membres en attente sont-ils avisés en même temps (le premier qui réserve l'obtient), ou seulement le suivant, avec un délai pour confirmer avant de passer au membre suivant ? | Avis simultané à tous les membres en attente ; la place va au premier qui réserve. | P-3 | 3 055,00 CAD |
| Q-5 — L'échéance de trois mois est-elle une date ferme (par exemple le début d'une session de cours) ? Quelles fonctions sont indispensables à cette date ? | Date cible souple : toutes les fonctions décrites sont livrées ensemble. | P-4, D-1 | 2 307,50 CAD + 2 148,00 CAD de dépenses sur l'horizon |
| Q-4 — Si le fournisseur d'authentification, de courriel ou de paiement que nous retenons traite des données hors du Canada, le studio l'accepte-t-il, ou préférez-vous des services avec traitement canadien ? | Hébergement au Canada ; prestataire de paiement reconnu, même si une partie du traitement est hors Canada, après évaluation. | P-2, D-3, D-11, D-19 | 1 852,50 CAD + 1 188,00 CAD de dépenses sur l'horizon |
| Q-1 — Utilisez-vous aujourd'hui un outil existant (liste de membres, logiciel de réservation) dont il faudrait conserver ou brancher les données, ou tout se construit-il à neuf ? | Rien à conserver : comptes, horaire et soldes sont construits à neuf, sans reprise de données. | P-1, D-5, D-14, D-21, D-22 | 1 778,00 CAD + 24,96 CAD de dépenses sur l'horizon |
| Q-8 — Qui s'occupera du site après la mise en service : une personne du studio ou un fournisseur externe ? Qui sera le responsable des renseignements personnels ? | Fournisseur externe pour les correctifs ; la direction du studio est responsable des renseignements personnels. | P-8, D-2, D-6, D-7, D-9, D-25 | 4 312,00 CAD + 12 900,00 CAD de dépenses sur l'horizon |
| Q-7 — Souhaitez-vous qu'un prestataire externe fasse un test d'intrusion avant la mise en production, en plus de la revue de sécurité interne ? | Non : revue de sécurité interne seulement. | P-7, D-8 | 1 386,00 CAD + 10 000,00 CAD de dépenses sur l'horizon |
| Q-6 — Combien de temps faut-il pouvoir remonter dans les sauvegardes (par exemple pour corriger un solde faussé découvert après une semaine) et quelle perte de données maximale acceptez-vous après un incident ? | Rétention standard du service géré (quelques jours) ; perte maximale d'une journée. | D-10, D-23, D-24 | 0,00 CAD de dépenses sur l'horizon |
| Q-9 — Les avis aux membres se font-ils par courriel seulement, ou souhaitez-vous aussi des messages texte ? | Courriel uniquement. | D-4, D-17 | 336,00 CAD de dépenses sur l'horizon |
| Hypothèses à confirmer sans question liée | D-12 : Les composants libres couvrent l'horaire, les formulaires et les tableaux ; aucune licence commerciale nécessaire. ; D-15 : Le studio dispose déjà d'un poste au comptoir pouvant ouvrir un navigateur à jour. ; D-16 : Le studio fournit lui-même ses descriptions de cours, ses tarifs et ses images, en français. ; D-18 : Aucun outil à licence annuelle n'est requis pour l'exploitation. | D-12, D-15, D-16, D-18 | 0,00 CAD de dépenses sur l'horizon |