Outil collaboratif homologué diffusion restreinte : une exigence à reformuler

Visioconférence, messagerie instantanée, partage et co-édition de documents : les outils collaboratifs font désormais circuler des informations Diffusion Restreinte (DR) au quotidien. Au moment de choisir un logiciel ou une plateforme, beaucoup d’organisations inscrivent donc la même exigence dans leur cahier des charges, celle d’un outil homologué diffusion restreinte.

Cette exigence ne peut pas être satisfaite telle quelle, car l’homologation ne s’applique pas à un produit. L’organisation la prononce pour l’ensemble de son système d’information. Un éditeur peut en revanche fournir les éléments qui permettront d’homologuer ce système, à condition qu’on les lui demande clairement.

Trois attentes derrière l’expression « outil homologué DR »

L’expression résume en trois mots des attentes de nature différente. Les distinguer permet de savoir à qui adresser chacune d’elles.

La première porte sur l’usage.

L’organisation veut pouvoir collaborer sur des informations DR sans enfreindre les règles de la Diffusion Restreinte. Dans un programme industriel de défense, par exemple, cela recouvre des situations très ordinaires :

• une revue de programme en visioconférence avec un partenaire, au cours de laquelle un document DR est partagé à l’écran ;
• un fil de messagerie où des ingénieurs commentent une spécification DR, consulté aussi depuis un téléphone ;
• un espace partagé dans lequel un sous-traitant dépose et modifie des plans.

Dans chacun de ces cas, l’information DR passe par un serveur, s’affiche sur des postes et laisse des traces. Cette attente est légitime, et la réponse tient d’abord à la façon dont l’outil sera déployé.

La deuxième porte sur la sécurité du produit.

L’acheteur veut un logiciel dont la robustesse a été vérifiée par un tiers. Cette vérification existe sous la forme d’une certification ou d’une qualification délivrée par l’ANSSI, pour un produit et une version donnés.

La troisième attente reste souvent implicite.

En exigeant un outil « homologué », l’organisation espère que le fournisseur portera une partie de la conformité. Or l’II 901 confie l’homologation à une autorité de l’organisation, pour son propre système d’information. Cette responsabilité reste donc chez l’acheteur, quel que soit le fournisseur retenu.

C’est cette troisième attente qui fait durer l’expression « outil homologué DR », mais celle-ci se heurte pourtant à un constat simple : un même outil ne présente pas les mêmes risques d’une organisation à l’autre.

Un même outil, des systèmes très différents

Une plateforme de visioconférence peut être installée sur les serveurs d’une organisation, dans un réseau fermé, pour des agents qui travaillent sur des postes dédiés. La même plateforme peut aussi être utilisée en service cloud, avec des sous-traitants qui se connectent depuis leur propre réseau.

Le logiciel est identique, mais les risques n’ont rien de comparable. Dans le second cas, les flux sortent du réseau de l’organisation, des postes qu’elle n’administre pas accèdent aux réunions et les données sont hébergées par un tiers. L’autorité d’homologation ne peut pas porter le même jugement sur ces deux systèmes.

C’est la raison pour laquelle l’homologation porte sur le système entier. Le risque naît de l’assemblage entre l’outil, son hébergement, le réseau, les postes de travail et les usages.

Les outils collaboratifs rendent cette logique plus sensible encore, parce qu’ils produisent eux-mêmes de l’information. Un historique de messagerie, les versions successives d’un document co-édité ou l’enregistrement d’une réunion reprennent des contenus DR. Ils doivent rester dans le périmètre homologué, au même titre que les documents d’origine.

L’éditeur ne prononce donc pas l’homologation, il fournit une partie de la matière du dossier.

Les éléments qu’un éditeur apporte au dossier d’homologation

Selon le guide de l’homologation de sécurité publié par l’ANSSI et la DINUM en avril 2025, le dossier réunit les choix d’architecture, l’analyse de risque, les mesures de sécurité et les risques résiduels acceptés. Pour la partie qui concerne l’outil collaboratif, l’éditeur peut apporter quatre types d’éléments :

• la description des fonctions de sécurité (contrôle des accès, gestion des droits, journalisation, chiffrement) ;
• les preuves d’évaluation indépendante, certification ou qualification de l’ANSSI ;
• les options de déploiement, sur les serveurs de l’organisation ou en service cloud ;
• une documentation d’exploitation qui aide à apprécier les risques résiduels.

Ces éléments ne servent que s’ils sont demandés de façon explicite. Encore faut-il que le cahier des charges les formule autrement que par le seul mot « homologué ».

Réécrire l’exigence du cahier des charges

Chaque formulation courante peut se traduire en une demande que le fournisseur est en mesure de prouver.

Formulées ainsi, les demandes s’adressent à tous les fournisseurs dans les mêmes termes. Leurs réponses deviennent comparables, et chacune trouve sa place dans le dossier.

Guide pratique Diffusion Restreinte

Le niveau d’exigence dépend enfin de la situation de l’organisation, c’est-à-dire de qui accède au service et depuis quel réseau. Un projet mené sur un réseau fermé n’appelle pas les mêmes garanties qu’une collaboration ouverte à des partenaires extérieurs.

Le guide « Collaborer en environnement Diffusion Restreinte » de Tixeo aide à situer son besoin parmi trois situations types et propose une checklist de questions à poser aux fournisseurs.

Téléchargez le guide Diffusion Restreinte

Du label attendu au dossier à construire

L’expression « outil homologué DR » traduit un besoin réel, celui de collaborer sur des informations sensibles en maîtrisant les risques. Elle conduit pourtant à chercher un label qui n’existe pas pour un produit. En la remplaçant par des demandes précises, l’acheteur obtient des éditeurs ce qu’ils peuvent réellement fournir. Il prépare aussi, dès la consultation, le dossier que son autorité d’homologation devra examiner.

Pour aller plus loin :

• Les normes de la Diffusion Restreinte : définition, cadre et règles

Foire aux questions

Pourquoi certains éditeurs présentent-ils leur solution comme homologuée ?

L’expression peut désigner deux réalités. Elle renvoie parfois à un système d’information homologué chez un client, dans lequel la solution est intégrée. Elle désigne aussi, par raccourci, une certification ou une qualification du produit. Dans les deux cas, il est utile de demander de quelle décision il s’agit, qui l’a prononcée et pour quel système.

L’homologation obtenue par une autre organisation vaut-elle pour la mienne ?

Une homologation vaut pour un système précis et engage l’autorité qui l’a prononcée. Elle ne se transfère donc pas d’une organisation à l’autre. Savoir qu’un outil fonctionne déjà dans un système homologué reste utile, car cela montre que l’éditeur sait fournir les éléments attendus. L’autorité de l’organisation doit toutefois se prononcer sur son propre système.

Une messagerie grand public chiffrée de bout en bout convient-elle à des échanges DR ?

Le chiffrement de bout en bout protège le contenu des messages, et c’est un atout réel. L’homologation porte cependant aussi sur les postes, les comptes, l’administration et la conservation des données. Une application installée sur des téléphones personnels, que l’organisation n’administre pas, s’intègre donc difficilement à un système homologué. Les critères de choix d’une messagerie sont détaillés dans l’article Pourquoi opter pour une messagerie instantanée chiffrée de bout en bout ?