Confiance et sécurité

La sécurité chez WeDisplay

Dernière révision : 30 juillet 2026. Cette page décrit le service tel qu'il est déployé aujourd'hui.

Cette page expose concrètement qui exploite WeDisplay, où le service fonctionne et ce qui protège les données que vous y déposez. Elle est écrite pour la personne qui doit approuver un nouveau fournisseur — elle indique donc aussi clairement ce que nous n'avons pas.

Tout ce qui suit est une description factuelle du système en exploitation, et non un engagement contractuel. Les engagements exécutoires se trouvent dans nos Conditions d'utilisation, notre Politique de confidentialité et notre Addenda de traitement des données.

1. Qui exploite WeDisplay

WeDisplay est exploité par EN6IA, une société immatriculée au Québec, Canada, sous le numéro d'entreprise du Québec (NEQ) 2266497173, faisant affaire sous le nom de WeDisplay. Il s'agit de l'entité juridique nommée dans nos Conditions d'utilisation, notre Politique de confidentialité et notre Addenda de traitement des données, et de la partie avec laquelle vous contractez. La dénomination et le NEQ figurent dans ces trois documents : vous pouvez donc les vérifier vous-même, et ils sont réunis, avec toutes nos autres politiques, dans le Centre juridique.

2. Les données en transit

• HTTPS partout. Le site vitrine, le tableau de bord, les API et le lecteur fonctionnent tous en TLS. Le HTTP en clair est redirigé de façon permanente vers HTTPS.
• HSTS. Les réponses de production portent l'en-tête Strict-Transport-Security: max-age=31536000; includeSubDomains : un navigateur qui a visité le site une seule fois refuse pendant un an de s'y connecter sans chiffrement, sur chaque sous-domaine.
• En-têtes de réponse renforcés. Chaque réponse définit également X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff et Referrer-Policy: strict-origin-when-cross-origin, ainsi qu'une Permissions-Policy qui désactive la géolocalisation, l'USB, le port série, le Bluetooth et le MIDI.
• Le lecteur Android refuse le trafic en clair. Notre application pour téléviseurs Android est livrée avec usesCleartextTraffic=false : le système d'exploitation lui-même bloque toute connexion non chiffrée que l'application pourrait tenter, même mal configurée.
• Diffusion en direct. Le partage d'écran et les sources en direct utilisent WebRTC, que le protocole chiffre en transit. Le relais utilisé lorsqu'une liaison directe est impossible est notre propre serveur plutôt qu'un service tiers, et ses identifiants sont à durée limitée et émis à la demande plutôt que codés en dur dans le lecteur.

3. Cloisonnement des organisations et contrôle d'accès

• Chaque requête est limitée à une organisation. Les routes de l'API résolvent l'organisation de l'appelant côté serveur et y restreignent la requête : les écrans, médias, listes de lecture et rapports d'un client ne sont donc pas accessibles depuis la session d'un autre client, quels que soient les identifiants envoyés par le client.
• 24 autorisations granulaires réparties en 10 catégories. L'accès au sein d'une organisation est régi par des autorisations attribuables individuellement, regroupées en écrans, médias, listes de lecture, mises en page, sources, équipe, paramètres, conférence, rapports et assistant IA — et non par quelques rôles grossiers. Un membre de l'équipe obtient exactement ce que son groupe de sécurité lui accorde, et les routes d'administration de la plateforme font l'objet d'une vérification distincte supplémentaire.
• Le plan temps réel est authentifié lui aussi. La connexion WebSocket qui pousse le contenu vers les écrans décode le témoin de session signé pendant la poignée de main et rattache la connexion à un salon limité à l'organisation. Chaque message de commande et de signalisation est ensuite autorisé pour l'écran ou la source précise qu'il vise, à partir de l'identité enregistrée à la connexion et non d'un identifiant contenu dans le message.
• Journal d'audit. Les actions sensibles liées au compte et à l'administration sont consignées dans un journal d'audit propre à chaque organisation.

4. Authentification

• Sessions. L'authentification repose sur Auth.js v5 avec des témoins de session JWT signés qui expirent après 7 jours. Ces témoins sont HttpOnly, Secure et SameSite=Lax, et utilisent les préfixes de témoin __Secure- et __Host- en HTTPS.
• Mots de passe. Les mots de passe sont hachés avec bcrypt à un facteur de coût de 12 et ne sont jamais stockés ni journalisés en clair. Les échecs de connexion répétés sur un même compte sont limités.
• Authentification unique, sur demande. WeDisplay offre OIDC (Microsoft Entra ID et Google Workspace), SAML 2.0 avec des connexions par domaine rattachées à un domaine que vous avez vérifié, et l'approvisionnement des utilisateurs et des groupes en SCIM 2.0, afin que les arrivées et les départs soient pilotés par votre fournisseur d'identité. Les trois sont développés et livrés, et sont activés client par client plutôt qu'actifs par défaut.
• La production refuse de démarrer avec un secret faible. Le serveur vérifie au démarrage son secret de signature de session et s'interrompt s'il est absent, s'il correspond à une valeur par défaut connue ou s'il fait moins de 32 caractères. Une clé de signature falsifiable est la seule défaillance qui annulerait tout le reste de cette page : elle est donc imposée par le processus, pas par une liste de vérification.

5. Sauvegardes et rétablissement

• Toutes les six heures, hors de l'instance. Un conteneur auxiliaire dédié exporte la base de données PostgreSQL de production toutes les six heures et téléverse le fichier vers le stockage d'objets Cloudflare R2 — délibérément un fournisseur différent de celui qui héberge l'application, afin qu'une mauvaise journée chez un fournisseur ne puisse pas emporter à la fois le système et ses sauvegardes.
• Rétention par paliers. Les exports aux six heures sont conservés 2 jours, les exports quotidiens 30 jours et les exports hebdomadaires 90 jours; tout ce qui est plus ancien est élagué automatiquement.
• Les médias autant que les enregistrements. Les fichiers médias téléversés sont synchronisés vers le même stockage hors site : les fichiers survivent donc à la perte de l'instance, et pas seulement les enregistrements de base de données qui les décrivent.
• Sous surveillance. Chaque cycle de sauvegarde terminé envoie un signal à un moniteur externe : une sauvegarde qui échoue silencieusement déclenche une alerte au lieu d'être découverte au moment d'une restauration.
• La restauration a réellement été exécutée. Le 30 juillet 2026, nous avons récupéré la sauvegarde la plus récente depuis le stockage hors site, l'avons rejouée dans une base de données temporaire, puis comparée à la production en service : 54 tables, 68 migrations de schéma et 88 contraintes de clés étrangères présentes, et un nombre d'enregistrements identique des deux côtés pour les utilisateurs, les organisations, les écrans, les médias, les listes de lecture et les journaux de diffusion. La base temporaire a ensuite été supprimée et la production est restée saine du début à la fin. Une sauvegarde non testée n'est qu'une hypothèse; celle-ci a été testée.

Ce que cela ne signifie pas. Il ne s'agit ni d'une garantie de délai de rétablissement ni d'une garantie de perte de données maximale, et nous n'offrons pas aujourd'hui de garantie contractuelle de disponibilité. WeDisplay fonctionne actuellement sur une seule instance dans une seule région : perdre cet hôte signifierait reconstruire à partir d'un export pouvant remonter à six heures, avec une interruption pendant l'opération. Un hébergement de base de données répliqué avec récupération à un instant précis figure à notre feuille de route et n'est pas encore en place. La disponibilité actuelle est publiée sur notre page d'état.

6. Renforcement de l'application

• Limitation de débit. L'inscription de compte, la réinitialisation et le changement de mot de passe, le jumelage des appareils et des sources, l'interrogation de contenu par le lecteur, l'accès aux conférences, la vérification des invitations, l'envoi de demandes commerciales ainsi que les points d'accès publics de codes QR et de données de widgets sont tous soumis à une limitation de débit.
• Les téléversements sont vérifiés par leur contenu, pas par leur nom. Chaque téléversement est validé par rapport à une liste d'extensions et de types MIME autorisés et par rapport à sa signature de fichier réelle (magic bytes) : un exécutable renommé en .png est rejeté. Les documents bureautiques doivent porter un véritable manifeste OOXML, et pas seulement un en-tête ZIP.
• Les médias ne sont servis que pour des fichiers enregistrés. Le point d'accès aux médias recherche le chemin demandé comme un enregistrement média présent en base de données avant de lire quoi que ce soit sur le disque, et rejette d'emblée les segments de traversée de répertoires. Aucune route ne sert un chemin arbitraire du système de fichiers.
• Protection contre le SSRF sur les appels sortants. Lorsque la plateforme récupère une URL en votre nom — widgets de données, intégrations, rappels HTTP — le nom d'hôte est d'abord résolu, puis rejeté si l'une des adresses obtenues est de bouclage, privée, de lien local, de NAT de classe opérateur (CGNAT) ou multidiffusion. La connexion est ensuite épinglée aux adresses exactes qui ont été validées, de sorte qu'une réattribution DNS (« DNS rebinding ») ne puisse pas la rediriger vers un hôte interne en cours de requête; les redirections ne sont jamais suivies et le corps de la réponse est plafonné au fil de sa réception.
• Secrets chiffrés au repos. Les identifiants que la plateforme conserve en votre nom — jetons de calendrier connecté, clés API de fournisseurs, clés de facturation — sont chiffrés en AES-256-GCM avant d'être écrits en base de données.
• Dépendances. Nous surveillons les avis de sécurité visant nos dépendances et corrigeons ce qui est atteignable à l'exécution dans le cadre de l'entretien courant; la plus récente revue complète de sécurité et de dépendances a été livrée en juillet 2026.

7. Où résident vos données

L'application WeDisplay et sa base de données PostgreSQL fonctionnent sur une infrastructure exploitée par OVH au Canada. Notre relais WebRTC fonctionne sur la même infrastructure : le trafic de relais de diffusion en direct n'est donc jamais confié à un fournisseur de diffusion tiers. Cloudflare se place devant l'application comme réseau de diffusion de contenu et pare-feu applicatif, et conserve également les sauvegardes hors site décrites plus haut.

Certains sous-traitants auxquels nous faisons appel pour des fonctions précises — paiements, courriels transactionnels, fournisseurs d'identité, assistant IA optionnel — traitent des données sur des serveurs situés hors du Québec, notamment aux États-Unis et dans l'Union européenne. Chacun est nommé individuellement à la section 5 de notre Politique de confidentialité, et avant de nous appuyer sur un tel transfert, nous évaluons si le destinataire offre une protection équivalente à ce qu'exige le droit québécois. Si vous avez besoin d'une entente particulière de résidence des données, soulevez-la avec nous avant de signer plutôt qu'après.

8. Vie privée, et ce qui s'affiche sur vos écrans

• Loi 25 du Québec et LPRPDE. Notre programme de protection de la vie privée est rédigé pour se conformer à la loi québécoise sur la protection des renseignements personnels dans le secteur privé (Loi 25) et à la LPRPDE canadienne, et nous respectons les droits prévus par le RGPD, le RGPD britannique et la CCPA/CPRA lorsqu'ils s'appliquent. Nous avons un responsable de la protection des renseignements personnels désigné, un registre interne des incidents de confidentialité et un processus de notification des atteintes qui inclut la Commission d'accès à l'information du Québec lorsque la loi l'exige.
• Nous ne vendons ni ne partageons de renseignements personnels au sens de la CCPA/CPRA, et nous ne communiquons pas de renseignements personnels à des tiers pour leurs propres fins de marketing.
• Aucun traceur tiers. Tous les témoins déposés par WeDisplay sont de première partie et fonctionnels : votre session d'authentification, les témoins techniques qui la protègent (un jeton CSRF et une URL de retour Auth.js, que notre couche d'authentification dépose à toute visite, que vous soyez connecté ou non), vos choix de consentement aux témoins, vos préférences de langue et d'interface, la devise d'affichage que vous sélectionnez sur notre page de tarification si vous la modifiez (une préférence d'affichage seulement — chaque forfait est facturé en dollars américains) et — uniquement si vous accordez le consentement fonctionnel — un code de référence. Il n'y a aucune suite d'analytique, aucun pixel publicitaire ni aucun script de suivi tiers dans le produit. Notre Politique relative aux témoins explique leur rôle et comment modifier vos choix.
• Aucune régie publicitaire sur vos écrans. Le lecteur n'intègre aucune régie publicitaire ni aucune trousse de mesure d'audience. Les écrans du forfait gratuit portent un filigrane WeDisplay et diffusent occasionnellement des messages promotionnels de WeDisplay — notre propre contenu, diffusé par nous, sans aucun tiers et sans collecte de données sur les spectateurs — et les forfaits payants peuvent être configurés sans publicité. Le contenu que vous choisissez d'afficher vous appartient évidemment : une page Web ou un widget que vous intégrez exécute ce que son propre éditeur y a mis.

9. Ce que nous n'avons pas encore

Une page de confiance n'est utile que si elle énumère aussi ce qui manque; le voici, sans détour.

• Aucun rapport SOC 2 ni certificat ISO 27001. WeDisplay ne détient aujourd'hui aucune certification ni attestation de sécurité délivrée par un tiers — ni SOC 2, ni ISO 27001, ni PCI DSS, ni attestation HIPAA. Notre Addenda de traitement des données le dit dans les mêmes termes. Si une certification est une exigence stricte pour votre organisation, nous ne sommes pas encore le bon choix, et nous préférons que vous l'appreniez ici plutôt que trois mois après le début d'un processus d'approvisionnement.
• Aucun test d'intrusion tiers publié. Nous menons des audits de sécurité internes et corrigeons ce qu'ils révèlent, mais nous n'avons pas commandé de test d'intrusion externe dont nous pourrions vous remettre le rapport.
• Aucune garantie contractuelle de disponibilité. Le service est fourni tel quel selon nos Conditions d'utilisation. La disponibilité en temps réel est publiée sur notre page d'état.
• Une seule région, une seule instance. Comme l'indique la section 5, les sauvegardes sont hors site et leur restauration a été testée, mais l'application elle-même ne dispose aujourd'hui d'aucune bascule automatique.

Nous préférons publier cette liste plutôt que d'être pris en défaut sur celle-ci. Si l'un de ces éléments constitue un obstacle pour vous, dites-le-nous : cela nous aide à ordonner nos travaux.

10. Signaler un problème ou nous poser une question

Si vous avez trouvé une faille de sécurité dans WeDisplay, écrivez à [email protected] en donnant assez de détails pour que nous puissions la reproduire. Nous accuserons réception et vous tiendrons informé pendant notre enquête, et nous n'engagerons aucune poursuite contre quiconque signale de bonne foi une faille réelle sans consulter, modifier ni détruire les données d'autrui au passage.

Pour une revue de sécurité fournisseur ou un questionnaire de sécurité, écrivez à la même adresse en précisant ce dont vous avez besoin — nous préférons répondre honnêtement, y compris lorsque la réponse est non, plutôt que de laisser une case vide. Les demandes relatives à la vie privée s'adressent à notre responsable de la protection des renseignements personnels, à [email protected], et un Addenda de traitement des données contresigné peut être demandé à [email protected].

Une question sur le contenu de cette page? Écrivez à [email protected]. Toutes nos politiques sont réunies dans le Centre juridique.