Chaque prompt est un transfert transfrontalier : gouvernance IA sous la loi 2019-014
31 août 2026 · 16 min read · Read in English
Sommaire
Une compagnie d'assurance de Lomé équipe deux cents collaborateurs d'un assistant IA. Une banque de Dakar branche son équipe support sur les mêmes fournisseurs. Une agence publique d'Abidjan lance un pilote de résumé documentaire. Dans chaque cas le travail est réel, le gain de productivité est réel, et l'achat s'est résumé à une carte d'entreprise et une URL de base. Dans chaque cas, personne n'a rien déclaré à l'autorité de protection des données, parce que personne n'a qualifié ce qui se passait comme un transfert de données. On l'a qualifié d'achat d'outil.
Le premier article de cette série montrait que personne ne sait ce qu'une entreprise dépense en IA. Le deuxième construisait la passerelle qui répond à cette question. Celui-ci reprend la deuxième des trois inconnues, l'exposition, dans un cadre où elle cesse d'être une affaire de préférence interne : ce qui sort des murs, sous quelle loi, et ce qu'une passerelle y change ou n'y change pas.
Deux réserves avant tout. Ceci est une analyse d'ingénierie et non un avis juridique, et le lecteur qui a besoin d'un avis doit le demander à un conseil inscrit dans la juridiction concernée. Et les textes cités ici ont été écrits avant l'existence de l'inférence conversationnelle, donc les appliquer suppose une interprétation. Je signale chaque endroit où j'étends un texte plutôt que de le lire.
La qualification que personne n'a faite
Partez de ce qui se trouve réellement dans la requête. Un agent du support colle un email client pour se faire aider à répondre. L'email contient un nom, une adresse, un numéro de police et une réclamation. Une recruteuse colle un CV pour le résumer. Un juriste téléverse un contrat qui nomme les parties. Un manager demande de l'aide pour rédiger un avertissement visant un salarié nommé.
Chacune de ces charges utiles est une donnée à caractère personnel selon toute lecture ordinaire : une information relative à une personne physique identifiée ou identifiable. L'envoyer vers un modèle hébergé hors du pays est un traitement effectué par un tiers pour le compte de l'entreprise, et la donnée a franchi une frontière pour y parvenir. Ce sont les deux faits dont découle tout le reste, et s'ils passent inaperçus c'est qu'aucun des deux ne ressemble à l'image mentale que les gens se font d'un transfert. Il n'y a pas d'export de base, pas de fichier, pas de projet de migration, pas de signature. Il y a une personne qui tape dans une zone de texte.
Cette image mentale compte plus qu'elle ne le devrait, parce que les processus de conformité se déclenchent à la reconnaissance. Une entreprise qui n'enverrait jamais un fichier clients à un prestataire étranger sans revue laissera le même contenu sortir un paragraphe à la fois, des milliers de fois par jour, parce que chaque acte pris isolément est minuscule et ressemble à de l'usage de logiciel plutôt qu'à un envoi de données.
Il y a ici une seconde population traitée, régulièrement oubliée : les collaborateurs eux-mêmes. Chaque prompt est rédigé par une personne identifiée, et dès lors qu'une passerelle journalise, l'entreprise traite des données de ses salariés portant sur ce qu'ils demandent, quand, et à quelle fréquence. C'est un traitement à part entière, avec sa propre base et sa propre obligation d'information des personnes concernées. Déployer une passerelle sans dire aux collaborateurs ce qu'elle enregistre, c'est créer un problème de conformité avec la solution de conformité.
Ce que demande réellement la loi 2019-014
La loi togolaise 2019-014 relative à la protection des données à caractère personnel conditionne le transfert de données vers un pays tiers au fait que ce pays offre un niveau de protection suffisant, et impose une information préalable de l'Instance, l'autorité de protection des données, qui rend un avis motivé. À ses côtés se trouvent la loi 2017-007 sur les transactions électroniques et son décret d'application 2018-062, ainsi que les règles de cybersécurité de l'arrêté 2022-040 pris par l'ANCY. Les juridictions voisines de l'UEMOA disposent de régimes structurellement proches, avec des institutions et des seuils différents.
La question que pose le texte n'est pas où se trouve le disque. C'est quel système juridique peut atteindre la donnée, et si vous avez déclaré cette exposition. C'est le point que l'analyse multi-cloud de ce blog faisait à propos du stockage, et il se transpose à l'inférence sans modification.
Ce qui ne se transpose pas proprement, c'est la forme de ce qu'il faut déclarer. Un régime de transfert de ce type suppose un traitement décrit : un jeu de données défini, une finalité énoncée, un destinataire connu, une durée de conservation, une description de sécurité. Ce cadre convient à un export de paie vers un sous-traitant étranger. Il convient mal à une passerelle LLM, parce que le contenu transféré est décidé à l'exécution par le collaborateur qui tape, et qu'aucune déclaration écrite à l'avance ne peut l'énumérer. Vous pouvez déclarer les catégories de données susceptibles d'être envoyées, les destinataires, les finalités et les garanties. Vous ne pouvez pas déclarer la charge utile, parce que la charge utile est ce que deux cents personnes décideront de coller demain.
C'est le véritable écart, et il mérite d'être formulé précisément parce qu'il coupe dans les deux sens. Ce n'est pas un prétexte pour sauter la déclaration : les catégories, les destinataires et les garanties sont déclarables, et refuser de les déclarer parce que l'exercice est imparfait n'est pas une position tenable. Mais cela signifie que le contrôle qui borne réellement le transfert n'est pas la paperasse. C'est le mécanisme qui contraint ce que les collaborateurs peuvent envoyer, donc un contrôle technique, donc la passerelle. La déclaration décrit la frontière. La passerelle est la frontière.
La juridiction, brièvement
Si l'analyse du « niveau de protection suffisant » se termine rarement bien pour les fournisseurs d'inférence américains, c'est pour la même raison qu'elle se termine rarement bien pour les fournisseurs cloud américains, et ce blog a déjà développé l'argument pour le stockage. En résumé : le CLOUD Act de 2018 amende le Stored Communications Act de sorte qu'un fournisseur soumis à la juridiction des États-Unis doit produire les données en sa possession, sa garde ou son contrôle en réponse à une procédure légale valide, quel que soit l'endroit où ces données se trouvent physiquement. Un point d'accès régional change la géographie. Il ne change pas quel tribunal peut contraindre la maison mère.
Appliqué à l'inférence, un détail aggravant mérite d'être noté. Avec le stockage, l'exposition est un stock : la donnée est là et pourrait être réquisitionnée. Avec l'inférence, l'exposition est un flux, et l'artefact intéressant n'est souvent pas la charge utile mais le motif. Le journal de ce que le personnel d'une administration a demandé sur une année est une description de ce sur quoi cette administration travaillait. Même un fournisseur qui ne conserve aucun contenu conserve des enregistrements de facturation, et ces enregistrements sont des métadonnées de volume, d'horaire et de département. C'est une exposition plus faible que le contenu, et ce n'est pas rien.
Ce que la passerelle règle vraiment
Sur ce fond, la passerelle de l'article précédent fait cinq choses précises, et il vaut la peine d'être exact à leur sujet, car la tentation d'en revendiquer davantage est forte.
Elle crée un point de sortie unique, ce qui rend le transfert inventoriable. Auparavant, la réponse honnête à « quels fournisseurs reçoivent nos données » était une estimation. Après, c'est une liste, et une liste est le préalable de toute déclaration.
Elle rend le flux descriptible. Catégories de données, destinataires, volumes, par département : tout cela se trouve dans le grand livre que vous aviez construit pour des raisons de coût, et c'est exactement la matière dont a besoin une demande d'avis motivé.
Elle autorise une transformation avant transfert. Masquer les données personnelles avant que la requête ne quitte votre infrastructure réduit ce qui franchit effectivement la frontière, et c'est une réduction réelle et non cosmétique, sous une limite traitée plus bas.
Elle vous donne le contrôle de la conservation de votre côté de la ligne. Ce que vous journalisez, pendant combien de temps et qui peut le lire deviennent vos décisions plutôt qu'un défaut fournisseur. Choisir de journaliser les métadonnées et pas le contenu, comme le recommandait l'article précédent, est une décision de protection des données autant que de stockage.
Elle rend le destinataire remplaçable. Comme les appelants s'adressent à des noms de modèles internes et non à des noms de fournisseurs, changer de fournisseur est un changement de configuration. Cela compte juridiquement et pas seulement opérationnellement : une entreprise capable de déplacer son trafic vers une autre juridiction en un après-midi n'est pas dans la même position de négociation et de remédiation qu'une entreprise qui aurait besoin d'un projet de six mois.
Ce qu'elle ne règle pas
La passerelle ne change pas la nature juridique du transfert. La donnée sort toujours, un sous-traitant étranger la traite toujours, et la même juridiction atteint toujours ce sous-traitant. Passer d'abord par votre propre proxy n'est pas une transformation, c'est un saut de plus. Quiconque présente une passerelle comme la réponse à une obligation de résidence vend la version IA de l'illusion multi-cloud : un changement de topologie décrit comme un changement d'exposition.
Elle ne résout pas les conditions que vous avez acceptées. Durées de conservation, possibilité d'utiliser les saisies pour l'entraînement, chaînes de sous-traitants et juridictions de ces sous-traitants sont fixées par contrat, et elles diffèrent substantiellement entre une offre grand public et un accord API entreprise chez le même éditeur. Lisez l'offre sur laquelle vous êtes réellement, pas la page marketing de celle que vous aimeriez avoir, et relisez-la quand elle change.
Et le masquage n'est pas de l'anonymisation. La détection est statistique : la reconnaissance d'entités rate les formes de noms inhabituelles, les conventions d'adresses locales et les identifiants sur lesquels elle n'a jamais été entraînée, et les motifs de noms et d'adresses ouest-africains sont exactement le genre de chose qu'un modèle réglé sur des données européennes et américaines traite le moins bien. Au-delà de la question de justesse s'en pose une juridique, réellement ouverte : remplacer un nom par un jeton en conservant le reste d'un dossier est une pseudonymisation, pas une anonymisation, car le contexte environnant réidentifie souvent la personne pour quiconque détient la source. Une donnée masquée reste très probablement une donnée personnelle. Le masque réduit l'exposition et ne supprime pas le transfert, et toute communication interne qui brouille ces deux affirmations vous sera resservie.
Les options de résidence, classées honnêtement
Quatre postures existent, et elles diffèrent bien plus par le coût que par la diapositive qui les décrit.
API publique avec garanties contractuelles. Le défaut. Le moins cher au token, les meilleurs modèles, aucune infrastructure. Le transfert est réel, la garantie est contractuelle, et la charge de déclaration est entièrement la vôtre. Pour des charges non sensibles c'est un choix défendable s'il est fait explicitement plutôt que par accident, et l'expliciter constitue l'essentiel du progrès.
Point d'accès régional chez le même fournisseur. La donnée peut être traitée plus près, la latence s'améliore. La juridiction sur la maison mère est inchangée. Cela vaut la peine d'être pris, et cela ne vaut pas la peine d'être survendu : cela traite la localité, pas l'atteignabilité.
Modèle déployé dans votre propre tenancy cloud. Les offres managées qui exécutent un modèle dans un compte que vous contrôlez réduisent l'exposition de façon significative, car les poids s'exécutent dans votre tenancy et non dans le service de l'éditeur. La juridiction du fournisseur cloud s'applique toujours, donc cela améliore le volet sous-traitance plutôt que d'éliminer le problème du contrôle étranger. Le coût monte, et il monte généralement vers de la capacité réservée, ce qui fait passer la forme FinOps du purement variable au partiellement engagé.
Modèle à poids ouverts auto-hébergé sur une infrastructure que vous contrôlez. La seule option où aucune entité étrangère ne traite la donnée. C'est aussi la seule où vous portez toute la charge opérationnelle : GPU, pilotes, pile de service, évaluation, montées de version, et l'écart de capacité entre un modèle ouvert de taille moyenne et le frontier du moment, écart réel qui se resserre et se rouvre à chaque cycle de publication. Pour une tâche étroite et bien définie sur des données réglementées, un petit modèle ouvert suffit fréquemment. Comme assistant généraliste pour deux cents personnes, il déçoit d'ordinaire, et la déception renvoie les gens sur leurs comptes personnels, ce qui est précisément le résultat que tout l'exercice vise à empêcher.
Le schéma qui tient au contact du réel n'est pas d'en choisir une. C'est de router par classe de données : le trafic réglementé et sensible vers le niveau auto-hébergé ou déployé en tenancy, tout le reste vers l'API publique, avec le routage appliqué à la passerelle plutôt que laissé au jugement de celui qui tape. C'est exactement à cela que servent le contrôle d'accès par modèle et le nommage interne des modèles, et c'est la raison concrète pour laquelle l'article précédent insistait sur le nommage des modèles par rôle.
Où se situent réellement les économies
La décision d'auto-héberger est habituellement présentée comme un choix de conformité assorti d'une pénalité de coût. Dans le contexte UEMOA, le volet coût présente trois caractéristiques qui changent l'arithmétique, et aucune n'apparaît dans les analyses écrites pour des entreprises européennes.
L'énergie et l'hébergement d'abord. Un déploiement souverain suppose soit un datacenter local doté du profil d'alimentation et de refroidissement qu'exigent les GPU, soit du bare-metal dans une installation qui l'a. Ce blog a déjà défendu l'architecture de référence du Kubernetes bare-metal souverain ; les charges d'inférence reprennent le même argument avec du matériel plus cher et une tolérance aux interruptions plus faible. De la capacité qui dort la nuit est de la capacité que vous avez payée, ce qui est l'inverse de la seule vertu réelle du modèle au token.
La devise ensuite, et c'est la raison pour laquelle l'article précédent gardait tous les coûts unitaires en dollars. Les factures fournisseurs sont libellées en dollars. Le franc CFA est arrimé à l'euro à parité fixe, donc le coût local d'une facture IA libellée en dollars suit l'euro face au dollar et rien d'ouest-africain. Une entreprise qui reporte son coût IA en monnaie locale verra ses coûts unitaires bouger pour des raisons sans rapport avec sa propre consommation, ce qui explique que la consommation se mesure en dollars à la passerelle et que l'exposition de change appartienne à la trésorerie. L'auto-hébergement convertit un coût variable libellé en dollars en un coût majoritairement local et capitalistique, et c'est un argument stratégique réel en sa faveur, sans rapport avec la protection des données.
La friction de paiement enfin, celle dont personne n'écrit. Payer des fournisseurs américains depuis la sous-région suppose une carte qui fonctionne, des plafonds assez hauts pour une facture qui croît avec l'usage et non avec l'effectif, et un processus financier capable d'absorber une charge variable en devise étrangère sans validation manuelle chaque mois. Les organisations finissent régulièrement avec la facture sur la carte d'une seule personne, ce qui est un risque opérationnel et un problème comptable avant d'être un problème de conformité. La passerelle aide ici d'une manière facile à manquer : consolider toutes les relations fournisseurs derrière un jeu unique d'identifiants détenus par l'entreprise remplace des dizaines d'arrangements de paiement individuels par un petit nombre d'arrangements gérables.
Un cadre de décision
Routez par classe de données, et appliquez le routage à la passerelle plutôt que dans un document de politique.
| Classe de données | Exemple | Posture | Application |
|---|---|---|---|
| Publique ou interne, sans donnée personnelle | Documentation publique, code générique, contenus marketing | API publique, meilleur modèle disponible | Niveau par défaut, aucune restriction |
| Donnée personnelle, faible sensibilité | Rédaction d'emails internes, correspondance non sensible | API publique sous conditions entreprise, masquage actif | Garde-fou PII en mode masquage, transfert déclaré |
| Donnée personnelle réglementée | Dossiers clients, données RH, santé ou finance | Modèle déployé en tenancy ou auto-hébergé | Noms de modèles distincts, réservés à des équipes précises |
| Donnée d'État ou classifiée | Charges d'administration souveraine sous règles ANCY | Auto-hébergé sur infrastructure contrôlée | Déploiement physiquement séparé, aucun fallback vers l'API publique |
La dernière ligne mérite un avertissement particulier. Les fallbacks sont une fonctionnalité de résilience et un danger de conformité, car un fallback reroute silencieusement le trafic vers une autre juridiction exactement au moment où personne ne regarde. Tout nom de modèle réservé aux données réglementées ne doit avoir aucun chemin de repli vers un fournisseur public, et cette contrainte appartient à la configuration du routeur, pas à la mémoire d'un exploitant.
Limites et questions ouvertes
La plus grande question ouverte est celle soulevée plus haut : un contenu masqué ou pseudonymisé constitue-t-il encore un transfert de données personnelles ? Selon le raisonnement qu'appliquent la plupart des régimes de protection des données, oui, car une donnée pseudonymisée reste une donnée personnelle dès lors que la réidentification est possible pour quelqu'un. Cette lecture fait du masque une réduction de risque et non une exemption juridique, ce qui est la position prudente et celle sur laquelle je bâtirais. Elle n'est pas tranchée, et une entreprise qui s'appuie sur le masquage pour éviter une déclaration s'appuie sur une interprétation, pas sur une règle.
La deuxième est institutionnelle. L'Instance n'a pas, à ma connaissance, publié de doctrine portant spécifiquement sur l'inférence conversationnelle, et la plupart de ses homologues régionaux non plus. Les entreprises raisonnent donc par analogie à partir de règles de transfert écrites pour des jeux de données. Cette analogie est la meilleure disponible et reste une analogie, et le premier avis publié dans la sous-région sur cette question tranchera des points que cet article ne peut qu'argumenter.
La troisième est que cette analyse s'arrête à la frontière de l'API. Elle ne dit rien des fonctions IA intégrées dans les produits SaaS que l'entreprise utilise déjà, où le transfert se produit à l'intérieur de l'infrastructure de l'éditeur, sous un contrat signé avant que quiconque n'ait envisagé la question. Cette surface est plus vaste que celle qu'une passerelle contrôle et elle se gouverne par les achats plutôt que par l'ingénierie, ce qui est un autre article et, pour la plupart des organisations, une exposition non mesurée plus grande que celle dont elles se préoccupent aujourd'hui.
Sources
- Togo, loi 2019-014 du 29 octobre 2019 relative à la protection des données à caractère personnel, en particulier le régime des transferts vers les pays tiers et le rôle de l'Instance.
- Togo, loi 2017-007 sur les transactions électroniques et décret d'application 2018-062 ; arrêté 2022-040 fixant les règles de cybersécurité supervisées par l'ANCY. Analysés en détail dans Décret 2018-062 et Kubernetes.
- États-Unis, Clarifying Lawful Overseas Use of Data Act (CLOUD Act), 2018, amendant le Stored Communications Act. Appliqué au stockage dans L'illusion du multi-cloud pour l'État.
- Modèles de déploiement bare-metal souverain : Architecture de référence pour un cloud gouvernemental souverain.
- Documentation LiteLLM, Garde-fous : masquage PII avec Presidio, pour le mécanisme de masquage avant transfert évoqué ici. docs.litellm.ai/docs/proxy/guardrails/pii_masking_v2
- Conditions de traitement des données des fournisseurs, qui diffèrent selon l'offre et évoluent dans le temps, et qu'il faut lire pour l'offre effectivement utilisée.
S'abonner aux prochains articles
Recevez les nouveaux articles par e-mail. Pas de spam, désinscription à tout moment.
Related posts
Architecture de référence pour un cloud gouvernemental souverain
Les deux articles précédents ont montré où le droit togolais et Kubernetes ne se rencontrent pas, puis pourquoi le multi-cloud ne répond pas à une question de juridiction. Celui-ci propose ce qu'il faut construire : une architecture de référence pour un cloud gouvernemental souverain en contexte UEMOA. Cahier des charges dérivé du texte, choix de couches justifiés un par un, modèle opérationnel, limites assumées et comparaison honnête avec les alternatives. Un document d'architecture, pas un tutoriel.
August 15, 2026
Personne ne sait ce que votre entreprise dépense en IA
Dans toutes les entreprises, les collaborateurs utilisent désormais OpenAI, Anthropic et Gemini au quotidien, et presque aucune n'est capable de dire qui a demandé quoi, quelles données sont sorties, ni ce que tout cela a rapporté. Cet article défend l'idée que la gouvernance IA par la charte échoue pour les mêmes raisons que les politiques anti shadow IT, que la demande d'un budget IA fixe est la mauvaise question, et que le FinOps est la porte d'entrée pratique : des trois inconnues, seul le coût est mesurable aujourd'hui, et c'est en le mesurant qu'on obtient les deux autres.
August 29, 2026
L'illusion du multi-cloud pour l'État : la duplication n'est pas la souveraineté
Le multi-cloud est vendu aux États africains comme la réponse à la fois à la résilience et à la souveraineté numérique : répartir ses charges entre plusieurs hyperscalers diluerait le risque et le pouvoir du fournisseur. Sous la loi togolaise 2019-014 sur les données personnelles et le régime de cybersécurité de l'ANCY, cette promesse ne tient pas. Cet article défend que le multi-cloud ne divise pas l'exposition juridique, il la multiplie, et se termine par un cadre de décision sur quand il est légitime et quand il ne l'est pas.
August 7, 2026