Une technologie qui se vérifie.

Un cœur métier commun. Des responsabilités claires.

Oronela est en cours de finalisation. Les 18 modules relient les soins, l’accompagnement, l’administration et l’exploitation. Vous choisissez le périmètre adapté à votre établissement. La plateforme technique réunit la connexion, les droits actuels, le stockage chiffré, les tâches de fond et les modifications traçables. Un module reçoit les informations d’autres domaines via des interfaces définies, au lieu de modifier librement leurs données.

L’interface de navigateur utilise Vue et TypeScript. Le cœur métier côté serveur et l’API sont écrits en Rust. SQL définit les structures de données, les règles d’intégrité et les migrations dans PostgreSQL. Python prend en charge les outils de contrôle, les processus d’exploitation et le fonctionnement privé de l’IA. La logique exécutable et ses interfaces se trouvent dans le dépôt du produit avec les tests correspondants.

L’interface communique avec une API contrôlée. Un backend-for-frontend gère la session côté serveur et relie l’interface à l’identité et aux processus métier. L’appareil du navigateur ne reçoit ni accès direct à la base de données ni connexion libre au serveur de modèle. Un écran ouvert ne remplace pas non plus une vérification des droits : avant une action engageante, le tenant, le rôle, la responsabilité, le contexte métier et la révision actuelle sont à nouveau pris en compte.

1. 01

   Espace de travail

   Fenêtres des résidents, soins, personnel, cuisine et administration dans le navigateur.

2. 02

   API et cœur métier

   Droits actuels, règles métier et contrats de modules versionnés.

3. 03

   Données protégées

   PostgreSQL, documents chiffrés, gestion des clés et audit.

4. 04

   Transmissions autorisées

   Connexions partenaires et IA privée facultative avec périmètre de données limité.

Les versions précisément fixées.

Ce tableau présente les versions fixées dans le dépôt du produit au 4 octobre 2026. Il décrit l’état traçable du développement et de l’intégration. Pour une installation, le paquet de version correspondant, sa configuration autorisée et son justificatif de version s’appliquent également.

Des outils Python sont également inclus. Aucune version commune de Python n’est fixée dans le manifeste racine examiné ; nous ne lui attribuons donc aucune version inventée. La version est consignée dans la preuve d’exploitation et de vérification concernée. Le modèle, l’environnement d’exécution et la configuration sont gérés comme des versions distinctes.

Références de version : rust-toolchain.toml, Cargo.toml et Cargo.lock, package.json et pnpm-lock.yaml, compose.yaml ainsi que le justificatif documenté de l’environnement d’exécution privé de l’IA.

Oronela SaaS ou votre propre installation.

Chaque client peut choisir entre le service Oronela SaaS et un système exploité par ses soins. Avec le service SaaS, Oronela assure l’exploitation sur sa propre infrastructure suisse. Le stockage, le traitement et l’IA facultative restent en Suisse. L’infrastructure est certifiée ISO 27001 ; cela ne signifie pas que l’application possède sa propre certification.

Pour une installation exploitée par vos soins, votre établissement détermine avec son équipe informatique le lieu d’exploitation et la responsabilité technique. Ces clients reçoivent également des mises à jour continues. Le paquet de livraison, les versions qu’il contient et les étapes documentées d’installation et de migration constituent la base commune. L’exploitant assume les responsabilités correspondantes concernant les accès, les frontières réseau, les clés, les sauvegardes et la surveillance, ou mandate un partenaire d’exploitation adapté.

Les fonctionnalités sont configurées selon les besoins. L’IA est elle aussi un choix délibéré de votre établissement. Une exploitation propre ne justifie pas la transmission de données à un service IA public : le traitement par le modèle et les sources autorisées restent dans l’environnement propre configuré à cet effet. Le concept système exclut tout remplacement silencieux par une IA tierce.

• SaaS : Oronela assume l’exploitation convenue et la livraison contrôlée des mises à jour.
• Exploitation propre : votre service informatique reçoit les bases techniques et des mises à jour continues pour sa propre installation.
• Dans les deux cas : les versions, modifications de sécurité, dépendances et indications de migration restent traçables.

L’accès au code source est inclus.

Tous les clients Oronela ont accès au code source. Les promesses de sécurité doivent pouvoir être vérifiées dans la mise en œuvre réelle. Votre service informatique ou un professionnel mandaté par vos soins peut comprendre comment une autorisation est vérifiée, où une clé est utilisée, quelles données reçoit une connexion et comment une modification est journalisée.

Comprendre le système va au-delà des interfaces visibles. Le patrimoine technique comprend les modules métier, les contrats API, les schémas de base de données, les migrations, les tests et la documentation de développement. Le code propre et les documents de développement utilisent l’anglais afin que les interfaces et les connaissances de maintenance restent sans ambiguïté au-delà des personnes et des langues. La documentation utilisateur reste disponible dans la langue de votre interface.

L’accès au code source constitue également une base pour des audits indépendants et une décision d’exploitation à long terme. Il permet à votre établissement de vérifier de manière ciblée les parcours critiques et de poser des questions à partir de passages concrets. Les identifiants d’accès, clés privées et données des résidents ne font évidemment pas partie de ce code source.

Protéger les données lors de leur transmission et de leur stockage.

Le cœur métier contient un chiffrement authentifié AES-256-GCM. Une nouvelle clé de données est utilisée pour chaque chiffrement. OpenBao protège cette clé dans un service de clés distinct. Le texte en clair d’un enregistrement métier n’est pas transmis au service de clés pour cette opération.

L’information chiffrée est liée à son identité attendue : l’organisation, l’objet stocké, la finalité et la révision font partie du contexte vérifié. Il ne suffit donc pas de copier un contenu chiffré dans un autre enregistrement. Les modifications du contenu ou un contexte inadapté entraînent un rejet. Le déchiffrement reste en outre lié à une autorisation métier actuelle ; un contenu cryptographique valide ne permet pas à lui seul un accès.

Les documents volumineux sont traités par segments authentifiés. Le parcours documentaire existant vérifie notamment la longueur complète, la fin du document et l’accusé final. Des parties déchiffrées individuellement ne sont pas déjà considérées comme un document validé. Les versions de clés et révisions de documents restent traçables afin que la rotation et la restauration prennent en compte les bons originaux.

Le système utilise HTTPS pour la transmission. Selon leur profil d’exploitation, les connexions entre services internes disposent de certificats et d’identités de service vérifiés, notamment au moyen d’une authentification TLS mutuelle. Les rôles de base de données, les accès réseau et les finalités des clés sont limités. En cas d’erreur, ni les contenus médicaux ni les tokens ne sont affichés dans les messages d’erreur généraux.

• Champs et documents : un chiffrement authentifié plutôt qu’une simple mention de confidentialité.
• Clés : gestion distincte avec accès lié à l’organisation et à la finalité.
• Transmission : connexions protégées et destinataires explicitement autorisés.
• Restauration : les originaux, l’historique des clés et la lisibilité effective sont examinés ensemble.

Les limites entre organisations et les droits métier agissent ensemble.

Un établissement de soins et un site ne sont pas des filtres quelconques dans l’interface. Le serveur travaille avec l’organisation établie de manière fiable et les autorisations actuelles de la personne agissante. Le stockage des données et les rôles limités de base de données complètent cette frontière métier. Un identifiant de résident d’autrui ou un formulaire de navigateur manipulé ne doit créer aucun accès.

Les droits peuvent changer pendant qu’une fenêtre est ouverte. Une commande engageante vérifie donc la situation actuelle. Selon l’opération, cela comprend la compétence métier, la finalité, l’état des sources et la révision. Une copie périmée ou une autorisation expirée ne devient pas valable simplement parce qu’elle a été affichée auparavant.

Chaque module reste responsable de ses propres informations métier. Par exemple, l’admission et le séjour relèvent de M01, les places et les chambres de M05, et les bases tarifaires contractuelles de M11. Les autres domaines obtiennent les informations nécessaires via des contrats versionnés. Cela permet d’éviter les copies contradictoires et les responsabilités incertaines.

Un audit suit le processus réel.

Pour les modifications pertinentes, le chemin d’audit technique consigne la source, l’heure, le contexte et la révision. L’état métier, l’historique, l’audit et l’ordre consécutif sortant sont traités ensemble dans la voie transactionnelle prévue. L’outbox sépare l’enregistrement durable d’un ordre de sa livraison ultérieure. Un ordre peut ainsi être retraité après une interruption de connexion sans doubler aveuglément son effet métier.

Les événements d’audit sont liés à leur prédécesseur par SHA-256. La vérification prend en compte les octets originaux stockés et le type d’événement concerné. L’archive séparée vérifie les paquets reçus et émet des accusés signés ; le parcours d’accusé existant utilise Ed25519. La source ne confirme l’archivage qu’à partir de l’accusé correspondant dûment vérifié. Une remise technique et une confirmation métier restent des faits différents.

Les autorisations de lecture pertinentes disposent elles aussi d’un contexte traçable. Une vue d’audit limitée ne prétend pas être exhaustive pour les domaines historiques qu’elle ne contient pas. Lors d’un contrôle, le périmètre, la période, les liens de chaîne, les accusés d’archivage et les droits d’accès sont donc examinés ensemble.

L’audit de sécurité et de qualité du produit complète ces preuves d’exploitation. Les modifications sont rattachées aux exigences, aux risques, à la protection des données et aux dépendances. Les bases de validation exigent une revue indépendante, des résultats de contrôle concrets et une évaluation responsable sur les plans métier, sécuritaire et opérationnel. Un test de composant réussi ne remplace ni une réception clinique ni un audit indépendant.

Évolution continue sans modifications incontrôlées des données.

Les processus de soins, bases légales et exigences techniques évoluent. Oronela est donc développé en continu. Les besoins réels des établissements alimentent des exigences concrètes ; ils donnent lieu à des modifications traçables avec des tests et des effets documentés. Les processus éprouvés, interfaces et preuves historiques restent une responsabilité commune du développement métier et de l’exploitation.

Le versionnement concerne l’application, les bibliothèques, les migrations de base de données, les règles et l’IA facultative. Une règle modifiée ne doit pas réinterpréter silencieusement un justificatif historique de soins ou de facturation. Une proposition actuelle référence les sources effectivement utilisées ; un original déjà créé conserve sa base d’époque.

Les modifications de base de données sont gérées dans des migrations ordonnées. Le processus de validation exige des états de départ et d’arrivée définis, des dépendances, la compatibilité, des sommes de contrôle et une voie de restauration. Un retour sûr dépend du type concret de modification et des écritures ultérieures. Lorsqu’un retour direct n’est pas autorisé, une correction ou une restauration documentée est nécessaire.

Une mise à jour pour une installation exploitée par vos soins reste vérifiable à l’aide du paquet de version. Celui-ci comprend les nouvelles versions, les effets sur la configuration et les interfaces ainsi que les étapes de migration nécessaires. Dans l’exploitation SaaS, la même version autorisée constitue la base de la livraison contrôlée.

• Comprendre l’exigence et son impact.
• Modifier ensemble le code, les tests et la documentation.
• Réunir une vérification indépendante et les justificatifs adaptés.
• Autoriser la version exacte et la livrer de manière contrôlée.
• Observer l’exploitation, recueillir les retours et fournir des corrections traçables.

L’IA reste facultative et dans votre environnement de données.

Oronela fonctionne avec les modules choisis par votre établissement. L’IA est utilisée uniquement lorsque vous le souhaitez et que les fonctions concernées sont activées. Dans le service Oronela SaaS, le traitement des modèles et l’accès aux connaissances fonctionnent sur les propres serveurs Oronela en Suisse. Aucun appel caché à un fournisseur d’IA public.

L’état de contrôle technique comprend un environnement Qwen réellement utilisé localement. La version du modèle, l’environnement d’exécution et la provenance des artefacts sont consignés séparément. Le modèle reçoit le contexte nécessaire à une finalité autorisée. Les sources permises, la personne actuellement agissante et le retrait d’un contexte font partie du chemin de l’application.

Une réponse reste une proposition avec des sources distinctes. Une synthèse ne remplace pas une observation documentée, et une recommandation de planning n’annule pas une règle métier. Dans le cas de vérification documenté, le modèle choisit entre des propositions de planning déjà vérifiées à nouveau ; il ne modifie pas librement leurs affectations. La validation reste entre les mains des personnes autorisées.

La qualité du modèle est évaluée à l’aide de cas métier adaptés et de contrôles de protection des données. La couverture de code classique peut mesurer la logique des adaptateurs, mais ne peut pas justifier une affirmation de 100 pour cent de réponses correctes du modèle. Une nouvelle version de modèle ou de prompt reçoit donc son propre contexte d’évaluation et de validation.

Votre service informatique peut examiner les détails.

Nous présentons les propriétés techniques de manière à ce qu’elles restent vérifiables. Les questions de chiffrement, de limites entre organisations, de versions ou de restauration peuvent être discutées à partir de mises en œuvre et de justificatifs concrets. L’accès au code source permet à vos spécialistes d’examiner eux-mêmes les chemins importants pour votre établissement.

Pour l’exploitation, le périmètre réel de livraison, sa configuration et les validations associées sont examinés ensemble. Des textes généraux sur le produit ne remplacent pas ces documents. Contactez-nous si votre équipe informatique, votre responsable de la protection des données ou un auditeur indépendant a besoin d’une preuve particulière, ou si vous souhaitez discuter avec nous d’une exploitation propre.