Ce que nous faisons, et ce que nous n’avons pas encore.

État au 30 octobre 2026

Où sont vos données

Le service, sa base de données et ce site sont hébergés par ServaRICA (Rica Web Services), à Montréal, sur un seul serveur. Plus rien n’est hébergé en France. Les exceptions — les quelques services tiers par lesquels passe une partie de l’information — sont nommées une à une dans la politique de confidentialité ; cette page ne les remplace pas.

Le service n’est joignable que par un tunnel sortant de Cloudflare : aucun port web n’est ouvert sur le serveur. Seul l’accès d’administration (SSH) l’est, par clé seulement, avec une protection contre les essais répétés (fail2ban) ; les mises à jour de sécurité du système s’installent automatiquement. Cloudflare termine le chiffrement (TLS) avant de relayer le trafic vers le serveur ; la politique de confidentialité décrit ce qu’il voit au passage.

Les en-têtes de sécurité

Le site public (remanso.ca) envoie sur chaque réponse : une politique de contenu (Content-Security-Policy) qui n’admet que des ressources venant de remanso.ca, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (géolocalisation, micro et caméra fermés), Cross-Origin-Opener-Policy: same-origin et Strict-Transport-Security d’un an, sous-domaines compris.

Le service (app.remanso.ca) envoie une politique de contenu sans aucune origine tierce, frame-ancestors 'none' (aucun autre site ne peut l’afficher dans un cadre), object-src 'none', nosniff, X-Frame-Options, Referrer-Policy, Strict-Transport-Security d’un an sous HTTPS, et Cache-Control: no-store sur ses pages, pour qu’un bouton « Retour » sur un poste partagé ne rejoue pas un écran fermé. Toute écriture venue d’un autre site est refusée (403).

Ce que ces en-têtes ne font pas. Les scripts et les styles en ligne sont admis ('unsafe-inline') : le service n’a pas encore de jeton par requête, ce qui affaiblit la protection contre l’injection de script. Et une seule page peut être cadrée par d’autres sites : le lecteur d’un écran d’affichage, par décision. Vous pouvez tout vérifier vous-même dans les outils de développement d’un navigateur, onglet « Réseau ».

Comptes et accès

• Le mot de passe compte au moins douze caractères ; il est conservé haché, jamais en clair.
• L’adresse courriel est confirmée avant l’usage du compte.
• Une session expire après sept jours sans activité. Réinitialiser son mot de passe ferme toutes les autres sessions de la personne.
• La connexion par Google ou Microsoft est possible, en plus du mot de passe.
• Dans votre organisation, c’est vous qui décidez qui voit quoi, par rôle et par périmètre. De notre côté, l’accès technique est limité aux personnes qui en ont besoin pour faire fonctionner le service.

La séparation entre organisations

Chaque ligne de la base de données appartient à une organisation, et la base elle-même refuse qu’une ligne se rattache à celle d’une autre — pas seulement le code du service. Ce que chaque personne peut ensuite lire est fixé par le code, qui filtre chaque lecture par l’organisation de la personne connectée. Nous ne prétendons pas qu’une erreur de code soit impossible. C’est pourquoi, à chaque déploiement du service, un balayage automatisé crée deux organisations jetables et vérifie qu’une adresse bricolée n’affiche rien de l’organisation voisine. Ce balayage peut être omis explicitement pour un déploiement d’urgence ; ce n’est pas la règle.

Sauvegardes et reprise

Une sauvegarde par jour, la nuit, conservée trente jours au Québec. Chacune est vérifiée par une restauration réelle : si elle ne se relit pas, elle est signalée en échec, mise à part et jamais utilisée. Chaque jour, une copie vérifiée est tirée sur une seconde machine, aussi au Québec, qui n’est pas chez l’hébergeur. Cela protège de la perte du serveur ou d’une suppression, pas d’un sinistre qui toucherait les deux endroits à la fois.

Comme la sauvegarde est quotidienne, une reprise après sinistre peut perdre jusqu’à une journée de saisie ; ce n’est pas un engagement chiffré. Nous ne publions ni objectif de temps de reprise ni perte de données maximale acceptée : nous n’en avons pas mesuré sur l’installation actuelle.

Si un incident survient

Notre engagement écrit est celui de la politique de confidentialité : en cas d’incident touchant vos renseignements et présentant un risque de préjudice sérieux, nous vous avisons, ainsi que la Commission d’accès à l’information, comme la loi l’exige, en vous disant ce qui est arrivé, ce qui est touché et ce que nous faisons. Nous ne publions pas de procédure interne détaillée : elle n’est pas encore écrite.

Signaler une vulnérabilité

Écrivez à confidentialite@remanso.ca, avec une description et les étapes pour reproduire. Les mêmes coordonnées sont dans security.txt. Merci de ne pas accéder aux données d’autres personnes au-delà de ce qu’il faut pour montrer le problème, de ne pas tester par surcharge, et de nous laisser le temps de corriger avant d’en parler. Un message envoyé à cette adresse est un courriel comme un autre : les conditions promettent la réponse d’une personne dans les deux jours ouvrables ; pour un signalement de sécurité, nous en accusons réception en un jour ouvrable. Nous ne promettons pas de délai de correction.

Ce que nous n’avons pas encore

Un acheteur public a le droit de le lire avant de signer, pas après.

• Aucune certification : ni SOC 2, ni ISO/IEC 27001.
• Aucun test d’intrusion par un tiers indépendant. Nos vérifications sont les nôtres : des épreuves automatisées et des revues internes.
• L’authentification à deux facteurs est disponible, mais facultative. Chaque personne peut l’activer pour son compte (un code à usage unique généré sur son appareil, dix codes de secours, un verrou après cinq essais ratés). Elle n’est exigée de personne par défaut : l’administrateur de chaque organisation choisit de l’exiger ou non — de ses administrateurs seulement, ou, s’il le préfère, de tous ses membres (depuis le 2 novembre 2026) — et peut revenir sur son choix. La personne visée est avisée par courriel quand sa deuxième vérification est activée, retirée ou réinitialisée, ou quand son organisation l’exige d’elle (le courriel ne contient ni code ni lien). Si elle perd son appareil et ses codes de secours : un administrateur de son organisation peut la réinitialiser ; en dernier recours, l’équipe de Remanso le fait après avoir vérifié son identité par un autre moyen que la plateforme. Les clés d’accès (WebAuthn) ne sont pas offertes.
• La connexion unique (SSO/SAML/SCIM) avec le fournisseur d’identité de votre organisation n’est pas en service à ce jour. Le fonctionnement prévu : elle sera activée organisation par organisation, sur demande, par l’exploitant. SAML et SCIM ne sont pas offerts.
• Le journal des consultations n’est pas en service à ce jour. Un journal d’activité des changements existe pour l’administration ; il ne dit pas qui a simplement ouvert une fiche.
• Aucun objectif de reprise publié (RTO/RPO), aucune page d’état, et aucun taux de disponibilité promis : les conditions le disent.
• Un seul serveur, sans bascule automatique, et une seule personne qui exploite Remanso : aucun second administrateur n’est désigné à ce jour, et aucune procédure de remplacement n’existe encore.

Nous mettrons cette page à jour quand l’un de ces points change — dans un sens ou dans l’autre.