Les listes de confiance européennes interviennent dans la vérification des services utilisés pour la signature électronique. Elles sont peu visibles pour l’utilisateur, mais leur exploitation compte pour les logiciels qui évaluent des certificats et des signatures. Leur évolution vers le format TLv6 mérite donc une place dans la veille des équipes documentaires et techniques.
La décision d’exécution européenne de 2025 qui actualise leurs spécifications s’applique depuis le 29 avril 2026. À la date de vérification de cet article, le 20 octobre 2026, il s’agit d’un changement déjà applicable, et non d’une échéance à venir. Voici comment en comprendre la portée et préparer une discussion utile avec son fournisseur.
À quoi servent les listes de confiance ?
Les États membres publient des informations sur les prestataires de services de confiance qualifiés dont ils sont responsables et sur les services qualifiés fournis. La décision 2015/1505 encadre ces listes et leurs formats. Source : texte consolidé de la décision 2015/1505.
Pour un acheteur, la question utile ne se limite donc pas à reconnaître le nom commercial d’un éditeur. Il faut identifier le service mobilisé dans le parcours étudié et les éléments sur lesquels repose sa vérification. Demandez une explication correspondant à votre offre et à votre usage, plutôt qu’une simple présentation générale du fournisseur.
Qu’est-ce qui a changé avec TLv6 ?
La décision d’exécution (UE) 2025/2164 du 27 octobre 2025 modifie la version de la norme sur laquelle repose le modèle commun des listes. Son article 2 fixe l’application au 29 avril 2026. Source : décision officielle publiée sur EUR-Lex.
La page officielle DSS de la Commission rattache cette évolution au format Trusted List v6 et à ETSI TS 119 612 v2.4.1. Elle invite les intégrateurs à vérifier leur compatibilité : une version inadaptée peut perturber l’accès aux listes ou leur validation. Source : information de la Commission sur la migration TLv6.
Ces textes ne permettent pas, à eux seuls, de conclure qu’un document reçu est valide ou invalide. Il faut examiner ce document et les résultats du processus de validation applicable.
Qui doit vérifier quoi ?
Si vous utilisez une plateforme hébergée, demandez au fournisseur comment il prend en charge l’évolution des listes et comment il suit les incidents de validation. Votre objectif est d’obtenir une réponse documentée, rattachée au service utilisé.
Si votre organisation exploite un validateur interne ou une application intégrant une bibliothèque de signature, faites identifier le composant, sa version, sa configuration et son responsable de maintenance. La mention d’une bibliothèque connue dans un dossier d’architecture ne renseigne pas sur la version effectivement déployée.
Les petites structures peuvent commencer par une question simple : « Qui est responsable de la validation des signatures que nous recevons, et où conservons-nous ses résultats ? »
Les questions à transmettre à son fournisseur
Voici une trame de vérification opérationnelle, à adapter au contexte :
- Quelle version du composant traite les listes de confiance ?
- La compatibilité TLv6 a-t-elle été testée dans notre environnement ?
- Comment les listes sont-elles actualisées et les erreurs signalées ?
- Quels rapports permettent de comprendre une validation incomplète ?
- Qui examine une anomalie et dans quel délai ?
- Comment tester un changement avant sa mise en production ?
Demandez des éléments observables : référence de version, compte rendu de test et exemple de rapport anonymisé. Un échange sur ces preuves sera plus utile qu’une réponse générale sur la conformité.
Organiser une veille qui reste exploitable
Tenez un registre court des changements : source officielle, date d’application, composant concerné, responsable et vérification réalisée. Distinguez la publication d’un texte, son application et la livraison d’une mise à jour logicielle. Ces événements peuvent avoir des calendriers différents.
Pour les contrôles à réception d’un fichier, poursuivez avec notre guide de vérification d’une signature PDF. Pour le cadre général, consultez notre présentation du règlement eIDAS.
Cet article apporte des repères documentaires et techniques. L’analyse d’une obligation précise doit tenir compte du service et de l’usage concernés.
