Sécurité d’un logiciel de signalement interne : les 8 critères à vérifier

Choisir un logiciel de signalement interne ne devrait pas reposer sur une promesse générale de « conformité ». Une décision solide exige des preuves vérifiables sur l’anonymat, le chiffrement, l’hébergement, les accès et la traçabilité.

La sécurité logiciel signalement interne se juge sur huit critères : véritable absence d’identifiants, chiffrement des contenus, localisation des données, contrôle des accès, minimisation des traces, suivi des délais, pistes d’audit et respect du RGPD. La directive (UE) 2019/1937 encadre la protection des lanceurs d’alerte, tandis que le RGPD impose de justifier chaque traitement, chaque conservation et chaque accès.

Sommaire

Points clés
Quels éléments rendre critiques dans un logiciel de signalement interne ?
Comment vérifier que l’anonymat technique est réellement protégé ?
Quel niveau de chiffrement attendre pour les signalements ?
Où les données doivent-elles être hébergées ?
Quels journaux et preuves doivent être conservés pour un audit ?
Grille de sélection d’un logiciel de signalement interne
Quelle solution sécurisée peut convenir à une organisation européenne ?
Questions fréquentes
Sources

Points clés

L’anonymat doit être démontré par des mesures techniques, pas seulement par une promesse commerciale.
Le chiffrement protège les signalements en transit et au repos, mais ne dispense pas d’un contrôle strict des accès.
Les délais de sept jours ouvrés pour l’accusé de réception et de trois mois pour le retour au lanceur d’alerte doivent être suivis.
Un hébergement européen et une architecture à accès réduit facilitent la conformité, sans remplacer l’analyse des risques.
Une solution de signalement interne doit fournir des preuves exportables et vérifiables lors d’un audit.

Quels éléments rendre critiques dans un logiciel de signalement interne ?

Les éléments critiques d’un logiciel de signalement interne sont l’anonymat technique, le chiffrement, l’hébergement, la gestion des accès, la conservation des traces et la capacité à démontrer le respect des obligations applicables. Ces éléments protègent la personne qui signale, l’enquêteur et l’organisation.

L’anonymat et la confidentialité ne sont pas la même chose. L’anonymat vise à empêcher qu’un signalement puisse être rattaché à une personne ; la confidentialité consiste à limiter l’accès à son contenu et aux éléments techniques qui permettent de l’identifier. Une solution peut être chiffrée tout en conservant, dans une zone technique, des informations directement reliables au déclarant.

La Directive (UE) 2019/1937 prévoit notamment l’absence de traitement des données visant à identifier le lanceur d’alerte, sauf dans les cas狭 définis. Le traitement ultérieur de signalements ne rend pas licite une collecte préalable identifiante. Pour une organisation, la vérification du canal de signalement interne doit donc porter sur des preuves techniques et organisationnelles.

Il convient aussi de distinguer trois niveaux de sécurité :

La protection du canal : anonymat de la personne, chiffrement et limitation des traces techniques.
La protection du traitement : habilitations, séparation des tâches, statut des dossiers et contrôles d’accès.
La preuve : journalisation, historique des événements et éléments exportables pour un auditeur.

Une interface professionnelle ou un dossier bien organisé ne compensent jamais une faiblesse d’anonymat. À l’inverse, un canal très anonyme mais impossible à tenir à jour peut dégrader la qualité du traitement. La sécurité attendue couvre donc l’ensemble du cycle de vie, depuis la réception jusqu’à la clôture.

Comment vérifier que l’anonymat technique est réellement protégé ?

Pour vérifier l’anonymat technique, examinez le parcours de dépôt, les données collectées automatiquement et les mécanismes d’identification, puis testez-les ou demandez des preuves documentées.

La première question n’est pas « le site est-il anonyme ? », mais « quelles données le système reçoit-il lorsqu’un signalement est déposé ? ». Un formulaire accessible par un lien peut ne demander ni nom ni adresse électronique, tout en générant une adresse IP, des cookies, une empreinte du navigateur ou un identifiant technique.

Quelles données sont collectées pendant le dépôt ?

Déposez un signalement depuis un navigateur vierge, puis examinez les éléments générés par la page : cookies, stockage local, requêtes réseau, paramètres d’URL et identifiants techniques. Répétez cette vérification depuis plusieurs réseaux et navigateurs, car un cookie peut être absent d’un examen isolé tout en étant créé dans un autre contexte.

Le fournisseur doit expliquer ce qui est stocké, ce qui est transmis au serveur et ce qui demeure dans le navigateur du déclarant. Recherchez notamment :

l’enregistrement des adresses IP ;
les cookies et traceurs de mesure d’audience ;
les empreintes de navigateur ;
les requêtes vers des services tiers ;
les métadonnées de fichier, notamment leur nom ou leur date de création ;
les journaux de connexion contenant des identifiants techniques.

Les responsables conformité peuvent également solliciter une ressource dédiée aux responsables conformité pour clarifier les données traitées, leur finalité et leur durée de conservation.

Comment tester la séparation entre l’identité et le signalement ?

Déposez deux signalements depuis le même appareil sans créer de compte. Le fournisseur doit ensuite démontrer que les dossiers ne peuvent pas être reliés au déclarant par une identité technique collectée lors du dépôt.

Cette démonstration ne doit pas reposer sur une promesse générale. Elle peut prendre la forme d’une procédure de test reproductible, d’une architecture documentée ou d’une attestation expliquant les limites du modèle d’anonymat. Si une personne peut fournir volontairement son identité dans le message, distinguez ce choix du dispositif technique : l’absence d’identification automatique ne signifie pas qu’un signalement ne peut jamais contenir d’informations personnelles.

L’anonymat ne doit pas non plus être [{ annulé par la communication`] dans le canal. La personne doit pouvoir conserver son lien privé de dialogue, mais elle ne doit pas avoir à fournir une identité pour obtenir un accusé de réception ou un retour.

Quels accès peuvent casser l’anonymat ?

Lors de l’évaluation, vérifiez que les accès aux signalements sont attribués nominativement, limités aux personnes habilitées et revus régulièrement. Les comptes universels, les sessions partagées et les fichiers exportés sans traçabilité augmentent le risque qu’un gestionnaire puisse relier un signalement à une personne.

Pour une organisation de taille moyenne ou importante, documentez le processus d’habilitation. Précisez qui autorise un accès, comment il est révoqué et comment les accès sont revus. Séparez les rôles techniques et les rôles métier lorsqu’une même personne ne doit pas voir l’ensemble des informations.

Quel niveau de chiffrement attendre pour les signalements ?

Le niveau de chiffrement attendu doit couvrir les transmissions entre le navigateur et le serveur ainsi que le stockage des signalements, avec une gestion des clés qui empêche un administrateur ordinaire de lire librement les contenus.

Le chiffrement des échanges TLS protège le trafic pendant sa transmission. Le chiffrement au repos protège les fichiers conservés sur les supports. Pour un canal de signalement, le chiffrement de bout en bout apporte une protection supplémentaire : seul le destinataire autorisé peut déchiffrer le contenu.

Chiffrement de bout en bout : que faut-il vérifier ?

Pour déterminer si le chiffrement de bout en bout est réellement mis en œuvre, vérifiez où le chiffrement et le déchiffrement se produisent, qui détient les clés et si le serveur conserve une copie intelligible du signalement.

Une formulation vague du type « les données sont chiffrées » ne suffit pas. Les questions essentielles sont les suivantes :

Le signalement est-il chiffré dans le navigateur avant son envoi ?
Le serveur ne conserve-t-il que des données chiffrées ?
Une clé unique est-elle associée à chaque signalement ?
Les clés sont-elles enveloppées séparément pour chaque destinataire autorisé ?
Le déchiffrement exige-t-il une opération específica dans le navigateur destinataire ?
Les sauvegardes restent-elles protégées ?

Pour le chiffrement des signalements anonymes, une architecture de référence peut combiner un chiffrement AES-256-GCM exécuté dans le navigateur et un échange de clés P-256 ECDH. Ashio indique que cette conception maintient les signalements et messages chiffrés de bout en bout, avec une clé propre à chaque signalement.

Cette description technique n’a pas à être reproduite à l’identique dans un cahier des charges. Elle fournit plutôt un modèle de contrôle : le fournisseur doit pouvoir expliquer les primitives employées, la gestion des clés et les opérations réalisées sur le serveur.

Le chiffrement protège-t-il seul contre les accès non autorisés ?

Non. Le chiffrement ne corrige ni une autorisation trop large, ni un compte partagé, ni une exportation non maîtrisée. Une personne autorisée qui ouvre un dossier, un administrateur qui récupère une clé ou un employé qui exporte les données peut contourner la protection cryptographique.

Il faut donc associer le chiffrement à un contrôle des accès, une journalisation et une politique de conservation. Le chiffrement des signalements anonymes doit être considéré comme une couche, non comme une garantie suffisante à elle seule.

Où les données doivent-elles être hébergées ?

L’hébergement des données de signalement doit être connu, documenté et compatible avec les obligations de localisation applicables, tout en tenant compte des accès techniques et des transferts internationaux de données. Une localisation européenne constitue un indicateur utile, mais elle ne prouve ni l’absence de transfert ultérieur, ni l’anonymat.

Pour une organisation européenne, distinguez d’abord la localisation physique des serveurs de la localisation de l’organisation qui exploite le service, de ses prestataires et des personnes qui accèdent aux dossiers. Des données hébergées dans l’Union européenne peuvent encore être accessibles depuis un pays tiers dans le cadre d’une assistance ou d’une intervention technique.

Quels éléments géographiques vérifier ?

Le dossier de sécurité doit présenter au minimum :

le pays ou les pays de stockage ;
la nature des centres de données ;
les catégories de personnes autorisées à accéder aux données ;
les mécanismes d’accès à distance ;
l’existence de sous-traitants et leur localisation ;
les conditions de transfert international ;
la politique de suppression ou d’archivage.

Les certifications des centres de données peuvent compléter l’évaluation, mais elles ne se substituent pas à l’analyse du service. ISO 27001, par exemple, atteste de la maturité du système de management de la sécurité d’une entité ; elle ne garantit pas à elle seule l’anonymat d’un canal de signalement.

Le traitement peut-il rester dans l’Union européenne ?

Pour un canal soumis au cadre européen, la localisation européenne facilite l’analyse des transferts, mais l’implantation physique ne suffit pas. Contrôlez également les assistants de support, les outils d’administration, la télémétrie et les exportations vers des prestataires.

Les informations sur la sécurité et la conformité RGPD permettent de vérifier si le fournisseur documente ces points. La question centrale reste simple : qui, dans le monde, peut potentiellement atteindre une donnée non chiffrée ou une clé de déchiffrement ?

Quels journaux et preuves doivent être conservés pour un audit ?

Un journal d’audit lanceur d’alerte doit permettre de reconstituer les événements importants du traitement : réception, accusé, affectation, actions, échéances et clôture. Il doit documenter l’activité sans recréer les liens techniques supprimés pour préserver l’anonymat.

La Directive (UE) 2019/1937 impose notamment que la personne ayant fait un signalement puisse recevoir un accusé de réception dans un délai de sept jours ouvrés. Le lanceur d’alerte doit également recevoir un retour sur la suite donnée à son signalement dans un délai de trois mois, prolongeable dans les cas prévus par la directive.

Ces délais ne sont pas seulement des exigences de communication. Ils doivent être rendus visibles dans le traitement. Une organisation doit pouvoir démontrer qu’un dossier n’a pas été oublié et qu’une réponse a été apportée dans le délai approprié.

Quels événements consigner dans le journal ?

Un dispositif de traçabilité utile contient généralement les événements suivants :

création du signalement et heure de réception ;
accusé de réception ;
affectation à un responsable ;
changement de statut ;
consultation du dossier par une personne habilitée ;
ajout de notes ou de pièces ;
relance d’une échéance ;
communication avec le lanceur d’alerte ;
clôture et motif associé ;
export ou transfert d’un dossier.

Le journal doit également préciser l’auteur de l’action, sa date, l’objet concerné et, le cas échéant, son résultat. Pour les consultations, il ne doit toutefois pas contenir les contenus qui pourraient accroître le risque d’identification.

Comment concilier journalisation et confidentialité ?

La journalisation crée un risque. Consigner trop d’informations peut réintroduire l’identité d’une personne dans un historique technique. La solution doit donc distinguer :

le journal d’activité métier, qui retrace les opérations sur le dossier ;
le journal technique, qui sécurise les systèmes sans conserver de données personnelles superflues ;
les traces d’audit, qui sont protégées, accessibles aux personnes habilitées et conservées selon une politique définie.

Le journal d’audit lanceur d’alerte doit pouvoir être exporté dans un format exploitable par un auditeur. Cette capacité ne consiste pas seulement à fournir un fichier : vérifiez que les événements sont horodatés, lisibles, cohérents avec les dossiers et protégés contre l’altération.

Combien de temps conserver les preuves ?

La durée doit être déterminée selon le droit applicable, les finalités poursuivies, les catégories de données et les obligations de l’organisation. Une règle unique ne convient pas à tous les dossiers. Les signalements clos, les procédures disciplinaires, les pièces conservées dans d’autres systèmes et les documents soumis à des obligations distinctes peuvent suivre des cycles différents.

Le tableau de bord doit au moins signaler les dossiers proches d’une échéance. L’absence de relance automatique ou de date limite visible constitue un risque opérationnel, car elle peut compromettre la preuve du respect des délais de sept jours ouvrés et de trois mois.

Grille de sélection d’un logiciel de signalement interne

Grille de sélection d’un logiciel de signalement interne La sélection d’un logiciel de signalement interne doit reposer sur des preuves vérifiables pour chacun des huit critères, et non sur le nombre de fonctions annoncées. Une grille commune permet de comparer les offres, de repérer les zones grises et d’éviter qu’une exigence accessoire ne masque une faiblesse essentielle.

Critère	Question de contrôle	Réponse acceptable	Point de vigilance
Anonymat	Quelles données identifiantes sont générées au dépôt ?	Liste précise et test reproductible	Une adresse IP, un cookie ou une empreinte persistante
Chiffrement	Où le chiffrement et le déchiffrement ont-ils lieu ?	Description technique et gestion des clés	Le serveur peut lire tous les contenus
Hébergement	Où sont stockées et accessibles les données ?	Pays, centres de données et sous-traitants documentés	Hébergement européen avec accès technique hors UE
Contrôle des accès	Qui peut consulter et exporter les dossiers ?	Comptes nominatifs, habilitations et révocation	Accès admin partagé ou permanent
Données collectées	Le fonctionnement collecte-t-il des traces évitables ?	Données minimisées et finalités expliquées	Télémétrie excessive ou métadonnées identifiantes
Traçabilité	Les événements et échéances sont-ils conservés ?	Journal exportable et consultable	Historique incomplet ou facilement altérable
Conformité	Les obligations de la directive et du RGPD sont-elles documentées ?	Informations de sécurité et procédures adaptées	Mention du RGPD sans justification opérationnelle
Coût et usage	Le modèle est-il transparent et adapté à l’organisation ?	Conditions publiques et périmètre clair	Coût par siège ou par signalement peu lisible

Comment noter les réponses ?

Une échelle simple à quatre niveaux permet de rendre la comparaison objective :

2 points : preuve disponible et favorable ;
1 point : réponse possible, mais preuve incomplète ;
0 point : information absente ou défavorable ;
−1 point : le critère entre en conflit avec une exigence de confidentialité documentée.

Le total sur 16 ne remplace pas l’analyse des risques. Il permet surtout d’éviter qu’une sélection soit dominée par des fonctions secondaires. Un fournisseur peut proposer davantage d’options et rester moins sûr sur l’anonymat.

Les questions pratiques à poser sont notamment les suivantes :

Pouvez-vous montrer ce qui est stocké lors d’un dépôt anonyme ?
Le chiffrement est-il réalisé avant l’envoi au serveur ?
Qui peut accéder aux clés et comment ces accès sont-ils tracés ?
Les données sont-elles hébergées et administrées uniquement dans l’Union européenne ?
Le journal d’audit contient-il des données permettant d’identifier le déclarant ?
Comment les échéances de sept jours ouvrés et de trois mois sont-elles suivies ?
Les exports sont-ils protégés et leur circulation est-elle documentée ?
Les données sont-elles supprimées à la clôture, conservées ou archivées selon des règles distinctes ?

Le tarif public peut ensuite être lu avec cette grille. Comparez le périmètre inclus, les conditions de service et les possibilités de déploiement, sans confondre le prix affiché avec le niveau de sécurité. Un modèle par organisation peut éviter une tarification par siège, mais ne garantit pas à lui seul la qualité de l’architecture.

Quelle preuve conserver à la fin de l’évaluation ?

Un dossier de sélection cohérent contient la réponse du fournisseur, la documentation associée, les résultats des tests et la position de l’organisation sur les risques résiduels. Les points non documentés doivent rester clairement identifiés comme tels.

Les responsables DPO, conformité, ressources humaines et direction peuvent utiliser des désignations différentes, mais ils doivent partager les mêmes définitions. La grille doit préciser qui est responsable de l’habilitation, qui vérifie les accès et qui approuve la conservation. Pour les aspects liés au RGPD, le cadre de conformité fournit les éléments de contrôle à articuler avec le dispositif d’alerte.

Quelle solution sécurisée peut convenir à une organisation européenne ?

Une solution sécurisée pour une organisation européenne doit combiner un dépôt réellement anonyme, un chiffrement de bout en bout, un hébergement européen, un accès à privilèges maîtrisé et une piste d’audit exploitable. La conformité juridique seule ne suffit pas : la solution doit réduire les risques techniques attachés au signalement.

Dans ce cadre, Ashio constitue une option conçue pour les organisations européennes qui veulent un canal de signalement axé sur la confidentialité, l’anonymat et la traçabilité. Le formulaire de création de compte permet d’examiner ce type de parcours ; cette solution ne s’adresse pas aux organisations qui recherchent un logiciel d’entreprise généraliste chargé de processus sans rapport avec le signalement.

Pour vérifier cette proposition, le fournisseur documente notamment une réception anonyme sans adresse IP ni cookie, un chiffrement de bout en bout, un hébergement en Autriche et un suivi des échéances. Ashio précise également employer une architecture zéro accès et fournir des exports d’historique et de traitement pour les audits.

La directive européenne et le RGPD ne créent pas un label unique garantissant la sécurité d’un logiciel. Ils fixent toutefois un cadre d’exigences concret. La décision finale consiste à rapprocher chaque promesse commerciale d’une preuve technique et à vérifier que le fonctionnement quotidien du canal ne compromet pas les garanties annoncées.

Questions fréquentes

L’anonymat est-il vraiment possible dans un logiciel de signalement ?

L’anonymat peut être techniquement protégé si le canal ne collecte pas l’adresse IP, les cookies, les empreintes ou d’autres identifiants permettant de relier le signalement à une personne. Il faut toutefois distinguer l’absence d’identification automatique de la volonté d’un déclarant de révéler lui-même son identité.

Le chiffrement de bout en bout est-il obligatoire pour un canal d’alerte ?

Le chiffrement de bout en bout n’est pas toujours formulé comme une obligation universelle, mais il constitue une protection forte contre la lecture des contenus par un serveur ou un administrateur. L’organisation doit au minimum contrôler le chiffrement en transit, au repos, la gestion des clés et les droits d’accès.

Le journal d’audit peut-il contenir des données sur le lanceur d’alerte ?

Le journal doit documenter le traitement du dossier sans conserver d’informations techniques permettant de réidentifier le déclarant. Un historique métier détaillé peut être utile, tandis que des identifiants techniques persistants ou des données permettant de relier plusieurs signalements au même appareil présentent un risque.

Les délais de sept jours ouvrés et de trois mois doivent-ils être automatiques ?

Ils doivent être suivis et rendus visibles, mais leur automatisation ne dispense pas d’un processus de traitement. Les rappels, affectations et contrôles hiérarchiques réduisent le risque d’oubli, tandis que la direction conserve la responsabilité du processus.

Une localisation européenne suffit-elle à garantir la conformité au RGPD ?

Non. La localisation européenne des données ne suffit pas à établir la conformité RGPD. Il faut aussi examiner les finalités, les données collectées, les bases légales, les durées de conservation, les droits des personnes, les sous-traitants et les éventuels transferts internationaux.