Décret 2018-062 et Kubernetes : le gap entre le texte et l'implémentation

Une plateforme de calcul qui héberge des données togolaises doit respecter un corpus juridique précis : la loi 2017-007 sur les transactions électroniques, son Décret d'application 2018-062, la loi 2019-014 sur la protection des données à caractère personnel, et les règles de cybersécurité de l'Arrêté 2022-040 pris par l'ANCY. Le problème n'est pas que ces textes soient laxistes. Le problème est qu'ils ont été écrits avec une image en tête : un serveur physique dans un datacenter, ou au mieux une machine virtuelle avec une adresse, un disque, un emplacement. Kubernetes ne fonctionne pas comme ça. Un pod naît, meurt et renaît ailleurs en quelques secondes. Un volume est provisionné à la demande par un pilote CSI et peut changer de zone. Un « Operator » n'est pas une entreprise, c'est un bout de code qui réconcilie un état désiré.

Cet article regarde ce décalage de face. Pour chaque obligation pertinente, je cherche son équivalent Kubernetes natif, puis j'isole les endroits où l'équivalence casse. L'angle est juridico-technique, pas un how-to : le lecteur visé est autant un juriste data protection qu'un ingénieur plateforme. Une précision utile d'emblée : ceci est une analyse d'ingénierie, pas un conseil juridique. Et une seconde, plus subtile : le Décret 2018-062 vise en premier lieu les prestataires de services de confiance (signature, certification, horodatage, archivage électronique). J'assume ici une lecture extensive, en traitant ses obligations comme un référentiel raisonnable pour toute plateforme qui héberge et traite des données, tout en signalant à chaque fois où cette extension est une interprétation et non la lettre du texte.

Un texte écrit pour le serveur, pas pour le pod

Il faut nommer précisément le décalage de modèle mental, parce que c'est lui qui crée tous les gaps qui suivent.

Le droit raisonne en termes d'entités stables et localisables. Un prestataire est « établi sur le territoire national » (Décret 2018-062, art. 58). Des données sont « conservées » pendant une durée. Un prestataire dispose d'un « plan d'arrêt d'activité » (art. 58). Toutes ces notions supposent implicitement qu'il existe un lieu, un serveur, un actif que l'on peut pointer du doigt et auditer.

Kubernetes dissout ces points d'ancrage. Le pod est éphémère par conception : le scheduler le place sur un nœud selon la capacité disponible à l'instant t, le tue quand une sonde de vivacité échoue, et en recrée un ailleurs. L'adresse IP change à chaque redémarrage. Le stockage se scinde en deux : l'éphémère, qui disparaît avec le pod, et le persistant, qui vit dans un PersistentVolume dont l'emplacement physique dépend du provisionneur. La responsabilité se répartit entre l'équipe applicative, l'équipe plateforme, et le fournisseur du cluster managé. Il n'y a plus un serveur : il y a un état désiré et une boucle de réconciliation.

Le texte n'a pas prévu cette abstraction. Ce n'est pas un reproche fait au législateur de 2018, c'est un constat : la conformité ne consiste plus à cocher « le serveur est au Togo », elle consiste à reconstruire, au-dessus d'une infrastructure mouvante, les garanties que le texte supposait acquises par la stabilité du matériel.

Les obligations réelles, article par article

Avant de cartographier, il faut être exact sur ce que les textes disent vraiment, car plusieurs intuitions courantes sont fausses.

Traçabilité et journalisation. L'article 41 du Décret 2018-062 impose aux prestataires de conserver « au moins pendant une durée d'un an » les données permettant d'identifier qui a contribué à un contenu. Le texte cite explicitement « l'adresse IP des points de connexion à distance » et « la trace horodatée des sessions ouvertes pour chaque service utilisé ». L'Arrêté 2022-040 renforce cela pour les opérateurs de services essentiels avec un contrôle dédié à la journalisation des événements (D1.1.1).

Sécurité. L'article 44 du décret demande de « protéger les données transmises contre tout accès non autorisé ». L'article 52 va plus loin : « mesures techniques et organisationnelles adéquates pour gérer les risques », d'un niveau « proportionné au degré de risque », avec notification de tout incident de sécurité « dans un délai de vingt-quatre heures » à l'organe de contrôle et, le cas échéant, à l'autorité chargée de la protection des données. C'est une obligation de moyens proportionnés, pas une liste de contrôles techniques figés.

Protection des données personnelles. L'article 50 du décret renvoie explicitement à la loi 2019-014 : le stockage et le traitement des données à caractère personnel s'effectuent « dans le respect de la protection des données à caractère personnel ». La loi 2019-014 définit le responsable du traitement, le sous-traitant, et l'Instance de protection des données à caractère personnel qui contrôle. Son article 20 impose que le sous-traitant apporte « des garanties suffisantes », soit lié par un contrat écrit, et n'agisse que « sur la seule instruction du responsable du traitement ». Son article 19 pose le principe de confidentialité et de sécurité.

Continuité. L'article 58 du décret exige que les enregistrements pertinents soient « accessibles pour une durée de douze mois ... aux fins notamment de ... assurer la continuité du service », et que le prestataire dispose « d'un plan actualisé d'arrêt d'activité permettant d'assurer la continuité du service et vérifié par l'organe de contrôle ». L'Arrêté 2022-040 en fait un domaine entier, la résilience des activités (R1).

Intégrité et réversibilité. L'article 69 du décret, sur l'archivage, demande d'empêcher « toute modification des données conservées », de « détecter les opérations, normales ou frauduleuses », et de « permettre l'identification des auteurs de telles opérations », le tout horodaté et accessible aux seules personnes autorisées. L'article 71 impose la réversibilité : à la demande, restituer, transférer à un autre prestataire, ou détruire définitivement les données.

Localisation. C'est ici que l'intuition est la plus trompeuse. Le Décret 2018-062 n'impose pas une résidence des données sur le sol togolais. Il ancre l'établissement du prestataire « sur le territoire national » (art. 58) et le contrôle territorial de l'organe de régulation. La contrainte de localisation réelle vient d'ailleurs : l'article 28 de la loi 2019-014 encadre le transfert de données à caractère personnel « vers un pays tiers », qui n'est permis que si cet État « assure un niveau de protection suffisant » et après information préalable de l'Instance qui rend un avis motivé. La question n'est donc pas « les données sont-elles au Togo », mais « les données franchissent-elles une frontière vers un pays inadéquat, et l'ai-je déclaré ».

Chiffrement au repos. Aucun de ces textes n'écrit noir sur blanc « chiffrement des données au repos ». Le décret parle de protéger « contre tout accès non autorisé » (art. 44) et de mesures « proportionnées au risque » (art. 52). L'Arrêté 2022-040 a un contrôle sur la réglementation du contrôle cryptographique (G3.1.5), mais formulé par renvoi : les contrôles cryptographiques « doivent être utilisés conformément aux lois et règlements pertinents ». Le chiffrement au repos est donc une exigence implicite, déduite de l'obligation de sécurité, jamais une prescription littérale.

Cartographie : chaque obligation et son équivalent Kubernetes

Pour une bonne partie de ces obligations, Kubernetes offre une réponse native. C'est important à établir avant de parler des gaps, parce que la plateforme n'est pas en faillite de conformité : elle couvre naturellement plusieurs exigences.

Sur le papier, la couverture est correcte. Les audit logs répondent au besoin de trace, les PodDisruptionBudget et l'anti-affinité répondent au besoin de continuité, RBAC et NetworkPolicy matérialisent la sécurité proportionnée. Un ingénieur plateforme peut légitimement dire « Kubernetes sait faire tout ça ». Le piège, c'est que cette couverture est vraie au niveau de l'infrastructure et fausse au niveau de la donnée. C'est exactement là que se logent les gaps.

Les vrais gaps

Un gap, ici, n'est pas une fonctionnalité manquante de Kubernetes. C'est un endroit où la réponse native de l'outil ne recouvre pas l'obligation juridique, parce que les deux ne parlent pas du même objet. Le texte parle de données identifiées et localisées ; Kubernetes répond au niveau des ressources et des API. Voici les quatre décalages qui comptent.

Résidence des données contre stockage éphémère et volumes dynamiques

L'article 28 de la loi 2019-014 fait dépendre la légalité d'un transfert de la destination géographique des données. Or Kubernetes est conçu pour rendre cette destination fluide.

Un PersistentVolume est provisionné par une StorageClass, elle-même adossée à un pilote CSI qui parle au backend de stockage réel. Dans un cluster managé chez un hyperscaler, ce backend est un service régional : le volume vit dans une zone, et selon la configuration, la réplication de ce service peut copier les blocs vers une autre région pour la durabilité. Rien dans le manifeste applicatif ne rend cette géographie visible. Un développeur qui écrit storageClassName: standard ne sait pas, et n'a aucune raison de savoir, dans quel pays atterrissent physiquement ses octets.

Le stockage éphémère aggrave le flou. Les fichiers temporaires, les caches, les emptyDir vivent sur le disque du nœud qui héberge le pod à cet instant. Le scheduler choisit ce nœud dynamiquement. Si le pool de nœuds s'étend sur plusieurs zones, voire plusieurs régions dans les architectures les plus élastiques, une donnée personnelle peut transiter par un nœud situé hors du périmètre déclaré, le temps d'un traitement, sans qu'aucune trace applicative ne le consigne.

Le gap est double. D'abord, le texte n'a jamais défini la résidence des données pour un système où la donnée n'a pas de lieu fixe : il présumait la stabilité du serveur. Ensuite, même si l'on interprète l'article 28 comme s'appliquant à ces mouvements, Kubernetes ne fournit aucun mécanisme natif qui déclare, contrôle et journalise le franchissement de frontière au niveau de la donnée. La topologySpreadConstraints ou le nodeAffinity peuvent contraindre le placement, mais ce sont des outils d'ordonnancement, pas des garanties de conformité auditable.

Traçabilité des accès aux données personnelles en multi-tenant

L'article 41 du décret veut la trace horodatée des accès, et l'article 69 veut « l'identification des auteurs » des opérations sur les données. L'audit log du kube-apiserver semble répondre. Il ne répond qu'à moitié.

L'audit du serveur d'API journalise les actions sur les objets Kubernetes : qui a créé un pod, modifié un Secret, listé les ConfigMaps. C'est une trace au niveau du plan de contrôle. Mais l'obligation juridique porte sur l'accès aux données à caractère personnel, qui se produit au niveau applicatif, à l'intérieur du conteneur, quand le code lit une ligne dans une base ou un objet dans un bucket. Cet accès-là est invisible pour l'audit de l'API : Kubernetes ne voit pas les requêtes SQL que fait votre application.

Le multi-tenant brouille encore l'imputabilité. Dans un cluster partagé, l'isolation passe par les namespaces, mais plusieurs équipes, plusieurs applications, parfois plusieurs clients cohabitent. Les identités techniques, les ServiceAccounts, sont partagées entre les réplicas d'un même déploiement : quand trois pods d'un même service accèdent à des données, ils présentent la même identité. Un service mesh qui ajoute des sidecars, un pooler de connexions qui mutualise les accès à la base sous une seule identité de service, et la chaîne entre l'utilisateur humain et l'octet lu se rompt. La trace existe, mais elle s'arrête à la frontière du cluster ou à l'identité de service, là où le juriste attend l'identification d'un auteur.

Le gap : la traçabilité native de Kubernetes est une traçabilité d'infrastructure. La traçabilité exigée par les articles 41 et 69 est une traçabilité de la donnée. Combler l'écart demande de l'instrumentation applicative que la plateforme ne fournit pas d'elle-même.

« Opérateur » juridique contre Operator Kubernetes

Le mot « opérateur » est un faux ami parfait, et le télescopage est plus qu'une curiosité de vocabulaire.

Au sens juridique, l'opérateur ou le prestataire est une personne, physique ou morale, qui porte des obligations et une responsabilité. L'article 47 du décret rend le prestataire « responsable des dommages causés intentionnellement ou par négligence », et présume même cette responsabilité pour un prestataire qualifié. La loi 2019-014 distingue le responsable du traitement, qui décide, et le sous-traitant, qui exécute sur instruction (art. 20). Ce sont des rôles imputables.

Au sens Kubernetes, un Operator est un pattern logiciel : un controller associé à une ou plusieurs CustomResourceDefinition, qui observe l'état du cluster et le réconcilie vers un état désiré. Un Operator de base de données peut, de sa propre initiative, décider de faire un failover, de restaurer un backup, de supprimer et recréer un volume, de déplacer une charge d'un nœud à un autre. Autrement dit, du code prend des décisions qui touchent des données personnelles, sans intervention humaine, sur la base d'une boucle de réconciliation.

Le gap est un vide d'imputabilité. Quand un Operator déclenche une restauration qui écrase des données, ou un rééquilibrage qui déplace un volume vers une zone non prévue, qui est le responsable au sens de l'article 47 ? L'éditeur de l'Operator ? L'équipe qui l'a déployé ? L'organisation qui exploite le cluster ? Le droit suppose une chaîne de responsabilité entre des personnes ; Kubernetes insère un agent autonome dans cette chaîne, et le texte n'a pas de case pour lui. Ce n'est pas un problème que l'on résout avec un manifeste : c'est un problème de gouvernance qu'il faut expliciter par contrat et par documentation.

Chiffrement au repos : etcd, Secrets et volumes

L'obligation de protéger les données « contre tout accès non autorisé » (art. 44) se heurte à un défaut de configuration bien connu de Kubernetes.

Trois surfaces méritent l'attention. D'abord etcd, le magasin clé-valeur qui contient tout l'état du cluster, y compris les Secrets. Par défaut, selon la distribution, etcd peut stocker ces données sans chiffrement au niveau applicatif : quiconque accède au disque ou à une sauvegarde d'etcd lit les Secrets en clair. Ensuite les Secrets Kubernetes eux-mêmes, dont le nom prête à confusion : un Secret n'est pas chiffré, il est encodé en base64, ce qui n'offre aucune confidentialité. Enfin les PersistentVolumes, dont le chiffrement dépend entièrement du backend de stockage et de sa configuration, pas de Kubernetes.

Le gap ici est double : côté droit, l'obligation de chiffrement au repos est implicite, déduite de l'article 44 et du contrôle cryptographique G3.1.5 de l'Arrêté 2022-040, jamais énoncée comme telle ; côté outil, le comportement par défaut ne satisfait pas cette obligation implicite. La rencontre des deux flous produit un risque réel : une organisation peut croire ses Secrets protégés parce qu'ils s'appellent « Secrets », et se trouver en défaut d'une obligation qu'aucun texte n'a formulée explicitement mais que tout auditeur sérieux exigera.

Patterns d'implémentation pour combler les gaps

L'analyse n'a de valeur que si elle débouche sur des réponses. Voici, gap par gap, des patterns pour reconstruire au-dessus de Kubernetes les garanties que le texte supposait acquises. L'objectif reste conceptuel : ce sont des directions, pas des recettes de déploiement.

Ancrer la résidence des données. Contraindre le placement avec nodeAffinity et topologySpreadConstraints pour maintenir les charges qui traitent des données personnelles dans des zones cartographiées. Choisir des StorageClass dont on connaît et documente la géographie physique, en désactivant la réplication interrégionale non désirée. Surtout, tenir un registre de traitement qui déclare, pour chaque volume et chaque flux, où les données résident et vers quels pays elles peuvent transiter, afin de rendre l'article 28 vérifiable au lieu de subi.

Rendre la traçabilité applicative. Compléter l'audit du serveur d'API par une journalisation au niveau de la donnée : la base de données journalise les accès, l'application émet des événements d'accès aux données personnelles avec une identité d'utilisateur réelle, pas seulement une identité de service. Éviter la mutualisation aveugle des identités : propager l'identité de l'utilisateur de bout en bout plutôt que de la dissoudre dans un pool de connexions. Un moteur de politique comme OPA Gatekeeper peut imposer que les charges qui touchent des données sensibles portent les labels et l'instrumentation requis.

Expliciter la responsabilité des Operators. Traiter chaque Operator autonome comme un maillon de la chaîne de responsabilité et le documenter comme tel : quel Operator peut agir sur quelles données, avec quelles permissions RBAC minimales, sous la responsabilité de quelle équipe. Restreindre les actions destructrices, exiger des garde-fous pour les opérations qui déplacent ou effacent des données, et consigner ces décisions dans le registre de gouvernance. Le pattern n'est pas technique, il est organisationnel : redonner un nom humain à chaque action automatique.

Chiffrer au repos, explicitement. Activer l'EncryptionConfiguration du serveur d'API pour chiffrer les Secrets dans etcd, idéalement adossée à un KMS externe plutôt qu'à une clé locale. Traiter les Secrets Kubernetes comme un mécanisme de distribution, pas de protection, et envisager un gestionnaire de secrets dédié ou des sealed secrets. Activer le chiffrement au niveau du backend de stockage pour les PersistentVolumes. Documenter ces choix pour transformer une obligation implicite en preuve auditable.

Limites de l'analyse et questions ouvertes

Cette analyse repose sur une extension que je dois assumer clairement. Le Décret 2018-062 vise en premier lieu les prestataires de services de confiance : signature électronique, certification, horodatage, archivage. Appliquer ses obligations à une plateforme de calcul générique est une lecture raisonnable, mais c'est une interprétation, pas la lettre du texte. Un juriste pourrait défendre un périmètre plus étroit, limité aux cas où la plateforme rend effectivement un service de confiance.

Plusieurs questions restent ouvertes. L'articulation exacte entre le décret, la loi 2019-014 et l'Arrêté 2022-040 mérite une lecture croisée par un praticien du droit togolais, notamment sur la qualification d'une plateforme en opérateur de services essentiels au sens de l'Arrêté. La notion de transfert de l'article 28 appliquée à des mouvements intra-cluster, éphémères et automatiques, n'a pas, à ma connaissance, été tranchée : un emptyDir qui touche brièvement un nœud d'une autre zone constitue-t-il un transfert au sens de la loi ? Enfin, la responsabilité des actions autonomes d'un Operator est un angle mort commun à beaucoup de cadres juridiques écrits avant l'automatisation déclarative, pas seulement au cadre togolais.

Le fond de l'affaire tient en une phrase. Ces textes ne sont pas mauvais : ils sont écrits pour un monde où l'infrastructure était stable et localisable. Kubernetes a rendu l'infrastructure mouvante, et la conformité consiste désormais à reconstruire, couche par couche, les garanties que la stabilité du matériel offrait gratuitement. Le travail n'est pas de contourner le texte, c'est de le traduire dans un modèle qu'il n'avait pas anticipé.

Sources

• Décret n°2018-062/PR portant réglementation des transactions et services électroniques au Togo, ARCEP
• Loi n°2017-007 relative aux transactions électroniques, numerique.gouv.tg
• Loi n°2019-014 du 29 octobre 2019 relative à la protection des données à caractère personnel, Journal Officiel
• Arrêté n°2022-040/PMRT portant adoption des règles de cybersécurité en République togolaise, CERT Togo

Ceci est une analyse d'ingénierie et non un conseil juridique. Pour toute décision de conformité, consultez un praticien du droit togolais de la protection des données.