Une plateforme numérique de prévention des risques psychosociaux dans le cadre de la Loi 27

Contexte

La Loi 27 a modernisé le régime québécois de santé et de sécurité du travail et a intégré les risques psychosociaux — surcharge, autonomie, reconnaissance, soutien social, harcèlement — au devoir de prévention de l’employeur. Un cabinet canadien de services professionnels offre cette évaluation à ses organisations clientes sous forme de mandat-conseil : sonder les employés, mesurer les facteurs de risque, remettre un rapport avec des recommandations. Avec des chiffriers et des outils de sondage génériques, cela ne tient pas au-delà de quelques mandats, et les données d’une organisation côtoient celles d’une autre. Le cabinet avait besoin d’une plateforme à lui, exploitable pour chaque organisation cliente, en français et en anglais, avec le contenu d’évaluation sous son contrôle. Je l’ai conçue et bâtie avec mon équipe chez SOFT M POWER CANADA, et elle est en production.

Défi

Trois populations se partagent la même plateforme : le cabinet, ses organisations clientes et leurs employés. Chaque lecture doit être limitée à l’organisation et au rôle, et le sondage doit permettre de répondre à 146 questions en six modules sur plusieurs séances sans rien perdre. Le contenu d’évaluation — modules, questions, recommandations — devait rester modifiable par le cabinet et bilingue dans la base, pas codé en dur. Les résultats devaient être comparables d’un mandat à l’autre : une logique de scores et de recommandations déterministe, qu’un consultant peut expliquer à un client. Les rapports devaient s’imprimer et se partager comme des documents, dans l’une ou l’autre langue, sans faire de la plateforme un système de gestion documentaire. Et tout cela devait être bâti par une petite équipe dans un calendrier serré, puis résister à une revue de sécurité externe.

Mon rôle

Fondateur et architecte. J’ai défini le produit à partir de la pratique d’évaluation du cabinet : personas, modèle à quatre rôles, règles d’affaires des scores et des recommandations, et spécifications fonctionnelles fonctionnalité par fonctionnalité, avec critères de préparation et d’achèvement. J’ai conçu le modèle de données et la stratégie d’isolation — la sécurité au niveau des lignes comme véritable barrière, l’interface comme guide — et fixé la direction technique : backend PostgreSQL géré, fonctions sans serveur, rapports HTML imprimés par le navigateur. Mon équipe chez SOFT M POWER CANADA a bâti, testé et livré la plateforme avec un flux de développement assisté par l’IA piloté par ces spécifications, et nous l’exploitons pour le cabinet : versions, correctifs de sécurité, tâches de rappel et d’audit, et migration du backend vers un projet en région canadienne en 2026.

Architecture / approche

Un exploitant, plusieurs organisations, une seule base : une clé d’organisation sur chaque table d’affaires, et des politiques de sécurité au niveau des lignes qui limitent chacun des quatre rôles à ce qu’il peut lire ou écrire, appliquées par des fonctions SQL plutôt que par l’interface. Le référentiel du sondage est de la donnée, pas du code : modules, questions et recommandations sont des lignes bilingues que le cabinet modifie depuis une page d’administration, sous la garde d’un test d’intégrité. Les scores et les recommandations sont un moteur de règles : pourcentage de réponses négatives par question, cinq paliers de risque par module, seuil de 40 % complété jusqu’à un top 25, classement par score et par priorité. Les rapports sont générés en HTML et imprimés en PDF par le navigateur, en français ou en anglais.

Technologie

React 18 avec TypeScript et Vite, Tailwind et shadcn/ui, React Router, TanStack Query, react-hook-form avec validation zod, recharts pour les vues de rapports et papaparse pour l’import CSV. Un backend PostgreSQL géré avec authentification : 27 tables sous sécurité au niveau des lignes, 124 politiques, 35 fonctions SQL et 30 déclencheurs, livrés par 301 migrations; 25 fonctions sans serveur en Deno pour le crochet d’authentification, la réinitialisation par code à usage unique, la validation de connexion côté serveur, les courriels transactionnels bilingues, les rapports servis par clé temporaire et les tâches planifiées; trois tâches planifiées dans la base pour les rappels horaires, l’audit hebdomadaire et le digest d’alertes. Un mécanisme FR/EN maison, un guide utilisateur intégré par rôle, et une page de validation qui exécute 76 tests d’intégration contre le backend réel.

Exécution

Née en mai 2025 comme gestionnaire de formulaires RH générique, la plateforme a été recentrée en quelques semaines sur les risques psychosociaux; dix-neuf versions documentées ont suivi, de la v1.0 (juin 2025) à la v1.19 (mars 2026), avec spécifications et plan de tests maintenus avec le code. La logique de recommandations a connu trois itérations — seuil seul, top 25 seul, puis hybride avec indice de performance —, consignées dans les notes de version. La génération PDF côté serveur a été tentée puis abandonnée au profit de rapports HTML imprimables. Un test d’intrusion externe fin 2025 a conduit à une série de durcissements côté serveur, confirmés par un nouveau test début 2026. En septembre 2026, tout le backend — schéma, données, comptes, tâches et fonctions — a été migré vers un projet en région canadienne, après un audit de pré-bascule en lecture seule.

Contraintes

Des données sensibles par nature — des réponses sur la surcharge, la reconnaissance et le harcèlement, détenues pour des organisations clientes du cabinet —, d’où une isolation par organisation et par rôle imposée dans la base. Un exploitant unique avec plusieurs organisations clientes plutôt qu’un SaaS multilocataire en libre-service, ce qui explique le modèle de rôles et l’import CSV plutôt que l’inscription. Deux langues dans chaque écran, chaque courriel et chaque rapport. Pas de dépôt de documents : les rapports existent comme HTML généré, pas comme fichiers. Une petite équipe et un flux assisté par l’IA, tenus en ligne par des spécifications écrites et des tests d’intégrité. Et un cadre légal que la plateforme soutient sans le certifier : l’évaluation éclaire les professionnels du cabinet, elle ne remplace pas leur jugement ni ne garantit la conformité à la Loi 27.

Leçons clés

1. L’isolation appartient à la base de données : la sécurité au niveau des lignes est la barrière, l’interface n’est que le guide.
2. Quand le contenu d’évaluation est de la donnée, ce sont les experts du domaine qui le possèdent — et un test d’intégrité garde la correspondance honnête.
3. Un moteur de règles déterministe est le bon outil quand chaque recommandation doit pouvoir être expliquée à un client; l’IA aurait ajouté de l’opacité, pas de la valeur.
4. Le pipeline de rapport le plus simple qui se livre — du HTML imprimé par le navigateur — a battu deux tentatives de PDF côté serveur.
5. Avec le développement assisté par l’IA, ce sont les spécifications écrites et les notes de version qui gardent cohérente une base de code qui évolue vite.