La souveraineté est un choix d'architecture, pas d'hébergement

Une entreprise décide qu’elle veut maîtriser ses données. Le projet reçoit un budget, un fournisseur est choisi et, dix-huit mois plus tard, les systèmes tournent dans un datacenter situé dans le pays, à des conditions contractuelles qui satisfont le service juridique. On annonce au conseil d’administration que l’entreprise est désormais souveraine.

Puis quelqu’un pose une question pratique. Si l’éditeur augmentait fortement ses prix l’an prochain, combien de temps faudrait-il pour partir ? Personne ne sait répondre. Le modèle de données appartient au produit de l’éditeur. Les circuits d’approbation sont paramétrés dans ses écrans d’administration. Les clés de chiffrement résident dans son service de gestion de clés, et le modèle de langage qui rédige les réponses aux clients est appelé via son compte. Les serveurs ont déménagé. La dépendance, non.

La cause : la souveraineté a été traitée comme une question de lieu, alors qu’elle est une question de qui peut faire quoi sans demander la permission. Le lieu compte : il détermine le droit applicable et qui peut être contraint de remettre les données. Mais ce n’est qu’une propriété parmi d’autres, et la seule qui s’achète sur étagère. Les autres doivent être conçues.

Là où la « souveraineté » échoue en silence

Des clés détenues ailleurs. Si les clés de chiffrement vivent dans un service que contrôle le prestataire, celui-ci peut lire les données, tout comme quiconque peut le contraindre. Des données stockées dans votre pays et chiffrées avec une clé que vous ne détenez pas sont localisées, pas maîtrisées.

Un modèle métier que vous ne pouvez pas emporter. Tous les systèmes proposent un export. Peu exportent les relations, les règles et l’historique sous une forme qu’un autre système peut charger. Un ensemble de tables sans le sens de leurs colonnes est une sauvegarde, pas une sortie.

Une logique enfouie dans le paramétrage. Seuils d’approbation, règles tarifaires, orientation des demandes : quand ce sont des clics dans un écran propriétaire, on ne peut ni les lire, ni les relire, ni les déplacer. La façon dont l’entreprise fonctionne est conservée dans un format qu’un seul produit comprend.

Un modèle, un fournisseur. Si tout le travail sur le langage passe par un seul modèle externe, sous un seul compte, la capacité de l’entreprise à fonctionner dépend désormais des prix, de la disponibilité et des conditions d’utilisation de ce fournisseur. C’est un risque de chaîne d’approvisionnement, et il figure rarement dans une cartographie des risques.

Une sortie que personne n’a répétée. Un plan de sortie jamais exécuté est un espoir. La première fois que quelqu’un vérifie si l’entreprise peut partir, c’est généralement le jour où elle y est obligée.

Ce qu’il faut concevoir à la place

Traitez la souveraineté comme un ensemble de propriétés de l’architecture, chacune vérifiable par quelqu’un qui n’a pas à croire l’éditeur sur parole.

Les clés sont à vous. Les clés de chiffrement sont générées et conservées sur une infrastructure que l’entreprise contrôle, et l’exploitant de la plateforme ne peut pas s’en servir sans l’entreprise.

Le modèle de l’entreprise voyage avec les données. Objets, relations et règles sont décrits sous une forme ouverte et lisible, et versionnés, de sorte que ce que l’entreprise entend par une commande ou un client puisse partir avec les enregistrements. C’est le rôle d’une ontologie : le sens vit à côté des données, pas à l’intérieur du produit d’un seul éditeur.

La logique se lit. Règles et processus sont conservés comme des artefacts relisibles, dotés d’un historique, et non comme l’état d’un écran de paramétrage. Si un agent a modifié une règle, la modification a un auteur, un motif et une approbation.

Les modèles sont remplaçables. Le travail sur le langage est orienté tâche par tâche : le travail sensible peut aller à un modèle sur votre propre matériel, le travail courant à un modèle de pointe, et l’un comme l’autre peut être remplacé sans réécrire les processus qui s’en servent. Là où un petit modèle sur votre propre matériel suffit, l’architecture doit vous permettre de l’utiliser.

La pile est open source là où cela compte. L’open source ne garantit pas la souveraineté, mais il supprime la seule dépendance qui ne se négocie jamais : l’autorisation même de faire tourner le logiciel.

C’est la conception selon laquelle Hurukan est construit. Sa couche Sécurité et souveraineté applique les droits côté serveur, audite chaque modification en précisant si elle vient d’une personne, d’un agent ou du système, fonctionne sur l’infrastructure choisie par l’entreprise et consigne la sortie dès le départ. Elle est en construction, pas déployée : ce qui est décrit ici est une conception, pas un bilan.

Un test à faire cette semaine

Prenez un processus qui compte. La facturation est un bon candidat, parce qu’elle touche aux clients, aux prix, aux paiements et au droit. Répondez par écrit à cinq questions :

1. Où se trouvent les clés de chiffrement de ces données, et qui peut s’en servir ?
2. Si vous exportiez tout aujourd’hui, un autre système pourrait-il reproduire ce qu’une facture signifie ici : ses états, ses règles d’approbation, ses liens avec les commandes et les paiements ?
3. Où vivent les règles de ce processus, et une personne peut-elle les lire sans se connecter à l’outil de l’éditeur ?
4. Quels modèles externes touchent ces données, sous quel compte, et qu’advient-il du processus si ce modèle est indisponible pendant une semaine ?
5. À quand remonte la dernière fois que quelqu’un a déplacé ce processus, ou une copie, vers une autre infrastructure ?

Toute question qui demande plus d’une journée pour obtenir une réponse signale une dépendance que personne n’a conçue. Les réponses montrent aussi quelles données méritent le plus de soin, sujet d’un article distinct sur les données qui doivent rester dans l’entreprise.

La souveraineté achetée comme un contrat d’hébergement dure jusqu’à la première négociation difficile. La souveraineté conçue dans les clés, le modèle, la logique et la sortie est toujours là quand la négociation se tend. La présentation de Hurukan montre comment les couches s’articulent.