Le deck du fournisseur répond à la question qu’il a choisie. Un architecte sécurité en pose une autre : de quoi ce logiciel a-t-il besoin hors de mon réseau, et qu’est-ce qui en sort ? Posez les huit exigences ci-dessous au fournisseur, par écrit, avant la démonstration. Chacune vient avec le test que vous faites vous-même et la réponse qui clôt la réunion.
1. Ça tourne sous vos comptes, vos clés et votre juridiction
Le logiciel s’installe dans une infrastructure que vous contrôlez, s’authentifie contre votre fournisseur d’identité et stocke sous vos propres clés. Aucun control plane du fournisseur n’est requis pour démarrer, rester licencié ou continuer de fonctionner ; s’il en existe un, vous pouvez l’éteindre et le logiciel continue.
Comment vous le vérifiez. Bloquez les domaines du fournisseur au firewall et redémarrez le logiciel. Demandez la liste de chaque hôte qu’il joindra un jour, puis lisez vos logs de sortie après une semaine en production et comparez.
La mauvaise réponse. « Le control plane est hébergé dans une région UE. » La géographie juridique bat la géographie physique : une donnée tenue sous juridiction américaine est atteignable quel que soit son datacenter.[1] Le CLOUD Act oblige un fournisseur soumis à la juridiction des États-Unis à produire les données en sa possession, garde ou contrôle, où qu’elles soient stockées.[2]
2. Ça tourne entièrement fermé, et vous pouvez le prouver
Un déploiement qui tourne aujourd’hui sans modèle extérieur et sans réseau extérieur, contre un modèle que vous hébergez vous-même. Une couche d’intelligence qui présuppose une connexion à un datacenter sous juridiction étrangère est un otage, et sera traitée comme tel au moment précis où cela compte.[3]
Comment vous le vérifiez. Déployez dans un segment réseau sans route par défaut. Faites la démonstration là. S’il faut une exception, vous avez votre réponse.
La mauvaise réponse. « Notre endpoint de modèle est privé et chiffré en transit. » Le chiffrement décrit le tuyau. La question était : le tuyau existe-t-il ?
3. Aucune copie de vos données n’existe que vous n’ayez décidé de faire
Chaque extract, index, cache et stockage d’embeddings est une copie, et une copie a trois propriétés à connaître : où elle est, qui la lit, quand elle a été prise. Un fournisseur qui détient des copies hors de votre périmètre détient vos données.
Comment vous le vérifiez. Demandez l’inventaire de chaque endroit où le logiciel persiste ce qu’il dérive de vos données. Puis regardez les volumes vous-même et comparez.
La mauvaise réponse. « Nous ne gardons que des métadonnées. » Un schéma avec vos noms de colonnes, vos identifiants clients et vos codes produits est une description de votre entreprise.
4. Les droits d’accès vivent là où on ne peut pas les contourner
Qui peut voir quel enregistrement est une règle du stockage, appliquée là où passe chaque requête, jamais un filtre dans du code applicatif qu’un bug, un prompt ou une nouvelle intégration peut contourner. Un agent hérite des droits de la personne pour qui il agit, et rien de plus.
Comment vous le vérifiez. Prenez un compte aux droits restreints. Posez la question que la restriction existe pour bloquer, en trois formulations. Puis passez-la par chaque autre chemin : l’API, l’export, le rapport.
La mauvaise réponse. « L’agent a pour instruction de ne pas renvoyer ces données. » Une instruction est une demande. Une permission est un fait.
5. Chaque action attend un humain nommé
Le logiciel propose. Une personne, nommée et horodatée, approuve, et alors seulement quelque chose change dans un système de référence.
Comment vous le vérifiez. Demandez ce qui se passe entre la proposition et l’écriture, et qui la voit en premier. Demandez combien de propositions un approbateur doit traiter par jour, et décidez si c’est une revue.
La mauvaise réponse. « L’humain dans la boucle est configurable. » Un humain qui valide plusieurs centaines de propositions de la machine dans une journée ne valide rien ; c’est un appareil à signature attaché à un processus qu’il ne peut pas examiner.[4]
6. La trace peut être rejouée
Une trace qui enregistre ce que le modèle a dit est une transcription. Il vous faut une trace d’où la décision peut être reconstruite : quels enregistrements lus, quelle règle appliquée, quel plan exécuté, qui a approuvé, dans un ordre que personne ne peut réécrire après coup. La souveraineté se révèle dans l’exception, et l’exception est le cas sur lequel le régulateur vous interrogera, celui qu’un système statistique traite avec la même assurance que tout le reste.[5]
Comment vous le vérifiez. Prenez une décision du mois dernier. Demandez que sa réponse soit reproduite à partir de la trace seule, sur les mêmes données, sans le modèle. Si le chiffre bouge, la trace est un récit.
La mauvaise réponse. « Nous loggons chaque prompt et chaque complétion. » Un log de ce qui a été dit n’enregistre pas ce qui a été fait.
7. Si le fournisseur disparaît, vous opérez ce que vous avez installé
Le logiciel continue sans fournisseur, sur votre infrastructure, sous votre équipe d’exploitation. Une licence n’expire pas en écran verrouillé. Les formats qu’il écrit se lisent sans lui.
Comment vous le vérifiez. Demandez le runbook que votre équipe suivrait sans le fournisseur. Puis lisez la clause de résiliation.
La mauvaise réponse. « Nous proposons un escrow. » Du code source sous escrow est la promesse que vous reconstruirez un jour une chose que vous n’avez jamais appris à faire tourner.
8. Rien n’est partagé entre clients
Un déploiement, un modèle de l’entreprise, une organisation. Pas de tenant partagé, pas d’index partagé, pas d’embeddings mis en commun, pas de modèle amélioré sur vos données et servi à votre concurrent. La souveraineté est une pile : silicium, poids, données, ontologie, décision, et une seule couche partagée rend la pile entière partagée.[6]
Comment vous le vérifiez. Demandez si quoi que ce soit dérivé de vos données quitte le déploiement, télémétrie, échantillons d’évaluation et usage anonymisé compris. Demandez qui d’autre fait tourner les poids que le déploiement utilise, et si vos données les ont jamais touchés.
La mauvaise réponse. « Vos données sont isolées logiquement. » L’isolation logique est une promesse applicative. La séparation est un fait que vous pouvez inspecter.
C’est la liste à laquelle nous voulons être mesurés. Monarch s’installe dans votre infrastructure, sous vos comptes, vos clés et votre juridiction. Nous n’opérons aucun hébergement de vos données. Il n’est jamais partagé : un déploiement, une ontologie, une organisation. Faites les huit tests depuis votre propre réseau. Voyez-le sur vos données.