Orysk

Le contexte

Prevensys est un cabinet toulousain de prévention des risques professionnels. Ses consultants rédigent des documents uniques d'évaluation des risques (DUERP), diagnostiquent les risques psychosociaux et forment à la santé et à la sécurité au travail. En février 2022, son directeur général nous envoie un cahier des charges : un logiciel en ligne, vendu sur abonnement, pour que les clients du cabinet pilotent eux-mêmes leur document unique.

Le devis est signé en mai 2022, le premier commit date du 19 mai, une version alpha tourne en septembre et la version 1.0 sort en avril 2023. Le logiciel s'appelle d'abord Préven'SaaS, puis prend le nom d'Orysk avec sa nouvelle charte graphique au printemps 2023. Le code appartient à Prevensys.

Ce que fait le logiciel

Un DUERP recense, pour chaque unité de travail d'un établissement, les risques auxquels les salariés sont exposés, leur fréquence, leur gravité et les actions prévues pour les réduire. Orysk guide l'évaluation par un questionnaire d'environ 175 questions, calcule les indices de risque et de maîtrise, et produit les documents réglementaires : le document unique, le plan d'action, le programme annuel de prévention (PAPRIPACT) et l'affichage obligatoire, avec un QR code qui renvoie vers la version en ligne.

Les actions se suivent en tableau, en calendrier ou en kanban. Cinq rôles se partagent l'application, de l'équipe Prevensys, qui voit tous les clients, jusqu'à l'observateur en lecture seule. Depuis septembre 2026, un second module recueille les signalements des salariés sur le terrain.

Les défis techniques

La plupart sont arrivés avec la croissance du produit : les premiers clients d'Orysk avaient un établissement, les plus gros en ont aujourd'hui plusieurs centaines.

• Passer d'un établissement à plusieurs centaines

  La version 2.0, livrée en septembre 2025, a ajouté la gestion multi-établissement et un circuit d'approbation des évaluations. L'application avait été pensée pour de petits comptes et rechargeait toutes ses données à chaque écran. Sur un compte de 706 établissements et plus de 100 000 risques évalués, ce fonctionnement ne tenait plus.

• Une table de lecture tenue à jour par le serveur

  Pour afficher d'un coup les actions de tous les établissements, nous avons ajouté une table dénormalisée, alimentée par une fonction serveur à chaque modification, puis une pagination côté serveur. La migration a reconstitué 678 125 lignes, vérifiées à 100 % contre les données d'origine. Le module terrain, conçu ensuite, a prévu sa structure de lecture dès le départ au lieu de l'ajouter après coup.

• Les traitements longs sortis du navigateur

  Modifier en une fois les actions de nombreux établissements, ou générer un registre volumineux, gelait l'onglet. Ces traitements passent désormais par des tâches côté serveur : l'utilisateur lance l'opération, le serveur la découpe en lots de 400 et un indicateur suit l'avancement en direct.

• Un tableau de bord qui ne charge que ce qu'on regarde

  Sur le plus gros compte, ouvrir le tableau de bord multi-établissement déclenchait environ 1 400 requêtes pour les seules approbations. Depuis la version 2.12, chaque bloc se charge quand on l'ouvre. Côté Angular, il a fallu passer par des ng-template plutôt que par de la projection de contenu, parce qu'un contenu projeté est créé par son parent même quand il est masqué.

• Un module terrain relié au DUERP

  Le module santé et sécurité, livré en version 3.0 le 9 septembre 2026, permet à un salarié de faire un signalement sans avoir de compte. Chaque signalement se reflète dans le DUERP de l'établissement, et le statut des actions suit dans les deux sens. Le signalement fait foi, le DUERP n'en est qu'un reflet reconstruit. Les registres et rapports du module sont générés côté serveur sur les trames officielles du client, en PDF et en Excel.

• Les données de chaque client cloisonnées

  Avec le module terrain, des personnes sans compte écrivent dans l'application. La sécurité a été reprise en même temps : règles d'accès aux données et aux fichiers cloisonnées par client, écritures sensibles et envois de mails passés côté serveur, vérification App Check sur les fonctions publiques, et suivi d'un signalement par un lien à jeton qui n'expose aucune donnée personnelle.

Un projet qui a changé de rythme

Jusqu'en 2025, Orysk sortait quelques versions par an, déployées depuis un poste de développeur. Entre janvier et septembre 2026, il en a sorti 25, soit environ trois par mois, et l'outillage a dû suivre.

Depuis mars 2026, une pré-production alimentée par une copie anonymisée de la production reçoit chaque version avant la mise en ligne. Chaque modification passe par une pull request relue. La chaîne d'intégration GitHub Actions vérifie le formatage, le lint, les tests et le build, puis ne déploie que ce qui a changé : l'interface, les fonctions serveur ou les règles de sécurité, jamais des règles avant les fonctions dont elles dépendent. Les notes de chaque version listent les prérequis, les migrations et les vérifications de la mise en production.

Le format

Les gros lots sont chiffrés au forfait, sur cahier des charges. Le support et les petites évolutions sont décomptés au temps passé, version par version, avec le détail des tickets dans un espace Notion partagé avec Prevensys et classé par criticité.

Le directeur général de Prevensys recette lui-même chaque lot sur la pré-production avant sa mise en ligne. Pour le module terrain, notre recette interne a suivi en plus un cahier de 83 tests.

Technologies

• Angular
• NgRx
• Firebase
• Cloud Functions
• Firestore
• pdf-lib
• GitHub Actions