Matrix est un standard, pas un produit. Tout ce qui l'entoure demande du travail, et c'est ce travail que nous faisons.

00

Ce qu'est Matrix et les trois façons d'en disposer.

Une adresse Matrix fonctionne comme une adresse électronique. Tout ce qui suit dépend du choix de la personne qui détient la machine.

Matrix est un standard ouvert de communication en temps réel. Un compte réside sur un serveur, son adresse ressemble à @you:example.com, et les personnes sur des serveurs différents se joignent comme par courrier électronique. Personne n'a besoin de partager la même plateforme et aucune entreprise n'est au centre du réseau.

Il reste donc une décision essentielle : qui détient le serveur ? Tout le reste, du client aux passerelles vers d'autres réseaux en passant par l'identité, peut changer ensuite sans modifier les adresses.

Il existe trois façons de disposer d'un serveur d'accueil. Elles diffèrent par la propriété de la machine et la personne réveillée en cas de panne, pas par les capacités du logiciel.

Si vous découvrez le sujet

• Ce qu'est un serveur d'accueil et ce qu'il n'est pas
• Pourquoi l'adresse porte votre domaine et ce que cela vaut
• La fédération en termes simples : ouverte, limitée à des partenaires nommés ou fermée
• Le chiffrement de bout en bout et ce que le serveur voit encore
• Ce que les passerelles vers d'autres réseaux peuvent ou non transporter
• Le coût d'exploitation, en machines et en attention
• Ce qui change pour les personnes qui doivent l'utiliser chaque jour
• À quoi ressemble un premier mois réaliste

Les trois façons d'en disposer et leurs suites

• Après commande : nous convenons du domaine, vous payez la facture d'installation et la construction commence
• Un serveur opérationnel, sécurisé et sauvegardé, selon le calendrier convenu dans le périmètre écrit des travaux
• Puis un groupe pilote, puis tout le monde, puis la transmission : aucun basculement en un seul saut
• Sur notre infrastructure : dédiée, dans l'UE, mise à jour et surveillée
• Sur votre matériel ou compte cloud : installé, sécurisé et maintenu par nous
• Entièrement chez vous : conception, construction et transmission, puis vous l'exploitez
• Chaque formule peut devenir une autre ensuite ; l'adresse et les données suivent
• Aucun hébergement partagé, aucune licence par utilisateur, aucune dépendance à une application cliente
• La sortie est conçue au départ, pas improvisée à la fin

Non inclus : des comptes sur un serveur public ouvert à toute inscription. Chaque déploiement ici appartient à une seule organisation.

01

Déploiement, exploitation et passage à l'échelle.

Un serveur d'accueil qui démarre proprement, grandit délibérément et reste reconstructible.

Matrix est un protocole, pas un paquet. Un déploiement enchaîne les décisions : implémentation du serveur, base de données, stockage des médias et délégation du domaine.

Nous travaillons avec les implémentations de serveur de l'écosystème et les installations pilotées par gestion de configuration, conteneurs ou opérateur Kubernetes. La configuration reste versionnée pour reconstruire le déploiement plutôt que s'en souvenir.

La croissance est une discipline distincte de l'installation. Répartir les fonctions, maîtriser l'état des salles et tester sous un trafic réaliste se fait avant l'arrivée de la charge, pas après.

Installer et configurer

• Examen de l'implémentation : Synapse pour presque tout, des versions plus légères lorsque la charge le justifie réellement
• Sur votre matériel, les prérequis sont clairs : une machine x86-64, Debian ou Ubuntu à jour, un accès sortant sans restriction et un domaine que vous contrôlez, ou un sous-domaine gratuit fourni par nous
• Une installation neuve avec terminaison TLS, proxy inverse et paramètres par défaut sécurisés
• Le nom du serveur et sa délégation par fichiers well-known et enregistrements de service
• Une gestion de configuration pour un déploiement entièrement versionné et examinable
• Un déploiement sur une plateforme de conteneurs par charts ou opérateur
• La mise en place et l'optimisation de la base de données, avec des pools de connexions
• Un dépôt de médias sur disque local ou stockage objet
• Une passerelle de notifications, éventuellement dédiée à une application mobile à votre marque
• Des règles d'inscription : sur invitation, jetons, approbation, captcha
• Installation isolée et hors ligne pour réseaux sans accès sortant
• Des topologies à plusieurs domaines et locataires
• Une préproduction proche de la production pour répéter les mises à niveau avant leur arrivée

Adapter l'échelle

• Une architecture de processus de travail avec routage des requêtes par fonction
• La séparation des processus d'écriture des flux et de persistance des événements pour les parcs à forte écriture
• La réplication et la coordination des caches entre processus
• Des règles de répartition de charge respectant le routage du serveur d'accueil
• La maîtrise de la croissance de l'état des salles et sa compression
• Le transfert des médias vers un stockage objet et une couche de diffusion
• Le dimensionnement des émetteurs de fédération et la gestion des files sortantes
• Des règles de dimensionnement automatique sur les plateformes de conteneurs
• Des tests de charge sur un trafic réaliste plutôt que des meilleurs cas artificiels
• Une analyse de l'implantation multirégionale et en périphérie
• Un travail de performance pour les grandes salles et les grands espaces
• Un changement d'implémentation de serveur lorsque la charge le justifie

Non inclus : une astreinte. Les délais de réponse sont indiqués dans les niveaux d'assistance à /matrix/G. L'infrastructure reste la vôtre ou celle de votre fournisseur.

02

Migration, déplacement et portabilité.

Entrer sans perdre le fil. Partir sans payer la sortie.

La plupart des projets Matrix commencent ailleurs : une plateforme d'équipe hébergée, un serveur de discussion jamais mis à jour, un serveur public qui n'était qu'un essai.

La migration se fait par étapes. Une passerelle maintient les deux systèmes actifs pendant le déplacement des personnes, pour une transition progressive plutôt qu'un basculement brutal.

La portabilité fonctionne de la même façon en sens inverse. La propriété tient ici aux niveaux de pouvoir, pas à une licence ; la sortie est conçue dès le départ.

Arrivée

• Une migration depuis des plateformes d'équipe hébergées, des serveurs communautaires, IRC ou XMPP
• L'import de l'historique avec conservation des auteurs, horodatages et pièces jointes
• La correspondance entre votre annuaire existant et les identifiants Matrix
• Une migration de base de données d'un stockage embarqué vers un moteur de production
• Une migration du stockage des médias vers un stockage objet ou une couche de diffusion
• Le passage d'une connexion par mot de passe intégrée à un service d'authentification dédié
• Un basculement progressif avec les deux systèmes reliés et actifs en parallèle
• Un plan de retour arrière et de secours pour chaque étape

Migrer, partir, reproduire

• Le déplacement du serveur d'accueil vers un nouveau matériel, une région ou un fournisseur
• Une stratégie de changement du nom de serveur et de délégation
• Le changement d'implémentation lorsque le modèle d'exploitation change
• La mise à niveau des versions de salles dans tout le parc
• L'export, l'archivage et la fermeture de la plateforme quittée
• La construction d'une distribution interne pour que les équipes déploient des serveurs conformes
• Une architecture de référence et une configuration type validée pour les déploiements répétés
• La création et la suppression de locataires lorsque vous hébergez pour d'autres
• Des ensembles d'artefacts hors ligne et des miroirs privés pour les réseaux restreints

Schéma

Huit décisions façonnent un déploiement Matrix pour un établissement. Chacune est prise délibérément, plutôt qu'héritée d'une valeur par défaut.

00 Le dossier

• Périmètre : déploiement, sécurisation, authentification unique, règles de fédération, modération, appels et documents demandés à un établissement. Chaque réglage ci-dessous est une décision, et chaque décision est consignée.
• Ce qui est documenté : documentation, schémas et décisions d'architecture, ainsi qu'un dossier complet de protection des données : analyse d'impact, registre des traitements, politique de suppression et procédure de violation de données.
• Exploitation : revue de configuration, planification de reprise et tests de restauration de base de données dans un environnement isolé.
• Sujets abordés : souveraineté et vie privée, auto-hébergement, conteneurisation, protection et conservation des données, authentification unique, marque, bots et widgets, intégration de l'assistance, fédération sélective, modération et conformité, exploitation et observabilité, adoption et recommandations.
• Vos cases cochées accompagnent ce message.

01 Hébergement

Où se trouve réellement le serveur d'accueil ?

• A. Cloud géré
• + En fonctionnement dès l'inscription, sans personne à recruter
• + La bonne réponse pour une petite équipe sans personne pour exploiter un serveur
• - La conservation, les limites et la localisation des données du fournisseur deviennent les vôtres
• - Les mises à niveau arrivent selon son calendrier, pas le vôtre
• B. Serveur dédié
• + La base de données, les médias et les journaux résident sur un matériel identifiable
• + Vous fixez la conservation, les limites d'envoi et la sécurisation
• - Quelqu'un doit appliquer les correctifs, surveiller et en répondre
• - Une mauvaise configuration est votre panne, pas une page de statut

Serveur d'accueil, client, fournisseur d'identité, base de données et proxy inverse, conteneurisés sur du matériel contrôlé par l'établissement.

02 Fédération

Qui est autorisé à accéder à vos salles ?

• A. Fédération ouverte
• + Tout le réseau Matrix dès le premier jour
• + La bonne réponse pour un groupe de recherche dont les partenaires sont déjà ailleurs
• - Votre périmètre de modération couvre tout le réseau avant que votre politique existe
• - Ce qui a été fédéré vers l'extérieur ne peut être rappelé
• B. Fédération par liste d'autorisation
• + Le port de fédération reste fermé jusqu'à votre décision contraire
• + Les serveurs partenaires sont admis nominativement, un par un
• - Tout ce qui est hors liste est inaccessible, y compris des services souhaités
• - Chaque nouveau partenaire exige une décision de quelqu'un

Un déploiement peut commencer fermé : port de fédération fermé, liste explicite de serveurs autorisés et modération en place avant l'admission du premier serveur externe.

03 Identité

Comment une personne se connecte-t-elle ?

• A. Comptes locaux
• + La connexion fonctionne même si rien d'autre ne tourne
• + La bonne réponse pour un pilote de vingt personnes sans annuaire à contacter
• - Les inscriptions, réinitialisations de mots de passe et départs alimentent la file d'assistance
• - Une personne partie garde un compte actif jusqu'à ce que quelqu'un s'en souvienne
• B. Authentification unique
• + Une identité institutionnelle avec un cycle de vie du compte déjà géré ailleurs
• + Un filtre sur le domaine de messagerie détermine qui peut s'inscrire
• - Le fournisseur d'identité devient un deuxième système à exploiter
• - Une seule mauvaise configuration empêche toute connexion

Intégration du fournisseur d'identité, séparation des domaines d'authentification, filtrage par domaine de messagerie et configuration de base de données.

04 Chiffrement

Quelles salles sont chiffrées de bout en bout ?

• A. Tous les salons
• + L'opérateur du serveur ne peut rien lire, nous non plus
• + La bonne réponse lorsque le modèle de menace inclut l'hébergeur
• - La recherche, les bots, widgets et contrôles de conformité perdent leur visibilité
• - Les passerelles et le chiffrement de bout en bout ne se combinent pas simplement
• B. Différencié selon la salle
• + Chiffrement là où le contenu le justifie, salles en clair ailleurs
• + La recherche, les bots et l'archivage restent actifs là où ils sont nécessaires
• - Quelqu'un doit rédiger et défendre la règle
• - Une mauvaise classification est une erreur silencieuse, pas visible

Nous convenons du chiffrement salon par salon et documentons ses effets sur les passerelles, la modération, la recherche et l'archivage.

05 Conservation

Combien de temps les éléments restent-ils ?

• A. Tout conserver
• + Rien n'est jamais perdu et personne ne doit décider quoi que ce soit
• + La bonne réponse lorsqu'une loi sur les archives impose une conservation indéfinie
• - C'est la valeur par défaut dans la plupart des déploiements, choisie par personne
• - Chaque message jamais supprimé reste un message dont vous devez répondre
• B. Politique de conservation côté serveur
• + Les messages et médias envoyés localement expirent selon un calendrier défini
• + Les médias des autres serveurs sont mis en cache, pas archivés
• - Expiré signifie expiré : aucun retour en arrière
• - Le calendrier doit être convenu avant d'être configuré

Une durée pour les messages et médias envoyés localement, une plus courte pour ceux des autres serveurs. Les deux sont configurées et documentées.

06 Modération

Que se passe-t-il en cas de problème dans une salle ?

• A. Manuellement
• + Aucun mécanisme supplémentaire ; un administrateur lit le signalement et agit
• + La bonne réponse pour une salle de quinze collègues
• - Le délai de réaction dépend de la personne qui se trouve éveillée
• - Ce qui est appris dans une salle ne protège pas la suivante
• B. Imposée par politique
• + Une salle de politique applique ses bannissements à toutes les salles protégées
• + Les nouvelles salles héritent de la protection au lieu d'être configurées
• - Une mauvaise politique se propage aussi vite qu'une bonne
• - Quelqu'un doit toujours être responsable de la liste

Un bot de modération applique la politique dans tout le parc, à côté d'un environnement d'exécution de plugins chargé des tâches quotidiennes.

07 Réunions

Où se déroule l'appel ?

• A. Un lien externe
• + Ce que l'établissement a déjà licencié et approuvé
• + La bonne réponse lorsque le cycle d'achat s'est clos l'an dernier
• - Un deuxième produit, une deuxième connexion, une deuxième revue de confidentialité
• - Le chat est à un endroit, l'appel à un autre et les notes à un troisième
• B. Dans la salle
• + L'appel commence là où les bonnes personnes sont déjà présentes
• + Les widgets gardent la réunion à côté de la conversation
• - Davantage à exploiter : serveurs de médias, TURN, signalisation
• - La prise en charge des appels dans les salles reste inégale selon les clients

OpenTalk, Jitsi avec Prosody, Jicofo, JVB et coturn, ainsi que LiveKit pour Matrix-RTC, présentés sous forme de widgets dans les salles.

08 Accès d'administration

Qui peut accéder au plan de contrôle ?

• A. Points d'accès publics
• + Accessible depuis tout appareil, sans tunnel à distribuer
• + Un système de moins à exploiter pour une petite équipe
• - Quiconque devine le nom d'hôte atteint votre page de connexion
• - L'API d'administration est une cible de grande valeur sur un port très public
• B. Limité par le réseau
• + Les interfaces d'administration répondent à une adresse source, pas à un nom
• + Aucune page de connexion à attaquer, puisqu'aucun chemin ne permet de l'atteindre
• - Un tunnel fonctionnel est nécessaire avant toute réparation
• - Si vous vous bloquez, la récupération exige une session sur la console

Les interfaces d'administration sont derrière WireGuard, adressées par IP source plutôt que DNS. Les médias authentifiés, les notifications sans contenu de message, les limites d'envoi, la suppression automatique des appareils obsolètes et la durée limitée des jetons de renouvellement sont explicitement configurés.

09 Envoyer le parcours

Indiquez votre colonne et ce que vous cherchez à exploiter. Vos huit choix accompagnent ce message.

• Salles, personnes, échéance. Tout ce que vous savez déjà.
• Aucun suivi ni requête tierce sur cette page. Rien n'est transmis ici : votre parcours et votre message sont inscrits dans un brouillon de votre logiciel de messagerie et ne partent que lorsque vous les envoyez.

Non inclus : des garanties sur ce qu'un autre fournisseur vous remettra. La qualité de son export dépend de lui, pas de nous.

03

Fédération, passerelles et découverte.

Joindre d'autres organisations. Joindre d'autres réseaux. Selon des conditions définies.

La fédération est ce que les plateformes fermées ne peuvent copier. Des organisations distinctes gardent leurs serveurs distincts tout en partageant une salle.

Elle exige aussi une politique écrite. Ouverte, sur liste d'autorisation, réservée aux partenaires ou totalement fermée : toutes sont valables et chacune modifie ce qu'il faut surveiller.

Les passerelles étendent cette idée au-delà du protocole. Elles relient les personnes qui ne migrent pas et donnent du temps à celles qui migrent.

Politique de fédération

• Modèle de fédération : ouvert, sur liste d'autorisation, réservé aux partenaires ou fermé
• Des listes d'autorisation et de refus avec une procédure de revue pour ajouter des partenaires
• Des listes de contrôle d'accès des serveurs par salle
• La délégation well-known, la découverte des serveurs et la stratégie de certificats
• La gestion et la rotation des clés de signature ainsi que la configuration des notaires
• Le diagnostic de résolution d'état, d'événements manquants, de lacunes d'historique et de trafic bloqué
• Des procédures d'intégration des partenaires pour les salles interorganisations
• Des conceptions de transferts interdomaines et unidirectionnels pour les réseaux segmentés
• Des serveurs de politique et des abonnements communs aux listes de politique entre partenaires
• Une procédure de défédération des partenaires à retirer

Passerelles et recherche

• Une architecture de passerelles : quels réseaux et quel modèle de salle
• Des passerelles vers WhatsApp, Telegram, Signal, Discord, Slack, Google Chat, Google Messages, Instagram, Facebook Messenger, LinkedIn, Bluesky, Steam, IRC et le courrier électronique
• Vous choisissez celles à inclure : chacune est un composant à exploiter, surveiller et parfois réparer ; aucune n'est activée par défaut
• Une correspondance d'identités pour attribuer les messages relayés au bon auteur
• Une configuration de relais pour les participants distants sans compte Matrix
• Configuration chiffrée des passerelles
• Des passerelles sur mesure pour les systèmes internes via l'API de services applicatifs
• La supervision, le retrait des passerelles et le traitement des données à l'arrêt
• La publication de l'annuaire des salles et le périmètre de découverte
• Une stratégie d'alias et de liens permanents, avec des adresses stables pour les salles durables
• Une hiérarchie d'espaces permettant aux nouveaux venus de s'orienter sans explication

Non inclus : le contrôle de l'autre côté. Une passerelle dépend entièrement de l'API et des conditions d'utilisation de l'autre réseau.

04

Connexion, comptes et intégration de l'annuaire.

Un compte, un annuaire, une seule entrée.

Les mots de passe locaux ne résistent pas aux besoins d'une organisation. Matrix parle OAuth et OpenID Connect via un service d'authentification dédié pour placer la connexion là où se trouvent déjà vos autres accès.

Le travail essentiel concerne le cycle de vie, pas la connexion. Arrivées, changements de poste et départs doivent donner ou retirer les bonnes salles sans ticket à déposer.

Se connecter

• Une authentification déléguée via un service d'authentification Matrix
• L'intégration du fournisseur d'identité en amont avec les services d'annuaire et courtiers
• Une migration de la connexion par mot de passe intégrée vers une connexion déléguée
• Une authentification multifacteur et un accès conditionnel appliqués par le fournisseur d'identité
• L'échange de jetons d'identité signés pour que widgets et services sachent qui est présent
• L'épinglage des certificats et la gestion des appareils pour les parcs de clients administrés
• L'accès invité et les invitations par courriel ou téléphone lorsque le cas le justifie

Comptes dans la durée

• La création et la suppression de comptes pilotées par l'annuaire d'entreprise
• Des parcours d'arrivée, de changement de poste et de départ associés aux comptes, salles et espaces
• Une politique d'identifiants : parties locales, noms affichés, avatars et adresses personnalisées
• L'association et le rapprochement des identifiants tiers
• Un périmètre d'annuaire pour que la recherche ne retourne que ce que la politique autorise
• Des procédures de désactivation, de renommage et de réactivation
• La gestion des sessions, la durée des jetons et les parcours de déconnexion forcée

Non inclus : l'exploitation de votre fournisseur d'identité. Le travail s'arrête à l'intégration et à la correspondance.

05

Clés, appareils et récupération.

Un chiffrement dont on peut récupérer l'accès.

Le chiffrement de bout en bout est la moitié facile. La moitié difficile est un téléphone perdu, un ordinateur effacé ou une arrivée dans une salle après des années de conversation.

La signature croisée, la sauvegarde des clés et le stockage des secrets transforment une démonstration de chiffrement en système exploitable par une organisation. Chacun modifie ce que la recherche, l'export et l'archivage peuvent voir.

Ces limites sont consignées plutôt qu'atténuées.

Activation

• Le chiffrement par défaut des nouvelles salles, avec des exceptions nommées
• La signature croisée et la vérification des appareils, y compris les parcours par emoji et lecture de code
• La sauvegarde des clés et le stockage des secrets côté serveur, avec gestion de la clé de récupération
• La migration vers la pile cryptographique actuelle dans les clients et SDK
• L'adaptation des bots, passerelles et services aux salles chiffrées
• Une stratégie de rotation des clés de salle et son coût dans les autres domaines

Au quotidien

• Le cycle de vie des appareils et sessions, avec révocation des appareils perdus ou retirés
• Une politique de visibilité de l'historique et de partage des clés, pour qu'une arrivée révèle ce que vous souhaitez
• L'effet réel du chiffrement sur la recherche, l'export et l'archivage
• L'analyse de contenu et le placement de l'antivirus là où le chiffrement le permet encore
• Une documentation de garde des clés et de récupération pour l'organisation
• Des guides pour utiliser la vérification et la récupération comme prévu

Schéma

01 / 06 · De l'extérieur vers l'intérieur

01 Périmètre

WireGuard, ports fermés, aucun accès par DNS

L'administration n'est pas sur le web public. Ses interfaces répondent uniquement par un tunnel WireGuard et à une adresse source autorisée, jamais à un nom d'hôte.

• Le port de fédération reste fermé jusqu'à ce que son ouverture soit une décision plutôt qu'une valeur par défaut.
• nginx termine la connexion côté public ; tout ce qui est derrière est atteint depuis le tunnel.
• Rien du déploiement ne peut être découvert par une résolution DNS.

wireguard · nginx · ACL d'adresse source · port de fédération fermé

02 Fédération

Liste d'autorisation d'abord, ouverture lorsque la modération est prête

Nous configurons la fédération selon la politique de l'organisation : fermée, sur liste autorisée ou ouverte.

• L'ouverture de la fédération suit la préparation de la modération, jamais l'inverse.
• La liste d'autorisation consigne les interlocuteurs avec lesquels l'organisation a accepté de communiquer.
• La fédération sélective est une décision de politique, consignée avant son activation.

synapse · politique de fédération · liste de serveurs autorisés

03 Identité

Authentification unique, séparation des domaines d'identité, filtrage du domaine de messagerie

L'authentification unique repose sur un fournisseur d'identité tel que Keycloak, avec séparation des domaines d'identité et filtrage du domaine de messagerie. Les comptes suivent l'annuaire de l'établissement plutôt qu'un deuxième annuaire privé.

• L'intégration du fournisseur d'identité et la configuration de sa base de données suivent les besoins de l'organisation.
• La durée des jetons de renouvellement est limitée et les appareils obsolètes sont supprimés automatiquement.
• La marque est intégrée au parcours de connexion, pas ajoutée après coup.

keycloak · séparation des domaines d'identité · postgresql · element web

04 Gouvernance

Application de la politique dans tout le parc et automatisation quotidienne

La modération est configurée avant l'ouverture d'un espace, pas après un incident. Un bot applique la politique dans tout le parc et les plugins assurent les tâches courantes.

• Un espace étudiant et un espace du personnel ne sont pas régis de la même manière sur un même serveur.
• Les bots et widgets assurent le routage, les rappels et le transfert vers votre service d'assistance existant.
• Nous examinons la configuration et documentons les procédures de reprise.

bot de modération · automatisation par plugins · listes de politique · intégration de l'assistance

05 Données

La conservation côté serveur et les documents qui la soutiennent

La conservation est fixée sur le serveur : une durée pour les messages et médias envoyés localement, une plus courte pour les médias provenant d'autres serveurs.

• Les médias ne sont servis qu'aux requêtes authentifiées. Les notifications ne contiennent aucun texte de message. La taille des envois est limitée.
• Nous préparons les analyses d'impact, registres de traitement, procédures d'effacement et procédures en cas de violation de données.
• La documentation, les schémas et les décisions d'architecture expliquent chaque réglage.

conservation synapse · postgresql · médias authentifiés · notifications sans contenu

06 Le salon

Le chiffrement là où il se justifie

Nous convenons du chiffrement salon par salon, selon les besoins de modération, de recherche et de conservation de l'organisation.

• Le chiffrement modifie les possibilités de la modération, de la recherche, des bots et widgets. L'activer partout désactiverait silencieusement les cinq couches qui l'entourent.
• Nous documentons l'effet des passerelles sur le chiffrement avant leur intégration.
• Les appels se déroulent dans la salle : OpenTalk, Jitsi et LiveKit pour Matrix-RTC, auto-hébergés et ouverts comme widgets.

element web · livekit (matrix-rtc) · opentalk · jitsi: prosody / jicofo / jvb / coturn

Non inclus : lire l'historique chiffré sans les clés. Personne ne peut le proposer ; une offre en ce sens est un signal d'alerte.

06

Choisir, personnaliser ou construire les applications clientes.

Le client est un choix. Le serveur ne décide pas de ce que les personnes regardent chaque jour.

Matrix sépare le serveur de l'application : ce que les personnes voient est un choix distinct, révisable sans toucher au déploiement. Plusieurs clients éprouvés existent ; ils diffèrent davantage par leur usage que par leurs capacités.

Le choix est plus facile selon le public que selon les fonctionnalités. Les personnes venant d'un chat d'équipe veulent un environnement familier ; celles d'une plateforme communautaire veulent des canaux et fils. Les administrateurs veulent une application de bureau légère qui ne les gêne pas.

S'ajoutent la personnalisation, le packaging et la gestion du parc : vos couleurs et votre nom, la distribution par vos canaux existants et une politique des applications autorisées à se connecter.

Choisir et déployer

• Element Web et Desktop pour les personnes venant d'une plateforme de chat d'équipe
• Element X pour les personnes utilisant surtout leur téléphone et recherchant la rapidité
• FluffyChat pour les personnes qui veulent de la simplicité et pour les écoles
• Cinny pour les personnes venant d'une plateforme communautaire et attendant des canaux
• Nheko pour les administrateurs et les personnes voulant une application native légère
• Un choix selon les futurs utilisateurs plutôt que par comparaison de tableaux de fonctions
• Un client web hébergé sur votre domaine plutôt qu'une adresse tierce
• Le packaging de bureau pour Windows, macOS et Linux
• La distribution mobile par les boutiques ou un canal interne
• Des notifications par une passerelle que vous contrôlez
• Une authentification unique intégrée jusqu'au client
• Une politique de parc : quelles versions de clients et applications peuvent se connecter
• Une migration entre clients sans perdre l'historique ni les clés

Personnaliser

• La personnalisation : couleurs, nom, icône, formulation et première utilisation
• Une version à votre marque publiée sous votre propre compte développeur
• Le retrait de fonctionnalités lorsque la simplicité est l'objectif
• Des widgets intégrant vos outils à la salle
• Un développement sur mesure avec les SDK clients publiés
• Une revue d'accessibilité du client réellement distribué
• Le choix, la personnalisation et l'intégration du client sont convenus dans le périmètre des travaux.

Nous choisissons et personnalisons un client Matrix existant pour votre organisation.

07

Clients, bots, widgets, appels et travail sur les SDK.

La salle est une surface de travail. Placez-y le travail.

Matrix publie une API de services applicatifs, une API de widgets et des SDK dans la plupart des langages courants. Cela suffit à intégrer la salle au travail plutôt qu'à en faire un lieu pour en parler.

Le travail client va d'une version personnalisée à une application spécialisée : borne, salle unique, affichage en lecture seule, faible bande passante ou messagerie intégrée à un logiciel déjà distribué.

Les appels en font aussi partie. Les appels de groupe exigent une unité de transfert, un service d'identifiants et des règles de pare-feu, pas seulement un bouton dans le client.

Clients et code

• Une évaluation des clients web, bureau, mobiles et terminal
• Des versions à votre marque : nom, icône, couleurs, présence en boutique, signature et publication
• Des clients sur mesure avec les SDK Rust, JavaScript, Kotlin, Swift, Dart ou .NET
• Des clients spécialisés : borne, salle unique, lecture seule, terrain et faible bande passante
• La messagerie Matrix intégrée à une application déjà distribuée
• L'accessibilité et la localisation, y compris les dispositions de droite à gauche
• Des services applicatifs, événements et états personnalisés pour les données métier de la salle
• Des modules de serveur d'accueil : contrôles antispam, règles tierces et points d'intégration d'authentification personnalisés
• Des tests de conformité et d'interopérabilité entre clients et serveurs

Bots, widgets et appels

• Une plateforme de bots à plugins pour partager un environnement d'exécution entre plusieurs automatisations
• Des bots pour l'accueil de l'assistance, les alertes, flux, approbations et tâches courantes
• Des passerelles courriel vers salle et salle vers courriel
• Des widgets : tableaux blancs, sondages, réunions, tableaux de bord, formulaires et approbations
• L'authentification des widgets par jetons signés, leur hébergement et le périmètre des permissions
• La visioconférence autonome et intégrée
• Le déploiement et le dimensionnement de l'unité de transfert pour éviter un maillage entre pairs lors des appels de groupe
• Des serveurs de relais et de traversée, des règles de pare-feu et la gestion de la traduction d'adresses
• Le raccordement des notifications mobiles pour faire sonner les appels sur les appareils verrouillés
• L'enregistrement, la conservation et la gestion du consentement lorsque la réglementation l'exige

Non inclus : les widgets ne font pas partie du coeur de la spécification. Mieux vaut le savoir avant d'en faire dépendre une feuille de route.

08

Modération, conservation et documents de protection des données.

Une politique qui résiste à une demande de consultation.

La modération est ici un travail au niveau du protocole : niveaux de pouvoir, listes de politique, contrôle d'accès aux salles et signalements. Les outils sont ouverts et disponibles. C'est généralement la politique qui manque.

La protection des données se situe au même endroit. Un système fédéré, répliqué et chiffré exige ses registres des traitements, ses règles de conservation et une description honnête de ce que l'effacement peut réellement atteindre.

Modération

• Des outils de modération avec un bot doté des pouvoirs nécessaires
• Des listes de politique : locales, abonnements à des listes partagées et listes publiées par vous
• Un réglage des protections contre les arrivées massives, vagues de spam et médias indésirables
• La conception des rôles et niveaux de pouvoir pour donner aux modérateurs exactement ce qu'il leur faut
• Le routage des signalements vers une file de triage avec un responsable nommé
• Des bannissements de serveurs, listes de contrôle d'accès aux salles et procédures de quarantaine
• L'analyse de contenu et la comparaison d'empreintes lors de l'envoi
• Des procédures de confiance et de sécurité, circuits d'escalade et comptes rendus de décision
• Des rapports de transparence conformes au régime applicable

Registres et règles

• L'accompagnement des analyses d'impact et les registres des traitements
• La cartographie des données entre salles, médias, clés, appareils et trafic de fédération
• La conception de la résidence des données et du lieu d'hébergement
• Une politique de conservation et d'expiration des messages, avec son application technique
• L'accès des personnes concernées, l'export et le retrait de contenu, avec leurs limites réelles
• Le chiffrement au repos et la documentation de garde des clés
• La documentation des sous-traitants et sous-traitants ultérieurs pour chaque composant utilisé
• Description de l’architecture de sécurité, modèle de menace et normes de configuration
• Les textes de politique d'utilisation acceptable, d'intégration et de départ

Non inclus : un conseil ou une validation juridique. Ce sont des documents techniques examinés par votre conseil, pas un remplacement de celui-ci.

09

Observabilité, maintenance et assistance.

Quelqu'un doit le surveiller un mardi.

Un serveur d'accueil que personne ne surveille est indéfendable. Les métriques, journaux et traces transforment "le chat est lent" en un composant identifié.

La maintenance est la moitié peu visible : mises à jour, nettoyage, dérive et restauration réellement exécutée plutôt que planifiée.

L'assistance intervient ici derrière votre propre service d'aide, pas directement devant vos utilisateurs.

Surveiller

• Des métriques et tableaux de bord pour le serveur d'accueil, la base, les passerelles, médias et appels
• Des journaux structurés et agrégés, avec une conservation conforme à la politique
• Un traçage distribué des requêtes lentes et retards de fédération
• Des règles d'alerte liées à des procédures écrites plutôt qu'à de simples seuils
• Des contrôles synthétiques de connexion, livraison, portée de fédération et établissement d'appel
• Une console d'administration pour la gestion quotidienne des utilisateurs et salles
• L'automatisation des tâches d'exploitation répétitives via l'API d'administration
• Des rapports de capacité, croissance et coûts du déploiement

Maintenir en service

• Une maintenance gérée : mises à jour, mises à niveau des composants et nettoyage courant
• Le suivi des avis de sécurité et la planification des correctifs pour vos systèmes
• Le suivi des versions, le calendrier des mises à niveau et les branches à support prolongé
• La revue et la correction des dérives de configuration
• Une configuration des sauvegardes et une restauration répétée, testée plutôt que supposée
• La maintenance des bases, l'entretien des médias, le nettoyage des éléments orphelins et la politique de quotas
• Des procédures de réponse aux incidents et des modèles de revue après incident
• Une assistance d'escalade derrière votre propre service d'aide
• Des contrôles de santé périodiques remis dans un rapport écrit

Non inclus : une astreinte ou toute tâche exigeant une deuxième personne éveillée. Les délais de réponse sont indiqués dans les niveaux d'assistance à /matrix/G. L'exploitation reste chez vous ou votre fournisseur.

10

Revue indépendante, formation et conseil.

Un regard extérieur sur votre parc, une formation pour le maintenir et un conseil avant de vous engager.

Beaucoup de déploiements fonctionnent sans que personne sache pourquoi. Une revue est un travail délimité avec un résultat écrit : ce qui est exposé, obsolète et ce qui cassera ensuite.

La formation est l'autre moitié. L'intérêt d'un standard ouvert est que vous n'êtes obligé de garder personne. La transmission est le livrable, pas le risque.

Parfois, la réponse utile vient avant tout cela : ce standard convient-il seulement au besoin ?

Examen indépendant

• Une revue de configuration selon les pratiques actuellement recommandées
• Une revue de sécurité de l'exposition, de l'authentification, des limites de débit et de la gestion des secrets
• La posture de fédération : ce qui est accessible, ce qui est de confiance et ce qui ne devrait être ni l'un ni l'autre
• La posture de chiffrement : signature croisée, sauvegarde des clés, entretien des appareils et salles ouvertes
• Une revue de performance et de capacité nommant les vrais goulets d'étranglement
• Une validation des sauvegardes et restaurations testant la restauration, pas le calendrier
• Une revue du parcours de mise à niveau, avec les composants en fin de vie
• Un inventaire des passerelles et bots avec un responsable consigné pour chacun
• Une feuille de route de correction priorisée avec effort et impact par point

Formation, transfert, conseil

• Une formation des administrateurs, opérateurs et modérateurs sur votre déploiement
• Des séances pour développeurs sur l'API client-serveur, les services applicatifs et widgets
• L'accueil des utilisateurs finaux et les habitudes de vérification et récupération des appareils
• Des supports de formation de formateurs pour que l'organisation continue sans nous
• Des procédures, manuels et documents de transmission rédigés pour votre installation
• Un conseil indépendant des fournisseurs sur l'adéquation d'un standard de messagerie ouvert
• Construire ou acheter, auto-héberger ou faire gérer, avec les compromis explicités
• L'aide aux achats : exigences, critères d'évaluation et questions à poser
• Une stratégie de sortie et une revue de portabilité pour que le déploiement reste déplaçable par vous

Schéma

Serveurs d'accueil, clients et authentification unique, déployés et sécurisés pour les écoles, universités et établissements publics.

01 AUDIT

Étape 01 / 09

Les questions avant les conteneurs. Ce que vous exploitez déjà détermine l'essentiel de l'architecture ; le reste relève de la politique plutôt que du logiciel.

• L'identité existante et les domaines de messagerie autorisés à détenir un compte
• Ce qui doit être journalisé, ce qui ne doit jamais être conservé et pour combien de temps
• Les établissements avec lesquels vous devez communiquer et ceux avec lesquels vous ne le devez pas
• Si un seul serveur dédié suffit réellement à la charge décrite

LIVRABLE : des constats écrits, une architecture cible et un périmètre que vous pouvez approuver.

02 CONCEPTION

Étape 02 / 09

Chaque choix coûteux à inverser est consigné avant d'être fait. Les décisions d'architecture et les schémas expliquent les choix pour l'organisation.

• Politique de fédération convenue avant le lancement : fermée, sur liste autorisée ou ouverte
• Conservation : une durée pour les messages et médias locaux, une plus courte pour les médias distants
• Chiffrement appliqué par salle selon un modèle délibéré, pas un commutateur unique
• Passerelles évaluées sur papier, y compris là où elles rompent le chiffrement de bout en bout

LIVRABLE : des comptes rendus de décision, schémas et politiques lisibles par votre délégué à la protection des données.

03 DÉPLOIEMENT

Étape 03 / 09

Serveur d'accueil, client, base et proxy inverse, conteneurisés sur votre matériel. Chaque composant est versionné pour reconstruire le déploiement plutôt que s'en souvenir.

• Un serveur dédié, sans opérateur tiers détenant vos messages
• PostgreSQL configuré pour Synapse plutôt que laissé sur ses valeurs par défaut
• nginx en amont, avec une délégation .well-known pour que la fédération lise le bon nom
• Element Web à votre nom et vos couleurs plutôt qu'au logo d'un fournisseur

LIVRABLE : un serveur d'accueil fonctionnel, défini dans des fichiers plutôt qu'assemblé à la main.

04 IDENTITÉ

Étape 04 / 09

Un compte, un mot de passe, un seul endroit pour le révoquer. L'authentification unique relie Matrix à votre annuaire existant.

• Un fournisseur d'identité en amont avec séparation des domaines d'identité
• Le filtrage du domaine de messagerie décide qui peut détenir un compte
• Configuration de la base de données et intégration du fournisseur d'identité
• Matrix fait confiance au fournisseur ; l'accès s'arrête donc là où l'annuaire le prévoit

LIVRABLE : une connexion par votre fournisseur d'identité et une seule liste de personnes.

05 SÉCURISATION

Étape 05 / 09

Les valeurs par défaut sont conçues pour Internet ouvert. Un établissement a besoin des réglages sous-jacents et d'un relevé écrit des modifications et de leurs raisons.

• Des médias authentifiés pour qu'un lien seul ne permette pas de lire un fichier
• Des notifications qui n'emportent aucun contenu de message hors du serveur
• Des limites d'envoi, appareils obsolètes supprimés et jetons de renouvellement à durée limitée
• Des interfaces d'administration accessibles uniquement par WireGuard, par adresse source et jamais par nom

LIVRABLE : un dossier de sécurisation avec chaque écart aux valeurs par défaut et sa raison.

06 FÉDÉRATION

Étape 06 / 09

La fédération est une politique, pas un commutateur. Elle s'ouvre lorsque la modération peut la soutenir, d'abord à des serveurs nommés.

• Accès fédéré configuré selon la politique convenue
• Un bot de modération applique la politique dans tout le parc
• Extensions de bots pour les tâches courantes des salons et l'intégration de services
• Le signalement, l'escalade et le traitement des preuves documentés avant toute ouverture plus large

LIVRABLE : un modèle de fédération et de modération lisible par les services juridiques et d'aide aux étudiants.

07 RÉUNIONS

Étape 07 / 09

Le travail commence dans le chat et s'achève dans les appels et widgets. Les médias en temps réel sont hébergés à côté du serveur d'accueil pour que les appels restent eux aussi dans le parc.

• OpenTalk pour les réunions planifiées, hébergé à côté du serveur d'accueil
• Jitsi avec Prosody, Jicofo, JVB et coturn, tous auto-hébergés
• LiveKit porte les appels Matrix-RTC dans le client Matrix
• Des widgets intégrés à la salle pour qu'un séminaire y travaille sans la quitter

LIVRABLE : chat, réunions et appels dans un seul parc, soumis aux mêmes règles.

08 EXPLOITATION

Étape 08 / 09

Le jour du lancement n'est pas la partie intéressante. C'est le mardi où quelque chose ne va pas et où quelqu'un doit comprendre plutôt que redémarrer.

• Surveillance de sécurité et planification de la réponse aux incidents
• Revue de configuration et procédures de reprise documentées
• Tests de restauration de base de données dans un environnement isolé
• Une conservation appliquée sur le serveur plutôt que laissée à la mémoire de quelqu'un

LIVRABLE : un périmètre honnête, annoncé à l'avance plutôt que découvert ensuite.

09 TRANSFERT

Étape 09 / 09

Vous devez pouvoir nous remplacer. La documentation le prouve et s'adresse à la personne qui reprend le système.

• Documentation, schémas et comptes rendus de décisions d'architecture
• DPIA, registre des traitements, politique de suppression et procédure de violation de données, tous préparés
• Chaque réglage différent de la valeur par défaut, avec sa raison
• Écrit pour la personne qui reprend le système, pas pour celle qui l'a construit

LIVRABLE : le système, les documents et les comptes, sans rien qui reste seulement dans notre mémoire.

10 CONTACT

Objectif

Commencez à l'étape 01. Un audit est un petit travail fixe qui indique si la suite vaut la peine.

• Définir un déploiement
• Demander une migration
• Demander un devis
• Une simple question

Aucun script tiers, aucun suivi, aucun captcha. Ou écrivez à hello@ave17.com

Non inclus : un certificat de réussite ou d'échec. Une revue présente des constats. La certification relève d'un régime distinct avec des auditeurs distincts.

Début

Commencez par le problème, pas par le produit.

• Dites-nous ce que vous exploitez, ce que cela doit devenir et les contraintes : réglementation, effectif, réseau isolé, annuaire existant ou plateforme liée par contrat jusqu'à l'année prochaine.
• Vous recevez des questions, une forme générale du travail et une note claire sur les éléments que nous ne prendrions pas en charge.

Écrire à

hello@ave17.com

À propos

Matrix

Non inclus : un devis forfaitaire à partir d'un premier message. Toujours le périmètre avant le prix.

A

La voie habituelle et celle des standards ouverts.

Deux façons de posséder une conversation. Aucune colonne ne nomme une marque : la différence est structurelle, pas concurrentielle.

Non inclus : prétendre que la colonne de droite est toujours la réponse. Certains besoins sont réellement mieux servis par un produit acheté.

B

Six couches entre Internet et une phrase.

Chaque couche est une décision distincte et peut être mal configurée indépendamment. Sélectionnez un anneau pour lire ce qu'il décide.

Périmètre

DNS, délégation et TLS déterminent ce qui est accessible avant même qu'un message existe.

Fédération

Les listes d'autorisation, contrôles d'accès des serveurs et clés de signature décident quels serveurs peuvent communiquer avec le vôtre.

Serveur

Le serveur d'accueil, la base et le stockage de médias constituent le parc. La sécurisation et les limites de débit le maintiennent en fonctionnement.

Identité

Le fournisseur d'identité et le service d'authentification décident qui détient un compte et pour combien de temps.

Salon

L'appartenance, les niveaux de pouvoir, règles d'arrivée et visibilité de l'historique décident qui voit quoi et depuis quand.

Message

Le chiffrement de bout en bout, les clés d'appareil et la signature croisée décident qui peut lire le contenu. Les serveurs le relaient sans le lire.

Non inclus : promettre que les six arrivent configurées. La plupart des déploiements en traitent trois correctement et héritent du reste.

C

Comment se déroule un projet.

Six étapes avec un résultat écrit à la fin de chacune. Sélectionnez une étape pour lire le travail et son résultat.

Non inclus : une durée fixe. Les étapes sont successives, mais leur durée dépend de votre parc et de vos approbations.

D

Trois façons de fédérer et comment choisir.

La fédération inquiète les achats, généralement parce qu'ils entendent "ouvert à tout Internet". C'est un réglage à trois positions.

Fermé

Votre serveur ne parle à aucun autre. Vous avez délivré chaque compte, chaque salle est interne et aucun message ne franchit votre périmètre. La fédération est désactivée, pas simplement filtrée.

Pour les parcs où la réponse à "cela peut-il communiquer avec l'extérieur ?" doit être non, par écrit.

Partenaires nommés

Votre serveur fédère avec une liste de serveurs nommés et refuse les autres. Fournisseurs, organisme de tutelle, autre administration : chacun est ajouté délibérément et peut être retiré de la même façon.

Le cas courant. Une portée là où vous la voulez, une porte fermée partout ailleurs.

Ouvert

Votre serveur fédère avec le réseau public. Toute personne ayant une adresse Matrix peut joindre vos équipes, sous réserve de vos règles d'arrivée, politiques de salle et modération.

Pour le travail ouvert au public : communautés, assistance et tout ce dont l'accessibilité est l'objectif.

Non inclus : prétendre que la fédération ouverte est sûre par défaut. Elle exige une modération, des politiques de salle et de l'attention.

E

Les questions réellement posées.

Ce n'est pas une introduction au protocole. Voici les huit questions posées lors d'une réflexion sérieuse, avec les réponses que nous donnerions lors d'un appel.

Quelle différence avec un serveur public gratuit ?

Un serveur public est partagé : votre adresse porte le domaine d'un tiers, vos données côtoient celles des autres et vous héritez des limites et politiques de l'opérateur. Ici, le déploiement vous est réservé, l'adresse porte votre domaine et vous fixez les limites.

Est-ce vraiment conforme ou seulement hébergé en Europe ?

La localisation n'est qu'un fait parmi d'autres et ne prouve rien seule. Ce qui compte est qui peut accéder aux données, selon quelle procédure et si vous pouvez vérifier l'affirmation. La section sur les accès à /matrix/H précise exactement les accès dont nous disposons et comment les vérifier de l'extérieur.

Pouvons-nous l'exploiter sur notre matériel ?

Oui, et c'est la moins chère des deux options. Votre machine, compte cloud ou centre de données ; nous assurons l'installation, la sécurisation et l'entretien. Les prérequis figurent dans Déploiement.

Que se passe-t-il si nous voulons partir ?

Vous emportez le serveur. L'adresse, les salles et l'historique appartiennent au déploiement, pas à un contrat avec nous. La sortie est conçue et documentée dès le départ ; voir Départ.

Facturez-vous par personne ?

Non. Cent personnes ou mille coûtent la même chose. Le prix suit l'infrastructure et le travail, pas l'effectif.

Qui peut lire nos messages ?

Dans une salle chiffrée de bout en bout, seuls les appareils des participants, ni le serveur ni nous. Dans les autres salles, le serveur détient le contenu et toute personne ayant un accès administratif peut le lire, nous compris pendant la maintenance. La section sur les accès à /matrix/H en précise les limites et les moyens de les vérifier.

À quelle vitesse répondez-vous en cas de panne ?

L'assistance standard répond sous deux jours ouvrés, la prioritaire sous huit heures ouvrées. Une panne est toujours comptée mais jamais facturée, quelle que soit la formule. Voir Assistance.

Pouvons-nous le voir fonctionner d'abord ?

Nous examinons vos besoins et convenons de la manière d'évaluer le déploiement proposé.

Non inclus : promettre que chaque réponse restera intacte dans votre environnement. Certaines changeront après son examen.

F

Ce que cela coûte.

Modifiez les chiffres et regardez le total. Rien n'est envoyé nulle part ; le calcul s'exécute dans votre navigateur et reste une estimation, pas un devis.

Installation, une fois

590 EUR

Travaux techniques hors périmètre

110 EUR par heure

Une évaluation

à partir de 3 jours à 110 EUR de l'heure

Plus de 1000 utilisateurs

la grille s'arrête, nous établissons un devis

Aucune TVA ajoutée : nous ne sommes pas immatriculés. Le montant affiché est le total.

La mise en place est facturée une fois ; le reste est mensuel. Les contraintes inhabituelles sont définies avant d’être chiffrées.

Non inclus : un devis forfaitaire à partir d'un premier message. Toujours le périmètre avant le prix.

G

Ce que l'assistance couvre et ce qu'elle ne couvre pas.

Deux niveaux. Ce que chacun couvre et ne couvre pas est consigné.

Heures ouvrées, du lundi au vendredi, hors jours fériés : une demande envoyée le vendredi soir reçoit une réponse le jour ouvré suivant. Trois demandes distinctes dans un message comptent comme trois demandes.

Couvert

• Le serveur est en panne, inaccessible ou renvoie des erreurs
• Un composant installé dans le déploiement est défaillant
• Des problèmes système : disque, mémoire, certificats, sauvegardes
• Une reconfiguration demandée : ajouter un composant, changer une politique, ajuster une limite
• Les mises à niveau et tout ce qui tombe en panne pendant celles-ci

Non couvert

• Les questions générales sur le fonctionnement du logiciel ouvert sous-jacent
• Écrire vos bots ou services applicatifs
• Pourquoi un composant tiers se comporte ainsi ; ses auteurs répondent mieux que nous
• Un composant tiers défaillant après ses propres changements en amont
• Les mises à niveau de distribution de votre système d'exploitation sur votre machine
• Le conseil pour construire une activité sur le logiciel

Non inclus : une permanence de 24 heures. Les délais de réponse sont explicitement indiqués en heures ouvrées.

H

Ce à quoi nous pouvons accéder et ce qui nous est inaccessible.

La moitié gênante d'abord : une page affirmant l'absence totale d'accès ne dit pas la vérité.

Ce à quoi nous pouvons accéder

• Tout fichier sur un serveur que nous maintenons ; la maintenance passe par SSH avec root
• Tout stockage en clair, y compris les données relayées d'autres réseaux qui, par conception, ne peuvent être chiffrées de bout en bout
• Le contenu des bases, journaux et sauvegardes du déploiement
• Les métadonnées des comptes : leur existence, connexions et appareils

Ce qui nous est inaccessible

• Le contenu des salles chiffrées de bout en bout ; les clés résident sur les appareils, pas sur le serveur
• Tout ce qui est sur une machine à laquelle nous n'avons jamais eu accès
• Les sauvegardes sont chiffrées avec une clé que vous conservez. Pendant que nous administrons la machine, nous avons accès aux données elles-mêmes. Après la révocation de notre accès, nous ne pouvons plus lire les sauvegardes
• Tout déploiement après transmission et retrait des accès

Ce que nous avons écrit nous-mêmes

• La gestion de configuration qui construit et maintient chaque déploiement
• La supervision et les alertes qui le surveillent ensuite
• Choix, personnalisation et intégration du client Matrix
• Les outils de sauvegarde et restauration, y compris les tests de restauration
• Tout le reste est du logiciel libre tiers, nommé ouvertement sur les pages de service

Vérifier plutôt que croire

• Les connexions et les lancements de programmes sont consignés dans le journal d'audit sur votre propre machine
• Demandez le retrait des accès entre les travaux ; c'est une demande normale
• Exécutez le cadre d'audit et observez les appels système
• Vérifiez vous-même les affirmations sur l'infrastructure. Les tests publics et leurs instructions figurent dans la section "Où il tourne et comment le vérifier sans nous demander." à /matrix/I.

Pouvoir et faire sont différents. L'accès sert uniquement à maintenir le serveur et le réparer en cas de panne. C'est le journal qui permet de nous y tenir, pas notre parole.

Non inclus : prétendre à un accès nul. Maintenir un serveur exige de pouvoir y accéder ; prétendre le contraire serait un mensonge vérifiable.

I

Où il tourne et comment le vérifier sans nous demander.

La plupart des opérateurs s'arrêtent à "serveurs dans l'UE". Vous pouvez tester tout ce qui suit de l'extérieur sans nous demander.

Exécutez les tests vous-même

• internet.nl : tests indépendants du site et du courrier de tout domaine
• DNSViz : parcourt la chaîne DNSSEC et montre chaque signature
• Hardenize ou équivalent : une page sur la posture DNS, courrier et web
• Un rapport SSL sur l'hôte : certificat, chaîne et protocoles pris en charge
• Pointez n'importe lequel vers ave17.com. Nous ne vous demandons pas de croire l'affirmation sur parole.

Cela ne sécurise pas à lui seul un serveur de messagerie. Cela montre comment la société travaille, ce que vous pouvez vérifier avant de signer quoi que ce soit.

Les contrôles opérationnels sont documentés et vous pouvez les vérifier.

J

Comment partir.

La sortie est conçue au départ. Un opérateur qui rend le départ difficile vous renseigne sur le reste de l'accord.

L'identité vous appartient

Le nom du serveur est votre domaine. Quel que soit l'opérateur, les adresses de vos équipes ne changent pas de propriétaire.

Vous recevez la machine, pas un export

Un déploiement est une base, un stockage de fichiers et une configuration. Les trois sont transmis tels quels, pas convertis en archive de départ.

La configuration est lisible

Les déploiements sont versionnés et examinables. Votre prochain ingénieur peut lire leur construction plutôt que la deviner.

La transmission est un service, pas une pénalité

Des procédures, une visite guidée et un responsable nommé pour chaque composant. Facturés comme du travail, au tarif habituel.

L'accès est retiré sur demande

Clés supprimées, sessions terminées, retrait visible dans vos journaux.

Aucuns frais de sortie, jamais

Aucun coût pour partir et aucun préavis déguisé en frais.

C'est aussi la réponse honnête à la dépendance fournisseur. Le protocole est ouvert : un autre opérateur peut reprendre le déploiement, et plusieurs existent. C'est l'intérêt de ne pas posséder le protocole.

Non inclus : du travail gratuit. La transmission est un travail facturé comme tel, mais le départ lui-même n'est pas facturé.

K

Votre interlocuteur.

Votre interlocuteur et les documents associés.

Les conditions de service, la notice de confidentialité et l'accord de sous-traitance au titre de l'article 28 sont publiés intégralement sur ce site avant toute demande de signature.

Écrire à

hello@ave17.com

À propos

Matrix

Non inclus : un conseil juridique. Nous exposons notre propre position ; il vous appartient de prendre conseil sur vos obligations.

Comment cela fonctionne

• A · La voie habituelle et celle des standards ouverts
• B · Six couches entre Internet et une phrase
• C · Comment se déroule un projet
• D · Trois façons de fédérer et comment choisir

Avant d'acheter

• F · Ce que cela coûte
• G · Ce que l'assistance couvre et ce qu'elle ne couvre pas
• E · Les questions réellement posées

Avant de faire confiance

• H · Ce à quoi nous pouvons accéder et ce qui nous est inaccessible
• I · Où il tourne et comment le vérifier sans nous demander
• J · Comment partir
• K · À qui vous avez affaire