DA-1 — Construire un portail sur mesure plutôt qu'acheter ou adapter un produit

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

partiellement couverte par les références citées

Décision type

Décision type — acheter ou construire : application sur mesure, plateforme du marché adaptée, ou logiciel complet acheté — option retenue : Construire une application sur mesure, appuyée sur des services gérés

Contexte

Flux d'enquête par superviseur, avis de gravité et visibilité restreinte des renseignements médicaux, liés à trois systèmes existants et aux normes imposées par l'équipe TI.

• E-1 — Remplacer le papier et le chiffrier par un portail unique
• E-3 — Enquête du superviseur et mesures correctives avec relances
• E-5 — Accès restreint aux renseignements médicaux et à l'identité des blessés
• E-26 — Aucun logiciel de santé et sécurité existant à conserver
• Q-10 — Existe-t-il, en plus du papier et du chiffrier, un logiciel du marché de santé et sécurité en service que vous voulez conserver, interfacer ou remplacer ?

Options envisagées

• Acheter un logiciel complet et adapter le processus à l'outil — Pourrait couvrir le besoin courant, mais son hébergement en région canadienne, ses rôles fins sur les champs médicaux et ses intégrations avec vos trois systèmes sont à vérifier ; aucun produit n'a été comparé dans ce dossier.
• Adapter une plateforme du marché avec quelques composants spécifiques — Piste valable pour le formulaire et le flux, mais la restriction par champ et les normes d'hébergement imposées limitent la marge ; non chiffrée ici.

Décision

Construire une application sur mesure, appuyée sur des services gérés. Aucune déclaration contraire du client ni avantage démontré d'un produit du marché ne justifie de dévier du choix par défaut. L'examen d'un logiciel de santé et sécurité du marché reste possible à part, comme approche non retenue.

Conséquences

• Compromis : Contrôle total des droits et de l'hébergement contre un coût de réalisation et une maintenance à la charge de l'équipe TI.
• Risque : Un produit du marché existant pourrait couvrir l'essentiel du besoin à moindre coût et rester non examiné.

Hypothèses

• Aucun logiciel de santé et sécurité en service à conserver.
• La fiche de décision type est non vérifiée : son choix par défaut est cité comme hypothèse.

Vérifications prévues

• Confirmer avec vous si un produit du marché a déjà été évalué ou écarté.
• Si la réponse sur l'outil existant change, revoir le périmètre d'intégration.

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 structurée en modules plutôt que des services séparés

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — style d'architecture : monolithe modulaire, microservices ou assemblage de services gérés — option retenue : Monolithe modulaire

Contexte

Petite équipe de réalisation, volumétrie modeste (100 à 1 000 opérations par mois), exploitation par une équipe TI interne.

• E-24 — Volumétrie : environ 1 200 employés, 1 000 déclarations par mois retenues
• E-27 — Rythme de réalisation de base : une personne à temps plein
• E-12 — Exploitation par l'équipe TI selon ses normes d'hébergement et de journalisation
• E-1 — Remplacer le papier et le chiffrier par un portail unique

Options envisagées

• Microservices — Une seule équipe et un domaine encore mouvant ; la charge d'exploitation serait disproportionnée pour votre équipe TI.
• Assemblage de services gérés autour d'un noyau léger — Aucun produit ne couvre l'essentiel du flux d'enquête ; les services gérés servent seulement aux fonctions périphériques (courriel, stockage, base).

Décision

Monolithe modulaire : modules déclaration, enquête, mesures et relances, gravité et avis, droits d'accès, préparation réglementaire, avec une base partagée et des traitements asynchrones internes. Les frontières de modules sont documentées pour permettre une extraction ultérieure.

Conséquences

• Compromis : Simplicité d'exploitation et transactions locales contre mise à l'échelle sélective.
• Risque : Les modules peuvent se mélanger avec le temps.

Hypothèses

• La charge reste modeste ; aucune mise à l'échelle particulière n'est requise.
• La fiche de style d'architecture est non vérifiée.

Vérifications prévues

• Revoir si les normes de l'équipe TI imposent un style de déploiement différent.

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 — Authentification unique par l'annuaire, avec second facteur pour tout rôle qui voit les champs protégés

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — authentification : comptes intégrés à l'application, fournisseur d'identité géré ou annuaire de l'organisation — option retenue : Authentification unique par l'annuaire de l'organisation

Contexte

Utilisateurs tous employés, déjà présents dans l'annuaire ; authentification unique demandée ; superviseurs, comité et service de santé et sécurité voient des renseignements de santé.

• E-8 — Ouverture de session par l'annuaire de l'entreprise
• E-25 — Comptes fournis par l'annuaire ; rôles et droits construits dans le portail
• E-18 — Sécurité applicative, chiffrement et journal d'audit des accès sensibles
• E-5 — Accès restreint aux renseignements médicaux et à l'identité des blessés
• Exigence de qualité : Sécurité
• Q-2 — Comment accéder à l'annuaire (protocole d'authentification unique), au système de ressources humaines et au progiciel de gestion (interface, fichier d'export, fréquence) ? L'annuaire peut-il imposer un second facteur aux superviseurs, au comité et au service de santé et sécurité (licence comprise) ? Pouvez-vous fournir des environnements d'essai et un interlocuteur pour chacun ?

Options envisagées

• Comptes gérés par l'application, second facteur pour les rôles sensibles — Choix par défaut des fiches pour des populations externes ; ici, les employés sont dans l'annuaire, et des comptes propres dupliqueraient l'identité et sa révocation. Retenu seulement si l'annuaire ne peut pas offrir le second facteur (environ + 10 à 30 h).
• Fournisseur d'identité géré (OpenID Connect) — Utile pour unifier plusieurs applications ou des exigences avancées ; n'apporte rien tant que l'annuaire remplit le rôle.

Décision

Authentification unique par l'annuaire de l'organisation. Le portail ne gère aucun mot de passe. Le second facteur, porté par l'annuaire, est exigé des administrateurs et de tout rôle qui voit les champs protégés (superviseurs, comité, service de santé et sécurité), soit une centaine de comptes ; l'expiration et la révocation des sessions s'appuient aussi sur l'annuaire. Seuls les rôles applicatifs et le rattachement aux usines sont construits dans le portail. La licence du second facteur est à confirmer avec vous.

Conséquences

• Compromis : Dépendance à la disponibilité et à la configuration de l'annuaire contre aucun mot de passe à protéger.
• Compromis : Friction d'usage du second facteur pour environ cent comptes, contre une protection des données de santé.
• Risque : Le protocole d'accès à l'annuaire est supposé standard ; une interface propriétaire augmenterait l'effort.
• Risque : Une licence de second facteur à acquérir serait à votre charge.

Hypothèses

• L'annuaire peut imposer un second facteur à ces rôles.
• La fiche d'authentification est non vérifiée ; la règle d'identité l'est.

Vérifications prévues

• Confirmer le protocole, l'environnement d'essai et l'interlocuteur de l'annuaire.
• Vérifier que chaque rôle qui voit un champ protégé est soumis au second facteur.
• Vérifier l'expiration et la révocation des sessions selon le niveau ASVS visé, à confirmer.

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)
• Exigences de vérification de sécurité applicative — OWASP ASVS (v2)

DA-4 — Hébergement de la chaîne complète dans une région canadienne

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — lieu d'hébergement des données : au Québec, au Canada ou ailleurs, selon la nature des données — option retenue : Hébergement au Canada, région canadienne vérifiée

Contexte

Données de santé, d'identification et d'employés ; exigence de territoire « Au Canada » déclarée comme politique interne ; client au Québec.

• E-13 — Données au Canada
• E-14 — Exigence de territoire : politique interne, sans obligation externe
• E-15 — Données de santé, d'identification et d'employés : protection renforcée
• Exigence de qualité : Résidence des données
• Exigence de qualité : Confidentialité et renseignements personnels
• Q-1 — Quelles sont les normes d'hébergement infonuagique et de journalisation de votre équipe TI (fournisseur et région approuvés, environnements, format et destination des journaux, gestion des secrets, correctifs) ?

Options envisagées

• Hébergement au Québec, chaîne complète — Respecterait aussi la politique ; non exigé. Variante chiffrable si votre équipe TI ou votre responsable de la protection des renseignements personnels la préfère, car elle évite l'examen des facteurs relatifs à la vie privée pour une communication hors du Québec.
• Hébergement hors du Canada — Contraire à la politique interne ; écartée, non proposée sans votre accord.

Décision

Hébergement au Canada, région canadienne vérifiée, pour la base, les fichiers, les sauvegardes, les journaux et les services auxiliaires (courriel inclus). Aucune obligation légale ou contractuelle de résidence au Québec n'est déclarée, donc le choix par défaut s'applique. Le fournisseur et la région exacts découlent des normes de votre équipe TI, non communiquées.

Conséquences

• Compromis : Choix de fournisseurs plus restreint contre protection des renseignements de santé et d'employés.
• Risque : Une région hors Québec appelle l'examen des facteurs relatifs à la vie privée de la Loi 25, à mener par vous.
• Risque : Un sous-traitant (courriel) pourrait traiter hors du Canada.

Hypothèses

• Loi 25 à considérer ; application de la loi sur les renseignements de santé et de services sociaux selon le statut de l'entreprise, à confirmer. Aucune conformité n'est présumée.
• La fiche d'hébergement est non vérifiée.

Vérifications prévues

• Vérifier la région de traitement de chaque service auxiliaire, sauvegardes et journaux inclus.
• Faire valider par votre responsable de la protection des renseignements personnels l'examen préalable.

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 — Base de données relationnelle pour les dossiers, mesures et journal d'audit

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — stockage principal des données : base relationnelle, base documentaire ou stockage clé-valeur géré — option retenue : Base de données relationnelle

Contexte

Données structurées et liées (déclarations, enquêtes, mesures, employés, usines), intégrité nécessaire, tableau de bord et exports.

• E-3 — Enquête du superviseur et mesures correctives avec relances
• E-7 — Tableau de bord par usine et par mois
• E-11 — Reprise de trois ans de déclarations du chiffrier
• E-24 — Volumétrie : environ 1 200 employés, 1 000 déclarations par mois retenues
• Q-7 — L'exclusion « backup » du dossier vise-t-elle les sauvegardes ? Quelle durée de conservation des sauvegardes et quelle capacité de restauration attendez-vous pour des dossiers contenant des renseignements de santé ?

Options envisagées

• Base documentaire — Les dossiers sont liés (employé, supérieur, usine, mesures) ; les relations et transactions priment.
• Stockage clé-valeur géré — Aucun débit ni cache mesuré ne le justifie à ce volume.

Décision

Base relationnelle gérée, chiffrée au repos, en région canadienne, avec la protection de base de l'hébergeur (restauration à un instant donné, environ 35 jours) et des migrations de schéma versionnées. Aucun service de sauvegarde distinct ni archivage à long terme, conformément à l'exclusion du dossier lue ainsi en attendant votre réponse. Les agrégats du tableau de bord sont calculés dans la même base, sans stockage complémentaire.

Conséquences

• Compromis : Cohérence et rapports simples contre mise à l'échelle des écritures, sans objet à ce volume.
• Compromis : Protection de base seulement : une corruption détectée après environ 35 jours ne serait plus restaurable.
• Risque : Restauration jamais éprouvée : à vérifier avant la mise en service.
• Risque : Durée de conservation des renseignements de santé non fixée ; la protection de base peut être trop courte.

Hypothèses

• L'exclusion « backup » du dossier est lue comme visant un service de sauvegarde distinct ou un archivage long terme, à confirmer.
• La fiche de stockage principal est non vérifiée.

Vérifications prévues

• Confirmer avec vous la portée de l'exclusion, la durée de conservation et la restauration attendue.
• Exécuter un test de restauration avant la bascule.

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-6 — Photos et pièces jointes dans un stockage objet chiffré, hors de la base

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — fichiers déposés ou produits : stockage objet, base de données ou disque du serveur — option retenue : Stockage objet, hors de la base

Contexte

Photos et pièces jointes d'événements et d'enquêtes, avec droits alignés sur le dossier et résidence canadienne.

• E-20 — Dépôt et gestion des photos et pièces jointes
• E-2 — Déclaration par tout employé, sur poste ou téléphone
• E-13 — Données au Canada
• Exigence de qualité : Résidence des données
• Q-7 — L'exclusion « backup » du dossier vise-t-elle les sauvegardes ? Quelle durée de conservation des sauvegardes et quelle capacité de restauration attendez-vous pour des dossiers contenant des renseignements de santé ?

Options envisagées

• Dans la base de données — Les photos prises sur téléphone sont volumineuses et leur nombre croît.
• Disque du serveur d'application — Fichiers durables et sensibles ; le disque ne convient qu'aux fichiers temporaires.

Décision

Stockage objet, hors de la base, en région canadienne, sans accès public, chiffré, avec liens signés de courte durée émis seulement si l'utilisateur a le droit de voir le dossier. Métadonnées et droits en base. Le contrôle du type réel et de la taille précède le dépôt. La protection de base du stockage est distincte de celle de la base ; une restauration conjointe est vérifiée avant la mise en service, sans archivage distinct. Le fournisseur reste une hypothèse selon vos normes d'hébergement.

Conséquences

• Compromis : Coût faible et capacité extensible contre une restauration à coordonner avec la base.
• Risque : Photos montrant des personnes blessées : sensibles comme les champs médicaux, à traiter selon les mêmes droits.
• Risque : Restauration base et fichiers incohérente.

Hypothèses

• Pas de photos à migrer depuis le chiffrier (à confirmer).
• La fiche de stockage de fichiers est non vérifiée.

Vérifications prévues

• Tester l'expiration des liens et le refus d'accès hors droits.
• Confirmer la politique de conservation des photos avec votre responsable.

Références

• Décision type — fichiers déposés ou produits : stockage objet, base de données ou disque du serveur (v2 — référence à vérifier)
• Stockage objet pour les fichiers et documents (v1)
• Stockage objet compatible S3 (OVHcloud — région canadienne Beauharnois confirmée) (v2)

DA-7 — Contrôle d'accès côté serveur par rôle, usine, dossier et champ sensible

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Contexte

Seuls les superviseurs, le comité et le service de santé et sécurité voient les renseignements médicaux et l'identité des blessés ; données de santé et d'employés.

• E-5 — Accès restreint aux renseignements médicaux et à l'identité des blessés
• E-15 — Données de santé, d'identification et d'employés : protection renforcée
• E-18 — Sécurité applicative, chiffrement et journal d'audit des accès sensibles
• Exigence de qualité : Sécurité
• Exigence de qualité : Confidentialité et renseignements personnels
• Q-8 — Comment définit-on un événement « grave », et quels sont les cas particuliers de rôles (déclaration visant le superviseur lui-même, absence du superviseur, déclaration confidentielle) ?
• Q-5 — Quels renseignements de santé précis sont saisis (nature des blessures, soins, arrêts de travail), qui est le responsable de la protection des renseignements personnels, et pour quelle durée les dossiers sont-ils conservés ?
• Q-12 — Souhaitez-vous un test d'intrusion indépendant avant la mise en service, ou un niveau de vérification applicative précis (par exemple exigé par votre équipe TI) ?

Options envisagées

• Contrôle par rôle seulement, au niveau des écrans — Insuffisant : l'autorisation par objet et par champ doit être serveur pour éviter l'accès par appel direct.
• Chiffrement applicatif de chaque champ médical — Variante plus forte que la demande ; à chiffrer à part si votre équipe TI ou la gouvernance l'exige.
• Test d'intrusion indépendant avant la mise en service — Variante chiffrée à part, hors de l'enveloppe ; à retenir si vos normes internes l'exigent.

Décision

Autorisation à moindre privilège appliquée côté serveur, par fonction et par objet : un déclarant voit ses déclarations, un superviseur celles de son équipe, un directeur d'usine les agrégats et les événements graves de son usine sans champs protégés. Les champs médicaux et l'identité des blessés sont filtrés à la lecture, exclus des agrégats, des courriels et des journaux techniques. Chaque consultation de champ protégé est journalisée. Environnements d'essai sans donnée réelle non masquée. Vérifications automatisées et revue de sécurité incluses, niveau ASVS visé à confirmer ; un test d'intrusion indépendant est une variante chiffrée à part, hors de l'enveloppe présentée.

Conséquences

• Compromis : Effort de conception et de tests de sécurité contre réduction du risque d'incident de confidentialité.
• Compromis : Sans test indépendant, la vérification repose sur des contrôles de l'équipe de réalisation.
• Risque : Cas de rôles non définis (déclaration visant le superviseur, absence) pouvant exposer ou bloquer un dossier.
• Risque : Une erreur de filtre sur un champ protégé échapperait aux contrôles automatisés.

Hypothèses

• Échelle de gravité fixe à quatre niveaux ; supérieur suivant en cas de conflit ou d'absence.
• Aucune conformité n'est présumée ; les listes OWASP structurent les vérifications.

Vérifications prévues

• Tests d'autorisation par objet et par champ pour chaque rôle, y compris appels directs aux interfaces.
• Revue du journal d'audit par un responsable désigné.
• Confirmer le niveau de vérification applicative visé et le recours à un test indépendant.

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)
• Classification, chiffrement et résidence des données (v2)

DA-8 — Usage sur téléphone par l'interface web adaptative, sans application native

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — application mobile : site adaptatif, application Web progressive ou native — option retenue : Site Web adaptatif, sans application

Contexte

Déclaration depuis un poste d'usine ou un téléphone ; photos de blessures ou de lieux ; aucun mode hors ligne exigé ni magasin d'applications demandé.

• E-23 — Application web adaptée au téléphone, sans application native
• E-2 — Déclaration par tout employé, sur poste ou téléphone
• E-22 — Accessibilité des écrans visée au niveau AA, vérifiée sur les parcours essentiels
• Q-9 — Les employés utiliseront-ils leur téléphone personnel ou un appareil fourni, un accès web suffit-il, et les avis passent-ils par courriel ou par message texte (selon le choix) ?

Options envisagées

• Application Web progressive installable — Utile pour des notifications poussées ou un hors-ligne court ; aucun n'est demandé. Variante possible si les usines ont des zones sans réseau.
• Native multiplateforme (une base de code) — Magasin, capteurs ou hors-ligne prolongé non exigés ; coût et maintenance supplémentaires, à chiffrer à part.

Décision

Site web adaptatif sans application. La prise de photo passe par le navigateur du téléphone, sans enregistrement dans la galerie de l'appareil lorsque c'est possible, avec une consigne d'usage pour les appareils personnels. Les avis passent par courriel, donc aucune notification mobile n'est requise. Accessibilité : niveau AA des règles WCAG 2.2 visé en hypothèse, vérifié par des contrôles automatisés et des essais manuels (clavier, lecteur d'écran) sur les parcours essentiels, sans audit externe.

Conséquences

• Compromis : Moindre coût et déploiement unique contre expérience moins riche et aucune saisie hors réseau.
• Compromis : Le niveau AA demande des vérifications dès la conception, contre un public élargi.
• Risque : Zones d'usine sans couverture : la déclaration ne serait pas possible sur le moment.
• Risque : Adoption faible si les appareils ne sont pas disponibles.
• Risque : Une copie de photo de blessure peut rester dans la galerie d'un téléphone personnel, hors des droits d'accès du portail, si la capture sans enregistrement n'est pas possible sur l'appareil.

Hypothèses

• Les employés disposent d'un navigateur récent sur poste ou téléphone.
• La fiche mobile est non vérifiée.
• Niveau AA à confirmer avec vous.

Vérifications prévues

• Confirmer les appareils, personnels ou fournis, et la couverture réseau dans les quatre usines.
• Essais de prise de photo sur les modèles courants, dont l'absence de copie dans la galerie.
• Contrôles d'accessibilité automatisés et essais manuels sur la déclaration, l'enquête et la consultation.

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 — Avis et relances par courriel, sans renseignement sensible dans le message

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — notifications aux utilisateurs : courriel transactionnel, texto, notification mobile ou messages dans l'application — option retenue : Courriel transactionnel par un service spécialisé

Contexte

Avis immédiat des événements graves, relances des mesures en retard, notifications demandées par courriel ou message.

• E-4 — Avis immédiat pour les événements graves
• E-21 — Notifications par courriel ou par message
• E-3 — Enquête du superviseur et mesures correctives avec relances
• Q-9 — Les employés utiliseront-ils leur téléphone personnel ou un appareil fourni, un accès web suffit-il, et les avis passent-ils par courriel ou par message texte (selon le choix) ?
• Exigence de qualité : Confidentialité et renseignements personnels

Options envisagées

• Texto par une passerelle — Pertinent pour l'urgence d'un événement grave auprès de personnes sans courriel de poste ; ajoute un fournisseur et un récurrent. Variante à chiffrer si vous la retenez.
• Notification mobile (push) — Requiert une application installée, non retenue.
• Messages dans l'application — Les superviseurs ne sont pas connectés en continu ; insuffisant pour un avis immédiat.

Décision

Courriel transactionnel par un service spécialisé, avec reprise sur échec et région de traitement canadienne à vérifier. Le message contient seulement un lien vers le portail, où les droits s'appliquent : aucun renseignement médical ni identité des blessés. Le message texte reste une alternative, jamais un envoi doublé.

Conséquences

• Compromis : Simplicité et traçabilité contre un délai de lecture non garanti pour un avis urgent.
• Risque : Un avis grave non lu à temps ; la fiabilité de livraison du courriel dépend du fournisseur.
• Risque : Fournisseur de courriel traitant hors du Canada.

Hypothèses

• Tous les destinataires d'avis ont un courriel professionnel dans l'annuaire ou les ressources humaines.
• La fiche de notifications est non vérifiée.

Vérifications prévues

• Confirmer la région de traitement du service de courriels.
• Définir avec vous le délai de livraison attendu pour un avis grave.

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)
• Renseignements personnels au Canada et au Québec — Loi 25, LPRPDE, principes des autorités sur l'IA (v1)

DA-10 — Échanges planifiés avec les ressources humaines et le progiciel de gestion

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

partiellement couverte par les références citées

Décision type

Décision type — intégration avec les systèmes existants : API synchrone, échange asynchrone, fichiers planifiés ou saisie manuelle — option retenue : Échange de fichiers planifié

Contexte

Employés, supérieurs, usines et départements viennent de systèmes tiers ; données de référence qui changent lentement ; mode d'accès inconnu.

• E-9 — Employés et supérieurs issus du système de ressources humaines
• E-10 — Usines et départements issus du progiciel de gestion
• Q-2 — Comment accéder à l'annuaire (protocole d'authentification unique), au système de ressources humaines et au progiciel de gestion (interface, fichier d'export, fréquence) ? L'annuaire peut-il imposer un second facteur aux superviseurs, au comité et au service de santé et sécurité (licence comprise) ? Pouvez-vous fournir des environnements d'essai et un interlocuteur pour chacun ?
• Exigence de qualité : Sécurité

Options envisagées

• API documentée et versionnée, appel synchrone — Choix par défaut, mais le portail doit rester utilisable si le système tiers est lent ou hors ligne ; la copie locale évite ce couplage.
• Saisie manuelle assumée (repli) — Les superviseurs dépendent de la hiérarchie à jour ; la saisie manuelle serait fragile pour 1 200 employés.

Décision

Synchronisation quotidienne planifiée, en lecture seule, des deux référentiels, par export de fichier ou par interface documentée interrogée en lot selon ce que chaque système offre. Le portail garde une copie locale, conserve les anciens codes, signale les employés sans supérieur et valide toute donnée reçue. Les appels exposés ou consommés suivent l'authentification par appel et les quotas de la règle API.

Conséquences

• Compromis : Découplage et résilience contre des données jusqu'à une journée de retard.
• Risque : Interface absente ou propriétaire, environnements d'essai tardifs.
• Risque : Départs ou changements de supérieur non reflétés avant la synchronisation suivante, avec mauvais routage possible d'un dossier.

Hypothèses

• Les deux systèmes fournissent un export ou une interface documentée.
• L'annuaire est traité à part (authentification unique).

Vérifications prévues

• Obtenir pour chaque système le mode d'accès, la fréquence permise, un environnement d'essai et un interlocuteur.
• Définir la règle de repli quand le supérieur est inconnu.

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)
• Sécurité des API — OWASP API Security Top 10 (2023) (v1)

DA-11 — Relances, avis et synchronisations par une file de traitements adossée à la base

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

partiellement couverte par les références citées

Décision type

Décision type — traitements différés : en ligne seulement, file de traitements en base ou courtier de messages dédié — option retenue : File de traitements adossée à la base de données

Contexte

Envoi d'avis avec reprise sur échec, relances des mesures en retard, synchronisations nocturnes, calcul des agrégats, purge.

• E-4 — Avis immédiat pour les événements graves
• E-3 — Enquête du superviseur et mesures correctives avec relances
• E-9 — Employés et supérieurs issus du système de ressources humaines
• E-7 — Tableau de bord par usine et par mois
• Exigence de qualité : Disponibilité

Options envisagées

• Pendant la requête, sans file — Les appels au courriel et aux systèmes tiers peuvent échouer ou être lents ; les relances et synchronisations sont planifiées.
• Courtier de messages dédié — Aucun débit élevé ni plusieurs consommateurs ; composant supplémentaire à exploiter et à payer sans gain à ce volume.

Décision

File de traitements adossée à la base de données, sans service de file distinct, avec tâches planifiées, reprise sur échec et journalisation d'exécution. Un avis grave est inscrit dans la même transaction que l'événement, pour ne pas être perdu. Les volumes sont modestes et une seule application produit et consomme les tâches.

Conséquences

• Compromis : Simplicité et cohérence transactionnelle contre un débit limité, sans objet ici.
• Risque : Tâche échouée sans alerte : un avis grave non envoyé passerait inaperçu.

Hypothèses

• Environ 1 000 déclarations par mois au plus.
• La fiche des traitements différés est non vérifiée.

Vérifications prévues

• Alerte sur toute tâche d'avis en échec ou en attente au-delà d'un délai à fixer avec vous.

Références

• Décision type — traitements différés : en ligne seulement, file de traitements en base ou courtier de messages dédié (v2 — référence à vérifier)

DA-12 — Une seule organisation, cloisonnée par usine seulement au niveau des droits

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — plusieurs organisations dans une même solution : base partagée cloisonnée, base par organisation ou instance par client — option retenue : Une seule organisation (pas de modèle multi-organisations)

Contexte

Une entreprise unique répartie dans quatre usines ; directeurs d'usine et superviseurs limités à leur périmètre.

• E-1 — Remplacer le papier et le chiffrier par un portail unique
• E-5 — Accès restreint aux renseignements médicaux et à l'identité des blessés
• E-10 — Usines et départements issus du progiciel de gestion
• E-25 — Comptes fournis par l'annuaire ; rôles et droits construits dans le portail

Options envisagées

• Base (ou schéma) par organisation — Les usines appartiennent à la même organisation ; l'isolement physique ajouterait des coûts sans exigence documentée.

Décision

Aucun modèle multi-organisations : une seule base et un seul déploiement. L'usine est un attribut de rattachement qui sert aux droits et au tableau de bord, sans isolement physique par usine.

Conséquences

• Compromis : Simplicité et agrégats entre usines faciles contre aucun isolement physique entre usines.
• Risque : Une erreur de filtre par usine exposerait des dossiers d'une autre usine ; à couvrir par des tests.

Hypothèses

• Aucune filiale ni usine d'une autre entité juridique ne s'ajoute.
• La fiche des locataires est non vérifiée.

Vérifications prévues

• Tests d'accès entre usines pour chaque rôle.

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-13 — Journaux d'audit et techniques envoyés vers l'outil central de l'équipe TI

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

partiellement couverte par les références citées

Contexte

Normes de journalisation imposées, accès aux renseignements médicaux à tracer, exploitation par une équipe TI interne.

• E-12 — Exploitation par l'équipe TI selon ses normes d'hébergement et de journalisation
• E-18 — Sécurité applicative, chiffrement et journal d'audit des accès sensibles
• Q-1 — Quelles sont les normes d'hébergement infonuagique et de journalisation de votre équipe TI (fournisseur et région approuvés, environnements, format et destination des journaux, gestion des secrets, correctifs) ?
• Exigence de qualité : Sécurité

Options envisagées

• Journalisation propre au portail seulement — Contraire aux normes imposées et aux pratiques de détection centralisée.

Décision

Journal d'audit applicatif (connexions, consultations de champs protégés, changements de droits) enregistré en base et transmis, avec les journaux techniques, vers l'outil central dans le format et la destination des normes de l'équipe TI. Les journaux ne contiennent aucun contenu médical. Une surveillance avec alertes sur les échecs de tâches et les accès anormaux est prévue ; les responsabilités d'exploitation sont à répartir avec votre équipe selon les fonctions du cadre de cybersécurité cité (gouverner, protéger, détecter, répondre, restaurer).

Conséquences

• Compromis : Intégration aux normes TI contre dépendance à un format non connu.
• Risque : Normes non communiquées : format, rétention et destination peuvent changer l'effort (environ + 20 à 80 h).
• Risque : Journaux conservés trop longtemps contenant des identifiants personnels.

Hypothèses

• Les journaux sont envoyés vers un outil central exportable.
• Durée de conservation des journaux à fixer avec votre équipe.

Vérifications prévues

• Obtenir les normes de journalisation avant la conception.
• Tester qu'une consultation de champ protégé produit une entrée d'audit.

Références

• Excellence opérationnelle et observabilité (v2)
• Cadre de cybersécurité NIST CSF 2.0 — fonctions de gouvernance (v1)
• Risques applicatifs de référence — OWASP Top 10 (édition 2025) (v2)

DA-14 — Disponibilité 24 h sur 7 par plusieurs zones d'une même région canadienne, sans reprise multirégion

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

partiellement couverte par les références citées

Contexte

Disponibilité exigée sans cible chiffrée ; usines possiblement en continu (quarts de nuit) ; protection des données à préciser.

• E-19 — Disponibilité du portail
• Q-6 — Quelles plages de service (usines en continu, quarts de nuit) et quelle durée d'interruption et de perte de données maximale tolérez-vous ?
• Q-7 — L'exclusion « backup » du dossier vise-t-elle les sauvegardes ? Quelle durée de conservation des sauvegardes et quelle capacité de restauration attendez-vous pour des dossiers contenant des renseignements de santé ?
• Exigence de qualité : Disponibilité
• E-13 — Données au Canada

Options envisagées

• Reprise dans une seconde région canadienne — Plus forte que la demande ; environ + 20 à 60 h et un récurrent plus élevé, à retenir si la cible l'exige.
• Une seule zone — Écarté : une panne de zone interromprait les déclarations.

Décision

Hypothèse unique : service 24 h sur 7. Services gérés répartis sur plusieurs zones d'une même région canadienne, protection de base de l'hébergeur avec une restauration vérifiée avant la mise en service, déploiement avec retour arrière. Interruption maximale de quelques heures et perte de données d'une heure au plus sont des hypothèses. Une seconde région canadienne est une variante à chiffrer.

Conséquences

• Compromis : Coût d'infrastructure modéré contre une tolérance limitée aux pannes régionales.
• Risque : Une cible plus stricte que l'hypothèse exigerait de revoir l'infrastructure.
• Risque : Dépendance à la disponibilité de l'annuaire pour la connexion.

Hypothèses

• Cible chiffrée non déclarée ; hypothèses de plage 24 h sur 7, d'interruption et de perte de données ci-dessus.

Vérifications prévues

• Faire valider la cible par vos responsables d'usine.
• Répéter une restauration avant la mise en service.

Références

• Excellence opérationnelle et observabilité (v2)
• Optimisation des coûts et récurrent explicite (v2)

DA-15 — Reprise du chiffrier par un outil ponctuel avec rapport d'écarts et rejeu

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

non couverte par les références — justification propre au dossier

Contexte

Trois ans de déclarations à reprendre en partie, avec qualité et volume réels inconnus.

• E-11 — Reprise de trois ans de déclarations du chiffrier
• Q-3 — Combien de déclarations par mois le chiffrier contient-il réellement, et combien de lignes, de fichiers et de pièces jointes sur trois ans, dans quel état (colonnes uniformes, doublons, texte libre, photos) ?
• E-24 — Volumétrie : environ 1 200 employés, 1 000 déclarations par mois retenues

Options envisagées

• Saisie manuelle de l'historique — Disproportionnée pour plusieurs dizaines de milliers de lignes.
• Ne pas reprendre l'historique — Contraire à la demande ; les tendances du tableau de bord perdraient leur profondeur.

Décision

Outil de reprise ponctuel : lecture du chiffrier, nettoyage, correspondance nominale avec les employés, usines et départements, chargement par lots avec rapport d'écarts à valider par votre équipe, rejeu possible, puis verrouillage après la bascule. Les cas non rapprochés restent identifiés, sans invention de lien. Photos non reprises par hypothèse.

Conséquences

• Compromis : Historique exploitable contre effort de nettoyage et validation par votre équipe.
• Risque : Noms non rapprochables, doublons, texte libre : une part de l'historique pourrait rester non reprise ou à valider manuellement.
• Risque : Données de santé dans le chiffrier : l'outil et les copies de travail doivent respecter la région canadienne et être détruits.

Hypothèses

• Environ 36 000 lignes (1 000 déclarations par mois sur 36 mois), même hypothèse que le dimensionnement du stockage et des envois ; structure régulière.
• Hypothèse non appuyée par une fiche de référence.

Vérifications prévues

• Obtenir un échantillon du chiffrier et son nombre de lignes réel avant la conception de la reprise.
• Valider le rapport d'écarts avec le service de santé et sécurité avant la bascule.

Références

Aucune référence d'architecture citée ; la décision repose sur une justification propre au dossier.

DA-16 — Chaîne de livraison automatisée avec environnements séparés et déploiement contrôlé

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Contexte

Application sur mesure exploitée par l'équipe TI, données sensibles, exigence de sécurité et normes d'hébergement imposées.

• E-12 — Exploitation par l'équipe TI selon ses normes d'hébergement et de journalisation
• E-18 — Sécurité applicative, chiffrement et journal d'audit des accès sensibles
• Exigence de qualité : Sécurité
• Q-1 — Quelles sont les normes d'hébergement infonuagique et de journalisation de votre équipe TI (fournisseur et région approuvés, environnements, format et destination des journaux, gestion des secrets, correctifs) ?

Options envisagées

• Déploiement manuel sans automatisation — Non reproductible et sujet aux erreurs sur un système de santé et sécurité.

Décision

Code revu avant fusion, tests automatisés sur les demandes de fusion, construction reproductible, inventaire et suivi des dépendances, secrets hors du code, infrastructure décrite par du code, trois environnements séparés et déploiement en production déclenché manuellement après approbation, avec retour arrière. Le niveau de garantie de la chaîne est une hypothèse à confirmer avec votre équipe.

Conséquences

• Compromis : Mise en place initiale de la chaîne contre des livraisons sûres et réversibles.
• Risque : Chaîne sans responsable après le transfert ; dépendance compromise ou abandonnée.

Hypothèses

• Votre équipe TI peut prescrire ou fournir l'outillage de chaîne ; à confirmer.

Vérifications prévues

• Désigner un responsable de la chaîne et des mises à jour de dépendances côté TI.

Références

• Livraison continue et chaîne d'approvisionnement logicielle — DORA, SLSA, NIST SSDF (v2)
• Risques applicatifs de référence — OWASP Top 10 (édition 2025) (v2)

DA-17 — Aucune IA générative dans la solution

Statut

Proposée par l'IA, à confirmer avec vous

Date

16 octobre 2026

Couverture

couverte par les références citées

Décision type

Décision type — fonction d'IA générative : aucune, appel d'un modèle par API, recherche augmentée sur des documents, ou agent outillé — option retenue : Aucune IA générative (règles explicites ou recherche classique)

Contexte

Le besoin se décrit par des règles explicites ; données de santé et d'employés sous résidence canadienne.

• E-4 — Avis immédiat pour les événements graves
• E-5 — Accès restreint aux renseignements médicaux et à l'identité des blessés
• E-15 — Données de santé, d'identification et d'employés : protection renforcée
• Exigence de qualité : Confidentialité et renseignements personnels

Options envisagées

• Appel d'un modèle de langage par API, tâche bornée et sortie structurée — Possible pour résumer ou classer, mais aucune fonction demandée ne l'exige ; transmettre des renseignements de santé à un fournisseur ajouterait des garde-fous et un examen de confidentialité.

Décision

Aucune IA générative. Le seuil de gravité, le routage au superviseur, les relances et les agrégats reposent sur des règles stables. Les pistes d'IA sont présentées à part, non retenues et non chiffrées.

Conséquences

• Compromis : Comportement prévisible et périmètre simple contre l'absence d'aide à la lecture du texte libre.
• Risque : Aucun risque propre à l'IA ; l'analyse du texte libre reste manuelle.

Hypothèses

• Le client n'a pas demandé de fonction d'IA.

Vérifications prévues

• Revoir si une fonction d'IA est ajoutée : garde-fous et lieu d'inférence canadien à documenter.

Références

• Décision type — fonction d'IA générative : aucune, appel d'un modèle par API, recherche augmentée sur des documents, ou agent outillé (v2)
• Garde-fous d'une fonction d'IA générative — données, qualité, coût, repli (v2)