L'illusion du multi-cloud pour l'État : la duplication n'est pas la souveraineté

Toute discussion de stratégie cloud gouvernementale en Afrique de l'Ouest finit par arriver à la même recommandation : ne mettez pas toutes vos charges chez un seul fournisseur, répartissez-les entre plusieurs. L'argument vient des équipes commerciales des hyperscalers qui veulent vous vendre un second contrat, des cabinets de conseil qui facturent au document de stratégie, et des institutions de financement du développement dont les référentiels « cloud-smart » traitent la diversification de fournisseurs comme un indicateur de modernisation numérique. La promesse est double : la résilience face à la panne d'un fournisseur, et la souveraineté face au pouvoir d'un fournisseur unique sur vos données. Pour un État qui opère sous la loi togolaise 2019-014 sur la protection des données à caractère personnel et le régime de cybersécurité de l'Arrêté 2022-040 pris par l'ANCY, cette seconde promesse est fausse. Le multi-cloud ne divise pas l'exposition juridique entre fournisseurs, il l'additionne. Chaque fournisseur étranger supplémentaire est une juridiction de plus qui peut contraindre à la divulgation, une chaîne de sous-traitance de plus à encadrer au sens de la loi, un jeu de logs de plus à réconcilier pour un audit qui peine déjà avec un seul.

Ceci n'est pas un argument contre le cloud computing, ni contre la concurrence entre fournisseurs. C'est un argument contre une confusion précise et répandue : traiter le multi-cloud de diversification de fournisseurs, plusieurs hyperscalers indépendants détenant chacun une part des mêmes données régulées, comme une stratégie de souveraineté. La redondance multi-région chez un seul fournisseur responsable est autre chose, et légitime, on y revient plus loin. Choisir plusieurs fournisseurs pour des charges non liées et non sensibles aussi. Ce qui suit vise la version du multi-cloud vendue dans les décks de stratégie IT gouvernementale comme la réponse anti-lock-in et anti-risque-de-souveraineté, parce que c'est celle-là qu'une administration régulée par l'ANCY a le plus de chances de se faire vendre.

Ce que le multi-cloud promet vraiment

L'argument le plus solide mérite d'être posé honnêtement avant d'être contesté. Un fournisseur unique est un point de défaillance unique : une panne régionale, un litige contractuel, un changement de tarification ou de conditions peuvent mettre à l'arrêt ou prendre en otage tous les services numériques d'un gouvernement en même temps. Répartir les charges entre deux ou trois fournisseurs supprime cette concentration de risque et donne aux achats un vrai levier de négociation, puisqu'aucun fournisseur ne peut présumer que la relation est acquise. Plusieurs hyperscalers commercialisent désormais une « région locale » sur le continent, ou promettent des engagements de résidence des données qui, sur une diapositive, sont indiscernables de la souveraineté. Les cabinets de conseil emballent cela en architectures « multi-cloud by design », et les projets de transformation numérique financés par des bailleurs listent souvent la diversification de fournisseurs comme une ligne de réduction de risque, parce que c'est mesurable et facile à inscrire dans un document d'évaluation de projet.

Rien de tout cela n'est malhonnête en soi. Le risque de panne est réel, le levier de négociation est réel, et une « région locale » met effectivement des octets sur des disques physiquement situés dans le pays ou la sous-région. Le problème n'est pas que ces affirmations soient fausses, c'est qu'elles répondent à une question plus étroite que celle à laquelle un État a réellement besoin de répondre. Un argument de résilience face aux pannes et un argument de levier de négociation sont opérationnels et commerciaux. Un argument de souveraineté est juridique : c'est une affirmation sur qui peut être contraint, par quel tribunal, en vertu de quelle loi, de livrer ou de cesser de traiter les données de vos citoyens. Le multi-cloud répond raisonnablement bien aux deux premières questions. Il ne répond pas à la troisième, et le traiter comme s'il y répondait, c'est exactement là que l'illusion s'installe.

La résidence ne se règle pas par la duplication

L'article 28 de la loi 2019-014 conditionne le transfert de données à caractère personnel « vers un pays tiers » au fait que ce pays offre « un niveau de protection suffisant », et exige une information préalable de l'Instance, l'autorité de protection des données, qui rend un avis motivé. La question que pose la loi n'est pas « où se trouve le disque », c'est « quel système juridique peut atteindre cette donnée, et l'avez-vous déclaré ». La « région locale » d'un hyperscaler répond à la première question et laisse la seconde exactement où elle était.

L'illustration la plus nette est le CLOUD Act américain, le Clarifying Lawful Overseas Use of Data Act de 2018. Il modifie le Stored Communications Act de sorte qu'un fournisseur soumis à la juridiction des États-Unis, typiquement parce qu'il y est constitué ou y a son siège, doit produire les données qu'il a en « possession, garde ou contrôle » en réponse à une procédure légale américaine valide, que ces données soient stockées à l'intérieur ou à l'extérieur des États-Unis. Une région africaine locale exploitée par un hyperscaler dont le siège est américain ne supprime pas cette exposition. La société mère reste une personne morale américaine, et la donnée reste sous son « contrôle » au sens de la loi, quel que soit le pays qui héberge le disque physique. La géographie a changé. La juridiction non.

Ce n'est pas un problème propre aux États-Unis, ni un problème hypothétique. L'Union européenne, avec un régime de protection des données bien plus mature et bien mieux doté que celui du Togo, s'est heurtée exactement au même mur. Dans son arrêt Schrems II de 2020 (affaire C-311/18), la Cour de justice de l'Union européenne a invalidé le cadre EU-US Privacy Shield parce que le droit de surveillance américain pouvait atteindre les données détenues par des fournisseurs liés aux États-Unis, indépendamment des clauses contractuelles types ou de l'emplacement physique du stockage dans l'UE. Si un bloc économique et juridique de la taille de l'UE n'a pas pu contourner par contrat une portée extraterritoriale, une clause « région locale » dans les conditions d'utilisation d'un seul hyperscaler n'y parviendra pas davantage pour un État ouest-africain.

Ajoutez maintenant un deuxième et un troisième fournisseur, chacun ayant son siège dans une juridiction différente, chacun régi par son propre régime de divulgation extraterritoriale, et l'arithmétique empire au lieu de s'améliorer. Le multi-cloud ne moyenne pas cette exposition entre fournisseurs : il ajoute une nouvelle juridiction de contrainte potentielle pour chaque fournisseur ajouté, et une nouvelle appréciation d'adéquation au sens de l'article 28 ainsi qu'un nouveau contrat de sous-traitance au sens de l'article 20 à maintenir pour chacun. La redondance au niveau infrastructure devient de la redondance de risque juridique au niveau conformité.

Le plan de contrôle n'a jamais quitté la maison

« Région locale » est presque toujours une affirmation sur le plan de données, l'endroit où les octets sont stockés et calculés. C'est rarement une affirmation sur le plan de contrôle : le système de gestion des identités et des accès, le mécanisme de facturation et de suspension de compte, le service de gestion des clés de chiffrement, le canal de support et d'escalade d'incident, la couche d'orchestration globale qui pousse les changements de configuration à travers les régions. Ceux-là restent généralement exploités depuis, et régis par, la juridiction d'origine du fournisseur, quel que soit l'endroit où se trouvent les disques.

Ceci rejoint directement la question d'établissement déjà posée par le décret. Le Décret 2018-062 ancre l'imputabilité dans un prestataire « établi sur le territoire national » (art. 58), parce que le texte suppose l'existence d'une entité locale légalement responsable que le régulateur peut atteindre et sanctionner. Une « région locale » exploitée par un hyperscaler étranger met la donnée dans le pays sans nécessairement y mettre cet établissement responsable : l'entité qui peut suspendre le compte, faire tourner les clés, ou pousser un changement global de plan de contrôle en réponse à un ordre légal de son gouvernement d'origine, reste dans la plupart des cas la société mère étrangère. L'État a localisé les octets et laissé le levier ailleurs.

Le multi-cloud ne corrige pas cela, il le multiplie. Au lieu de faire confiance à un seul plan de contrôle étranger, l'État dépend désormais de deux ou trois, chacun avec ses propres défauts de gestion de clés, sa propre pratique de réponse à incident, son propre modèle d'accès support, aucun ne pouvant être unifié par l'État en une seule chaîne de contrôle auditable. Plus de fournisseurs signifie plus de plans de contrôle à qui faire confiance simultanément, pas moins de points de levier étranger.

Le multi-cloud et le fardeau d'audit de l'ANCY

Un audit ANCY au titre de l'Arrêté 2022-040 fonctionne par domaines de contrôle : journalisation des événements (D1.1.1), résilience des activités (R1), contrôles cryptographiques (G3.1.5), et d'autres déjà cartographiés en détail ailleurs. Chacun de ces contrôles attend une piste de preuve cohérente : une politique de rétention à vérifier, une horloge de notification d'incident à contrôler contre la règle des vingt-quatre heures du décret, un jeu de logs d'audit à échantillonner.

Un parc multi-cloud casse cette cohérence par construction. Chaque fournisseur expose ses logs d'audit dans son propre schéma, les retient selon sa propre politique par défaut, et rapporte les incidents selon son propre calendrier interne avant même que l'horloge des vingt-quatre heures imposée par le décret ne puisse démarrer. Répondre à un seul contrôle ANCY, « montrez-moi les logs d'accès de cette charge sur les douze derniers mois », signifie désormais construire et maintenir des pipelines d'ingestion et de corrélation séparés par fournisseur, normaliser des formats qui n'ont jamais été conçus pour s'aligner, et espérer que les défauts de journalisation du fournisseur le moins instrumenté ne deviennent pas le plafond de ce que tout le parc peut prouver. Ce n'est pas un désagrément hypothétique, c'est une multiplication directe du coût et du risque d'audit : un auditeur n'a besoin de trouver le trou que chez le fournisseur le moins instrumenté pour faire échouer tout le parc sur un contrôle qu'un déploiement mono-fournisseur aurait pu satisfaire avec un seul tableau de bord.

Le coût caché : le plus petit dénominateur commun

Une véritable portabilité multi-cloud, celle qui permet de déplacer une charge d'un fournisseur à l'autre sans réécriture, exige de se standardiser sur l'intersection de ce que tous les fournisseurs choisis supportent. En pratique, cela signifie faire tourner des primitives Kubernetes basiques plutôt qu'une base de données managée, une file managée, ou un service de secrets managé, parce que ce sont précisément ces services managés qui diffèrent entre fournisseurs et créent le lock-in. L'équipe doit alors exploiter, patcher et sécuriser en interne ce qu'une offre managée aurait pris en charge, ce qui transfère directement la charge opérationnelle sur une organisation IT étatique qui est, quasiment par définition, plus contrainte en ressources que n'importe lequel des hyperscalers entre lesquels elle essaie de rester portable.

L'analyse de conformité Kubernetes le montrait déjà : un cluster unique bien géré a de vrais gaps, non triviaux, face à la loi 2019-014 et à l'Arrêté 2022-040 : résidence des données contre stockage éphémère, traçabilité des accès aux données personnelles, ambiguïté de l'imputabilité d'un Operator autonome, chiffrement au repos qui n'est pas activé par défaut. Aucun de ces gaps ne disparaît en ajoutant un second cloud. Ils se multiplient par le nombre de fournisseurs, pendant que la capacité d'ingénierie interne disponible pour les combler reste de la même taille. Un État qui parvenait tout juste à combler quatre gaps sur une plateforme se voit demander de combler quatre gaps sur deux ou trois plateformes simultanément, avec le même effectif.

Quand le multi-cloud est légitime

L'argument ci-dessus vise un schéma précis, pas tout usage de plus d'un fournisseur. Les cas suivants sont légitimes, pour des raisons différentes du récit de souveraineté habituellement avancé.

Le motif commun aux lignes légitimes est simple : soit la donnée n'a pas d'exposition juridique significative au départ, soit la redondance reste à l'intérieur d'une seule juridiction d'imputabilité. La ligne non légitime est celle où la redondance s'achète au prix d'ajouter des juridictions, et se vend comme si elle supprimait le risque au lieu de le déplacer et de le multiplier.

L'alternative bare-metal souverain

L'alternative vers laquelle pointe cet argument n'est pas « pas de cloud », c'est un fournisseur unique, établi nationalement ou régionalement, exploité éventuellement sur du Kubernetes bare-metal, qui satisfait l'établissement que présume le décret et donne à l'ANCY un parc unique et cohérent à auditer. Le bilan honnête comporte des pertes des deux côtés.

Ce qui se perd : une élasticité illimitée face aux pics de demande imprévisibles, l'accès aux services managés d'IA et de données les plus avancés que seuls les plus grands hyperscalers exploitent aujourd'hui à grande échelle, et la dépendance à un écosystème de fournisseurs régionaux plus petit et moins mature, avec ses propres contraintes de capacité et de talent. Un fournisseur souverain peut lui-même devenir un point de défaillance unique s'il est sous-doté, et « local » n'est pas synonyme de « bien audité » : un fournisseur souverain a besoin du même audit rigoureux et indépendant qu'un hyperscaler étranger, pas d'un laissez-passer parce qu'il a la bonne adresse.

Ce qui se gagne : un seul établissement légalement responsable qui satisfait réellement l'article 58 au lieu de le suggérer, un seul plan de contrôle au lieu de plusieurs, une seule piste de preuve pour un audit ANCY au lieu d'un exercice de réconciliation entre fournisseurs, et une structure de coût prévisible plutôt qu'élastique, ce qui compte parce que la plupart des charges étatiques ne sont pas à l'échelle d'Internet et n'ont pas besoin de l'élasticité d'un hyperscaler pour commencer. La conformité cesse d'être un exercice de rattrapage effectué après coup sur une infrastructure conçue ailleurs, et se rapproche d'une propriété de l'architecture elle-même.

Aucun des deux côtés de cet arbitrage n'est gratuit. La souveraineté par un fournisseur unique et responsable coûte de l'élasticité et l'accès aux services managés de pointe. L'illusion de souveraineté par la duplication multi-cloud coûte plus en effort d'ingénierie et en complexité d'audit qu'elle ne l'annonce, tout en livrant moins d'isolation juridictionnelle réelle que ce que promet l'argument commercial. Entre un vrai coût pour un vrai bénéfice et un bénéfice illusoire pour un vrai coût, le choix n'est pas serré.

Un cadre de décision

Avant d'adopter le multi-cloud pour une charge donnée, trois questions tranchent s'il aide ou s'il nuit :

Quelle est la donnée ? S'il s'agit de données personnelles au sens de la loi 2019-014, de données classifiées par l'État, ou de tout ce qu'une appréciation d'adéquation au titre de l'article 28 concernerait, traiter la diversification juridictionnelle comme un passif à minimiser, pas comme un bénéfice à poursuivre. S'il s'agit de contenu public ou non régulé, la question de souveraineté ne s'applique pas et les arguments de résilience et de négociation tiennent seuls.

Où vit réellement le plan de contrôle, et qui peut être contraint d'agir dessus ? Nommer honnêtement la juridiction, pour chaque fournisseur envisagé. Si la réponse nomme une juridiction hors de celle à laquelle la charge est censée être souveraine, ajouter un second fournisseur étranger ne change pas cette réponse, il en ajoute une seconde.

Quel est le motif réel ? Le levier de coût et la résilience technique sont des raisons d'ingénierie et d'achat légitimes, et devraient être nommées comme telles dans le document de stratégie. Si la justification affichée est la « souveraineté » ou la « réduction du risque juridique », elle doit désigner une exposition précise qu'elle supprime, un article, un contrôle, un transfert qu'elle évite, pas seulement une liste de fournisseurs diversifiée qui a l'air prudente sur une diapositive.

Limites de l'analyse et questions ouvertes

Ceci est un cadre stratégique, pas un substitut à une évaluation de risque juridique d'un contrat fournisseur précis. Certains hyperscalers proposent désormais des structures d'entité conçues spécifiquement pour réduire l'exposition au CLOUD Act, comme des montages de type « data trustee » opérés via une filiale locale ou régionale avec des barrières contractuelles contre l'accès de la société mère américaine. Savoir si une structure donnée réduit effectivement cette exposition est une question juridique à trancher au cas par cas, qui mérite un examen réel, pas un rejet en bloc au même titre que le marketing ordinaire de « région locale », ni une acceptation aveugle non plus. De même, une stratégie purement bare-metal souveraine échange un ensemble de risques contre un autre : les contraintes de capacité et de talent dans un écosystème local restreint sont de vrais modes de défaillance, et « souverain » est une propriété juridictionnelle, pas une garantie de compétence. Un fournisseur local mal géré n'est pas plus sûr qu'un fournisseur étranger bien géré, il est exposé différemment.

Le fond de l'argument tient en une phrase. Le multi-cloud répond à une question de disponibilité et, parfois, à une question de négociation, mais il ne répond pas à une question de juridiction, et l'habiller en stratégie de souveraineté multiplie le nombre de systèmes juridiques qui peuvent atteindre vos données au lieu de le réduire. Le remède à un problème de juridiction est une réponse de juridiction : un seul établissement responsable, à l'intérieur du périmètre que la loi définit déjà, pas une liste plus longue de fournisseurs étrangers détenant chacun un morceau de la même exposition.

Sources

• Loi n°2019-014 du 29 octobre 2019 relative à la protection des données à caractère personnel, Journal Officiel
• Décret n°2018-062/PR portant réglementation des transactions et services électroniques au Togo, ARCEP
• Arrêté n°2022-040/PMRT portant adoption des règles de cybersécurité en République togolaise, CERT Togo
• H.R.4943, Clarifying Lawful Overseas Use of Data Act (CLOUD Act), 115e Congrès américain, Congress.gov
• Cour de justice de l'Union européenne, affaire C-311/18, Data Protection Commissioner contre Facebook Ireland et Maximillian Schrems (« Schrems II »), 16 juillet 2020, InfoCuria

Ceci est une analyse stratégique et technique, pas un conseil juridique. Pour une évaluation de risque juridictionnel propre à un contrat fournisseur, consultez un praticien du droit de la protection des données et des marchés publics.