Il n'existe pas de stack sur étagère pour l'IA réglementée
Le marché veut vous vendre une stack. Choisissez un fournisseur, adoptez ses modèles, déployez dans sa région, et vous exploitez des agents d'ici la fin du trimestre. Pour beaucoup d'entreprises, c'est une très bonne réponse.
Sauf que dans une entreprise réglementée, c'est un piège, et la raison n'est pas commerciale. Quels modèles vous avez le droit d'utiliser, et où ils sont physiquement autorisés à tourner, est décidé par votre régime réglementaire et votre propre homologation de sécurité, pas par le défaut d'un fournisseur. Une stack sur étagère encode la réponse de quelqu'un d'autre à une question que seule votre fonction conformité peut trancher. C'est pourquoi elle ne passe jamais la revue.
Une banque soumise à DORA et à des obligations de résidence des données a besoin d'un déploiement fondamentalement différent de celui d'un hôpital, et les deux ont besoin d'autre chose que l'architecture de référence d'un fournisseur. La stack n'est pas un produit qu'on achète. C'est un ensemble de décisions qu'il faut assumer.
Le lock-in est un risque de concentration, pas seulement un risque commercial
Se standardiser sur un seul fournisseur de modèles a l'air d'une simplification prudente. Dans un contexte réglementé, cela crée discrètement un risque auquel votre superviseur s'intéresse activement.
La couche modèle est la partie la plus mouvante de toute la stack. Liez votre architecture à un fournisseur et elle vieillit au rythme de ce fournisseur, hérite de ses pannes et dépend de sa volonté continue de vous servir à des conditions acceptables. Dans une activité non réglementée, c'est une nuisance commerciale. Sous un régime de résilience opérationnelle, la dépendance à un tiers unique et irremplaçable est un risque de concentration, et démontrer que vous n'y êtes pas exposé s'apparente à une obligation.
L'agnosticisme fournisseur n'est donc pas un confort ajouté pour peser dans les négociations. C'est une preuve que votre fonction conformité doit pouvoir produire : voici comment nous contournons n'importe quel fournisseur unique, et voici le chemin testé que nous emprunterions si l'un d'eux devenait inutilisable demain.
La passerelle de modèles rend les fournisseurs interchangeables
La réponse au lock-in est une interface interne unique que tous les agents appellent, derrière laquelle les modèles sont interchangeables. Anthropic, Mistral ou un modèle open source tournant sur vos propres GPU se tiennent tous derrière la même porte. L'agent ne sait pas et ne se soucie pas de qui a répondu.
Trois propriétés séparent une vraie passerelle d'une passerelle décorative.
Un repli documenté et testé. Si un fournisseur est indisponible ou échoue à un contrôle de politique, la passerelle route automatiquement vers une alternative. Une portabilité qui n'a pas été testée avant que vous n'en dépendiez est un slogan, pas un contrôle. Sous un régime de résilience opérationnelle, un repli automatique et testé s'apparente à une exigence.
Au moins trois options portables documentées avant la mise en service. Pas après. Le moment de prouver que vous pouvez bouger, c'est quand vous avez encore le choix de ne pas le faire. Trois options documentées et substituables avant de dépendre de l'une d'elles, c'est ce qui transforme « nous pourrions changer » en « nous avons changé, voici le runbook ».
Un routage par sensibilité, pas par commodité. La passerelle décide où une charge peut tourner d'après les données qu'elle porte, pas d'après le fournisseur le moins cher ou le plus rapide du jour. Cette décision relève de la section suivante, parce que c'est celle que les régulateurs scrutent le plus.
La topologie de déploiement est une décision de souveraineté, routée par classe
Voici ce que la plupart des architectures de référence ratent : elles choisissent une seule topologie de déploiement pour tout. C'est ainsi qu'on finit soit par sur-contraindre du travail bon marché et non sensible, soit, bien pire, par laisser des données réglementées atteindre un endroit où elles n'auraient jamais dû aller.
La topologie n'est pas une décision. C'est une règle de routage. Les données sont classées par sensibilité, et la classification décide de la topologie.
| Contrainte rencontrée | Topologie | Ce que vous gagnez | Ce que vous acceptez |
|---|---|---|---|
| Charges non sensibles, cloud autorisé | Cloud (compte BYO) | Élasticité, charge d'exploitation minimale | Les données quittent votre compte vers la région du modèle, si permis |
| Données réglementées, cloud autorisé avec règles de résidence | VPC, région épinglée | Les données restent dans votre périmètre et votre région cloud | Vous exploitez la frontière et le routage |
| Règles interdisant le traitement externe | On-premises | Contrôle physique total | La planification de capacité et l'exploitation GPU sont à vous |
| Sensibilité maximale, isolation imposée | Air-gapped | Aucun chemin de sortie | Les mises à jour de modèle et l'exploitation sont manuelles et délibérées |
La règle se place au-dessus du tableau : classez la donnée, puis le tableau vous dit où cette classe peut tourner. Un même processus métier peut contenir à la fois des étapes sensibles et non sensibles, donc le routage se fait par étape, pas une fois pour tout le système.
La posture qui rend cela défendable est un routage de souveraineté qui échoue en fermé. Les données réglementées et personnelles restent par défaut dans votre périmètre. Seules les charges explicitement non sensibles peuvent atteindre un modèle en région externe, et seulement si vous l'avez autorisé. Quand une classification est incertaine, le système traite la donnée comme sensible et la garde à l'intérieur. Le défaut vous protège, et il faut une décision délibérée et journalisée pour l'assouplir. « Vos données ne quittent jamais vos murs » n'est alors pas une phrase marketing. C'est une architecture où la sortie est refusée par défaut et permise seulement par politique.
Posséder la stack, c'est posséder la sortie
L'agnosticisme fournisseur et le déploiement partout ne tiennent que si vous pouvez les prouver sous pression, ce qui veut dire que la sortie doit être réelle, pas rhétorique.
Deux choses empêchent une plateforme héritée de devenir discrètement le lock-in que vous vouliez éviter. Toutes deux relèvent du contrat, par écrit.
Séquestre et sortie testée. Sources et poids en séquestre, et un plan de sortie documenté et testé. Un chemin de migration jamais répété est un souhait, pas une garantie.
L'actif est à vous. Le runtime gouverné et les agents sont à vous d'exploiter. Votre feuille de route continue d'avancer quand le partenaire d'implémentation s'en va. Un partenaire sérieux s'astreint à être un tiers remplaçable au sens des règles de vos régulateurs, parce que c'est exactement ce que ces règles exigent de vos fournisseurs critiques.
L'enjeu n'est pas que vous deviez construire chaque couche vous-même. Reconstruire une passerelle de modèles, un moteur de politique et un tissu de déploiement à partir de zéro représente environ un an de plomberie difficile, l'essentiel dans les détails de sécurité et de conformité qu'un régulateur inspecte. L'enjeu, c'est que quel que soit le constructeur, les décisions restent les vôtres : quels modèles, exécutés où, déplacés comment. Ce sont des décisions de conformité habillées en ingénierie.
La question n'est donc pas « quelle stack devons-nous adopter ? ». C'est : si notre fournisseur de modèle principal devenait inutilisable demain, pour une raison commerciale, réglementaire ou de panne, quel est le chemin testé vers le suivant, et est-il documenté avant la mise en service ? Si vous ne pouvez pas répondre par modèle et par classe de données, vous n'avez pas encore de décision de déploiement. Vous avez un espoir de déploiement.
Si vous voulez cartographier vos classes de données sur les topologies permises pour un processus réel, prenez rendez-vous.