Rosie — architecture, sécurité, exploitation

Rosie est une application web progressive en JavaScript natif. L’application tourne comme processus Node sur une instance Debian chez Infomaniak, en Suisse, précédée de Caddy comme proxy inverse avec gestion automatique des certificats. La persistance passe par libSQL/SQLite sur la même instance (mode WAL), le stockage d’objets par le stockage d’objets compatible S3 d’Infomaniak. Le service worker utilise un CACHE_PREFIX par version. Un service de protection est placé devant le site public — il ne conserve aucune donnée ; l’interface s’adresse directement à l’instance suisse.

• Domaine principal : rosie-app.ch (y compris www).
• Alias / miroir : rosie-planer.com — sous forme de redirection 301. Tenir compte d’une fenêtre de cache d’environ deux minutes, qui se résorbe d’elle-même. Vérification immédiate de l’origine via ?cb=<random>.
• Sous-domaine de l’application : l’application tourne sous un nom propre qui pointe directement sur l’instance suisse (« DNS seulement », sans service intermédiaire).
• Aucune entrée générique. *.rosie-app.ch n’existe pas — un nom inventé ne se résout pas. C’est voulu et cela exclut la prise de contrôle d’un sous-domaine.
• Service de protection en amont uniquement pour le site public ; il ne conserve aucune donnée client.

• sw.js avec CACHE_PREFIX, estampillé depuis shared/version.mjs (scripts/sync-version.mjs).
• Cache en amont : environ deux minutes de décalage après une mise en production, qui se résorbe seul.
• immutableen-tête de cache pour les ressources versionnées.
• Bibliothèques chargées à la demande via _loadVendor — XLSX, html2canvas.
• Écran de démarrage iOS en PNG obligatoire — WebP abandonné depuis la version r168.
• Pas de synchronisation en arrière-plan — volontairement : un rejeu sans onglet ouvert n’aurait pas de jeton valide et risquerait des doubles écritures faute de clés d’idempotence. La file d’attente du chat ne se vide qu’avec l’application ouverte (voir docs/OFFLINE.md).
• Notifications web sur iOS uniquement dans l’application installée — imposer l’ajout à l’écran d’accueil.

• Clés VAPID (publique et privée) stockées comme secrets sur l’instance, sous /etc/rosie/env.
• subscribeToPushNotifications est un UPSERT idempotent.
• Les heures de silence sont respectées.
• Activation par catégorie d’alerte: bounty · planPublished · adminAlert · messages · absenceResult.

• Uniquement HTTPS sortant sur le port 443.
• Autorisation pour rosie-app.ch et le sous-domaine de l’application. Aucune autre destination n’est nécessaire — l’application n’appelle d’elle-même aucun service chez le client.
• Aucun port entrant.
• Pas de WebSocket nécessaire — l’application interroge le serveur toutes les 60 secondes.

Envoi par SMTP vers une boîte suisse chez Hostpoint. L’expéditeur de tous les courriels du système est support@rosie-app.ch — une adresse à laquelle on peut répondre, pas une impasse. SPF, DKIM et DMARC sont configurés ; nous recommandons de tester une fois la remise contre le filtre antispam du client après la mise en place.

• iOS 14.5+, Android 8.0+.
• Application web — aucun paquet de magasin d’applications.
• Le MDM peut configurer le navigateur préféré, les raccourcis sur l’écran d’accueil et les sites de confiance .
• À noter : Notifications web sur iOS exige l’application installée ; écran de démarrage iOS en PNG (pas de WebP).

Les migrations se trouvent sous database/migrations/ , numérotées à la suite, et ne s’appliquent que vers l’avant. L’état actuel figure dans le répertoire lui-même — cette page ne cite volontairement aucun numéro, qui serait faux dès la version suivante. Chaque passage est suivi d’une vérification du schéma. Les migrations sont construites de manière à pouvoir reconstituer entièrement une base vide.

• Sauvegardes automatiques de la base de données, chiffrées et déposées hors site.
• Fenêtre de restauration de 30 jours avec des points de restauration horaires (perte de données maximale : une heure).
• Stockage d’objets est sauvegardé séparément.
• Export complet des données par mandant, à tout moment depuis l’interface d’administration.
• Pas de redondance géographique. Une seule instance de production est exploitée volontairement — un redémarrage ou une mise à jour entraîne une brève interruption. C’est un compromis connu et assumé, rattrapable sans changer l’architecture.

À chaque version correspond une étiquette checkpoint-rNNN-deployed dans le système de gestion du code source. On peut ainsi prouver à tout moment quelle version était en production et quand.

• Filtrage des mandants côté serveur — tenant_id dans chaque requête.
• Les variables globales du mandant en mémoire sont vidées à la déconnexion par _resetTenantCalendarData() (six variables de calendrier).
• Les tests de fuite entre mandants sont figés par des cas de régression.
• Déclencheur d’enregistrement par marqueur de mandant companySettingsDirty.

• X-Worker-Version (r166 A10), X-Request-Id dans chaque réponse.
• Web Vitals → /api/analytics, envoi en keepalive, signal « Do Not Track » respecté.
• Filtre des données personnelles avant toute analyse.
• k-anonymat ≥ 4 pour les graphiques agrégés.
• Journaux se trouvent sur l’instance (systemd/journald) et sont exploités par le fournisseur ; une surveillance externe contrôle la disponibilité et alerte.

• Objectifs LCP / CLS / INP comme budget de performance.
• Correction du décalage visuel: width / height sur les balises <img>.
• Bibliothèques chargées à la demande via _loadVendor — XLSX / html2canvas.
• Économie de batterie : l’interrogation s’interrompt lorsque document.hidden (pause à la perte de visibilité).

• Fournisseur d’IA : activable par mandant ; un service fixe par usage, sans service de repli automatique. Le fournisseur utilisé figure dans la liste des sous-traitants ultérieurs du contrat de sous-traitance — pas ici, afin que cette page ne devienne pas fausse en cas de changement.
• Limitation de débit : 30 requêtes par heure et par utilisateur.
• Le filtre de données personnelles retire adresse électronique, numéro AVS, IBAN, téléphone et date avant chaque appel au service d’IA.
• Tâches planifiées de l’IA 0 2 / 0 4 pour l’apprentissage des motifs de tâches — requêtes sans staff.id.
• Reconnaissance vocale : assurée par le navigateur (Web Speech API) ; selon le navigateur ou le système d’exploitation, l’enregistrement est envoyé à son propre service de reconnaissance vocale — ROSIE ne reçoit ni ne conserve aucun enregistrement audio. Pour la reconnaissance de la commande, seul le texte reconnu est envoyé au service d’IA, avec consentement (art. 6 al. 6 nLPD).

Modules optionnels : Gestion de la qualité (QMS), Voice-to-Schedule, Préparation des salaires & finances, Smart Matchmaker, Radar de charge, Réseau régional. Activation par mandant via Administration → Outils.

• Touche Échap globale et piège de focus .
• Barre de progression ARIA .
• Quatre langues d’interface : DE / FR / IT / EN.
• 14 langues de chat pour la communication interne — la traduction s’effectue sur l’appareil.

• Les secrets se trouvent dans /etc/rosie/env sur l’instance, lisibles uniquement par le compte de service : clé de signature des sessions, paire de clés VAPID, identifiants pour le stockage d’objets, le SMTP et le service d’IA.
• Renouveler la clé de signature chaque année.
• La rotation des clés VAPID invalide les abonnements aux notifications (limitation connue).
• Hachage des mots de passe : PBKDF2-SHA-256 avec sel, en quatre passes chaînées de 100 000 itérations chacune (400 000 au total).

La création d’un mandant se fait chez le fournisseur, sur l’instance suisse. Aucune installation n’est nécessaire chez le client — pas de serveur, pas d’agent, pas de port entrant. Ce qui suit est la liste des points qui incombent réellement au client.

Des procédures existent pour : erreurs de connexion · erreurs de base de données · erreurs de mise en production · remise des courriels · panne de l’IA · remise des notifications · erreurs de migration.

• TLS 1.3.
• AES-256 au repos. Les champs de texte libre particulièrement sensibles sont en outre chiffrés individuellement.
• Hébergement des données en Suisse (Infomaniak) : puissance de calcul, base de données, stockage d’objets et sauvegardes. Le service de protection placé devant le site public et le prestataire de paiement sont nommés dans la liste des sous-traitants ultérieurs du contrat de sous-traitance.
• Contrat de sous-traitance disponible.
• Aucun cookie, aucun pistage — le signal « Do Not Track » est respecté.
• Destruction des clés comme révocation opérationnelle ; effacement dans les 30 jours suivant la fin du contrat, avec attestation écrite.
• Le SSO (SAML/OIDC) est indisponible et en cours d’évaluation ; aucune date ferme n’est fixée. Connexion par courriel et mot de passe, avec TOTP en option.