RFP d'accès à distance : 20 questions qui forcent la transparence

Acheter un logiciel d'accès à distance avec une checklist semble sûr — jusqu'à ce que tous les fournisseurs répondent « oui » à chaque ligne. Le vrai travail d'un RFP est d'obtenir des preuves — schémas, noms de protocoles, certificats, journaux — pour que vous puissiez comparer des compromis, pas du marketing. Cet article propose 20 questions ciblées qui séparent les revendications des fournisseurs de la réalité opérationnelle, explique à quoi ressemble une bonne réponse et signale les pièges rédhibitoires à refuser.

Comment interpréter ces réponses

Ne notez pas les fournisseurs sur le fait qu'ils disent « nous supportons X » — notez‑les sur les artefacts qu'ils fournissent. Demandez des diagrammes d'architecture, des empreintes de certificats TLS, des exemples de lignes de journaux (sanitisées), une chronologie d'incident documentée et un compte de test reproduisant un comportement revendiqué. Si un fournisseur refuse de fournir des preuves, ce refus est déjà une réponse.

20 questions qui font craquer les fournisseurs

1. Quel est votre modèle de connexion (P2P, brokered, relais) ?

   Pourquoi c'est important : les performances, la latence et qui peut observer le trafic dépendent du fait que les sessions soient directes ou proxyfiées. Demandez un diagramme et une description du flux de paquets.

   Preuve acceptable : un diagramme réseau montrant le traversal NAT, l'utilisation de STUN/TURN et les secours ; des exemples de plages d'IP utilisées par les relais.

   Signes d'alerte : réponses vagues du type « nous faisons ce qui est le plus rapide » ou refus de décrire les mécanismes de secours.

2. Si une session utilise un relais, qui l'exploite et quelles sont les régions ?

   Pourquoi c'est important : un opérateur de relais peut voir le trafic déchiffré si TLS y termine. Vous devez savoir si le relais est multi‑régions, mono‑région ou opéré par le client.

   Preuve acceptable : liste des entités opérant les relais, carte des régions et SLA pour le basculement régional. Pour Tenvo : nous exploitons un relais géré (serveurs en Allemagne). Si vous exigez votre propre relais, envisagez l'auto‑hébergement de RustDesk.

   Signes d'alerte : absence d'information sur les régions ou « nous utilisons des fournisseurs cloud » sans nommer les régions ni le comportement de basculement.

3. Comment le chiffrement des sessions est‑il implémenté et où TLS termine‑t‑il ?

   Pourquoi c'est important : les fournisseurs vantent souvent un chiffrement fort tout en omettant où les clés sont détenues. Un chemin direct P2P préserve un TLS de bout en bout entre les appareils ; lorsque le trafic bascule vers un relais, TLS termine à ce relais.

   Preuve acceptable : noms de protocoles (TLS), processus d'émission de certificats par appareil, et un diagramme montrant les points de terminaison. Demandez le mécanisme utilisé pour créer les certificats des appareils et leur durée de vie.

   Signes d'alerte : affirmations du type « le relais ne voit jamais les données » sans preuve cryptographique ou détails sur la garde des clés.

4. Qui détient les clés privées et comment sont‑elles protégées ?

   Pourquoi c'est important : la garde des clés détermine si un fournisseur — ou toute personne ayant accès à leur infrastructure — peut usurper des appareils ou déchiffrer des sessions via le relais.

   Preuve acceptable : description du cycle de vie des clés, usage d'HSM si applicable, et séparation des fonctions pour la signature. Si le fournisseur émet des certificats par appareil, demandez à voir la politique de signature de la CA.

   Signes d'alerte : « Nous gardons les clés en sécurité » sans détail procédural ou technique.

5. Décrivez votre modèle d'authentification : identités des appareils, identités utilisateurs et options MFA.

   Pourquoi c'est important : des modèles d'identité flous provoquent une dérive des privilèges et de mauvais journaux d'audit. Vous voulez une identité au niveau de l'appareil plus l'authentification utilisateur avec des options MFA solides (TOTP, push, tokens matériels ou passkeys).

   Preuve acceptable : diagrammes de flux d'authentification, mécanismes MFA supportés, et exemples d'entrées d'audit liant les sessions aux identifiants utilisateur.

   Signes d'alerte : compte partagé unique pour l'accès sans surveillance ou absence de MFA pour les actions d'administration.

6. Supportez‑vous SSO / SCIM / provisioning et comment les groupes sont‑ils mappés ?

   Pourquoi c'est important : l'onboarding/offboarding en entreprise doit être automatisé pour éviter des accès obsolètes.

   Preuve acceptable : support du schéma SCIM, étapes d'intégration SAML/OIDC SSO, fréquence de synchronisation des groupes, et exemples de CSV ou payload SCIM.

   Signes d'alerte : provisioning manuel par CSV uniquement sans piste d'audit.

7. Quelle télémétrie est collectée et les clients peuvent‑ils se désengager ou contrôler la rétention ?

   Pourquoi c'est important : la télémétrie peut inclure des métadonnées sensibles (noms d'utilisateur, noms d'hôte, adresses réseau). Vous devez contrôler ce qui est collecté et pour combien de temps.

   Preuve acceptable : liste de télémétrie (catégories, pas de PII brut), valeurs par défaut de rétention, et contrôles d'entreprise pour se désengager. Demandez un schéma d'enregistrement de télémétrie exemple.

   Signes d'alerte : « Nous collectons beaucoup de métriques » et refus de définir la rétention ou de fournir des contrôles de suppression.

8. Comment les sessions sont‑elles consignées et quel est le niveau de détail des logs ?

   Pourquoi c'est important : pour la conformité et la médecine légale vous avez besoin du démarrage/arrêt de session, de l'identité utilisateur, de l'appareil cible, et idéalement des métadonnées de session comme les IP et les sauts de relais. Si l'enregistrement de session est supporté, vous avez besoin du détail de stockage, chiffrement et rétention.

   Preuve acceptable : lignes de logs exemples (sanitisées), docs d'intégration SIEM, et options de rétention/archivage.

   Signes d'alerte : logs uniquement dans le portail fournisseur sans export ni API.

9. Offrez‑vous l'enregistrement des sessions et comment est‑il sécurisé ?

   Pourquoi c'est important : l'enregistrement aide les audits mais augmente l'exposition. Vous avez besoin de contrôles clairs sur qui peut lire les enregistrements, comment ils sont chiffrés et retenus, et les processus de suppression.

   Preuve acceptable : approche de chiffrement des enregistrements, contrôles d'accès, rétention, et une API ou option d'export compatible S3.

   Signes d'alerte : pas de RBAC sur les enregistrements ou enregistrements stockés en clair.

10. Quels rôles administratifs et primitives RBAC fournissez‑vous ?

    Pourquoi c'est important : un RBAC granulaire réduit les risques. Cherchez des modèles de rôle, des politiques de moindre privilège, et la séparation entre le support et les superadmins.

    Preuve acceptable : modèle RBAC, limites de périmètre (par équipe, par appareil), et exemples de politiques pour un rôle helpdesk vs un sysadmin.

    Signes d'alerte : rôles admin tout ou rien ou backdoors de superadmin cachées.

11. Comment gérez‑vous l'accès sans surveillance et l'élévation temporaire ?

    Pourquoi c'est important : l'accès sans surveillance est pratique mais dangereux. Vous voulez une élévation juste‑à‑temps, des gardes d'approbation et des jetons limités dans le temps.

    Preuve acceptable : diagrammes de workflow, durées de vie (TTL) des jetons, et une piste d'audit reliant l'élévation à un approbateur.

    Signes d'alerte : clés permanentes pour l'accès sans surveillance sans processus d'approbation.

12. Quelles sont vos pratiques de patching, build et release pour le code client et serveur ?

    Pourquoi c'est important : des vulnérabilités peuvent exister dans les clients et relais. Vous avez besoin de réponses standard sur la cadence des mises à jour, les builds signés, et les processus de divulgation CVE.

    Preuve acceptable : cadence de publication (par ex. correctifs de sécurité hebdomadaires), détails de signature des builds, et une politique CVE publique ou client.

    Signes d'alerte : pas de processus documenté de publication ou de signature.

13. Supportez‑vous des relais on‑prem ou gérés par le client, et quel en est le coût ?

    Pourquoi c'est important : certaines régulations exigent une infrastructure locale. Mais l'auto‑hébergement transfère la charge opérationnelle ; quantifiez le coût et les différences de support.

    Preuve acceptable : guide de déploiement, profil de ressources pour un relais, et tarification pour géré vs auto‑hébergé. Remarque : Tenvo est un relais géré exploité par nous (serveurs en Allemagne) ; si vous avez besoin d'infrastructure on‑prem, envisagez l'auto‑hébergement de RustDesk ; pour de nombreuses organisations le relais géré revient moins cher si on compte l'astreinte, les patchs et le renouvellement des certificats.

    Signes d'alerte : promettre l'auto‑hébergement sans documentation ou lier cela à des contrats entreprise coûteux.

14. Quels sont vos termes SLA pour la disponibilité, le basculement et le temps de réponse support ?

    Pourquoi c'est important : la disponibilité, le basculement régional et les temps de réponse doivent être contractuels. Demandez MTTR, % de disponibilité et modalités de crédit.

    Preuve acceptable : PDF SLA montrant les objectifs de disponibilité, niveaux de support et matrice d'escalade d'incident.

    Signes d'alerte : SLA verbal ou déclarations « nous visons » sans pénalités ni crédits.

15. Comment détectez‑vous et répondez‑vous à la compromission d'un compte ou d'un appareil ?

    Pourquoi c'est important : une détection et un confinement rapides limitent le rayon d'action. Vous avez besoin de mécanismes clairs de révocation et d'un exemple de chronologie d'incident.

    Preuve acceptable : API de révocation, rapport d'incident exemple (sanitisé), et temps moyen de confinement pour des incidents passés.

    Signes d'alerte : pas d'API de révocation ou dépendance à « contacter le support » pour des révocations urgentes.

16. Comment les audits clients sont‑ils pris en charge et quelles preuves pouvez‑vous fournir ?

    Pourquoi c'est important : les auditeurs demandent des logs, des contrôles et des listes d'accès. Les fournisseurs doivent fournir des artefacts exportables et un processus pour produire des packs d'audit.

    Preuve acceptable : modèle de pack d'audit, logs exemples, rapports SOC/ISO si disponibles, et processus documenté pour les demandes ad hoc.

    Signes d'alerte : uniquement des captures d'écran du portail ou « nous pouvons le montrer en direct » sans exports.

17. Quelle télémétrie ou quels composants sont tiers (CDN, analytics) et qui possède ces données ?

    Pourquoi c'est important : les services tiers introduisent des risques de chaîne d'approvisionnement et des problèmes de résidence des données.

    Preuve acceptable : liste des tiers, flux de données montrant ce qui est envoyé à chaque fournisseur, et contrats ou DPA lorsqu'ils sont pertinents.

    Signes d'alerte : « nous utilisons des tiers » sans les nommer ni expliquer les données envoyées.

18. Comment montez‑vous en charge pour de grandes flottes et quels outils de déploiement existent ?

    Pourquoi c'est important : les grandes entreprises ont besoin de déploiement en masse, d'options MSI/PKG et de configuration à distance.

    Preuve acceptable : MSI/PKG, flags d'installation silencieuse, templates MDM, API pour le déploiement d'appareils, et exemples de débits (sessions par relais).

    Signes d'alerte : installateurs manuels uniquement ou absence de guide pour des milliers d'appareils.

19. Quels outils de debug et de diagnostic exposez‑vous aux clients ?

    Pourquoi c'est important : lorsque tout échoue vous avez besoin de logs locaux, captures de paquets et d'un moyen d'engager le support fournisseur avec des données reproductibles.

    Preuve acceptable : emplacements des logs de debug locaux, contrôles de verbosité des logs, et workflow d'upload pour le support avec exemples de logs anonymisés.

    Signes d'alerte : l'utilisateur est forcé d'exécuter des outils distants à la demande du fournisseur sans transparence.

20. Comment la facturation est‑elle mesurée et quels frais inattendus peuvent apparaître ?

    Pourquoi c'est important : facturation par appareil, par utilisateur, sessions simultanées, et frais de bande passante ou d'egress régional peuvent surprendre les acheteurs.

    Preuve acceptable : matrice tarifaire, exemple de TCO sur 3 ans pour la taille de votre flotte, et hypothèses de coût de bande passante. (Voir aussi TCO de l'accès à distance.)

    Signes d'alerte : « Contactez les ventes » pour chaque détail de tarification ou frais cachés au Go.

21. Publiez‑vous des attestations indépendantes tierces (SOC 2, ISO 27001) et quelle est leur portée ?

    Pourquoi c'est important : les rapports indépendants sont utiles mais vérifiez ce qu'ils couvrent réellement (app, infra, devops). Demandez le dernier rapport et sa portée.

    Preuve acceptable : PDF du rapport ou lettre, bridge letters, et liste des services exclus.

    Signes d'alerte : rapports anciens ou indisponibles, ou affirmations de conformité sans détail de portée.

22. Montrez‑nous une chronologie anonymisée d'un incident passé de production ou d'une panne.

    Pourquoi c'est important : les incidents réels révèlent la maturité. Vous voulez la chronologie, la cause racine, la remédiation et les leçons apprises.

    Preuve acceptable : rapport d'incident redigéré avec des étapes de remédiation concrètes et vérification des correctifs.

    Signes d'alerte : refus de partager tout historique d'incident ou n'offrir que des déclarations PR génériques.

Pourquoi le relais managé de Tenvo est le choix pragmatique par défaut

Le coût opérationnel compte. Un relais auto‑hébergé évite l'infrastructure tierce mais transfère l'astreinte, le patching, le renouvellement des certificats, la HA et les tests de basculement à votre équipe. Pour la plupart des acheteurs cela se traduit par un coût total plus élevé et une récupération plus lente. Tenvo propose des clients natifs pour macOS, Windows et Linux, un client navigateur en bêta publique et un relais géré que nous exploitons pour vous, avec des serveurs en Allemagne. Tarification : Free $0 / Lite $2.99/mo / Pro $7.99/mo. Notre relais géré supprime la charge des opérations quotidiennes ; nous le recommandons comme valeur par défaut sauf exigence écrite explicite — par ex. résidence des données, réseau air‑gapped ou politique interdisant les relais tiers — qui impose l'auto‑hébergement.

Quand vous devez exiger l'auto‑hébergement

L'auto‑hébergement est justifié uniquement pour des raisons limitées : une obligation de conformité interdisant les relais tiers, des réseaux isolés inaccessibles depuis Internet public, ou des lois strictes de résidence des données qui ne peuvent être satisfaites par un service managé. Si vous prenez cette voie, demandez l'automatisation du déploiement, un playbook de mise à jour et un runbook documenté. Pour une vision réaliste des coûts cachés, see Self‑Hosted Remote Desktop: Why, How, and What Breaks et notre analyse du coût total dans Remote access TCO.

Checklist d'évaluation et prochaines étapes

• Exécutez une preuve de concept qui sollicite les repli P2P et l'utilisation des relais, en capturant des preuves au niveau paquets et des empreintes de certificats.
• Demandez des logs redigés en masqué et un pack d'audit ; comparez les formats avec votre SIEM. Voir Remote Desktop Audit Logging pour ce que les auditeurs attendent.
• Obtenez un TCO sur 3 ans pour chaque fournisseur incluant astreinte, patching et coûts d'egress des relais ; comparez‑le au prix managé de Tenvo.
• Lisez les attestations produits et, le cas échéant, demandez une bridge letter. Si vous avez besoin d'une comparaison plus approfondie avec des fournisseurs établis, consultez Comparaison TeamViewer, Comparaison AnyDesk et Comparaison RustDesk.
• Si vous avez besoin de clauses pour les achats, convertissez les 20 questions ci‑dessus en éléments de preuve obligatoires (diagrammes, empreintes de certificats, logs) et notez les fournisseurs uniquement sur les preuves, pas sur les déclarations.

Prêt à tester un relais managé et un client natif ? Téléchargez un client et exécutez les mêmes 20 vérifications dans un pilote court : Get Tenvo.