# L'accès à un modèle est une chaîne d'approvisionnement **Résumé:** Un régulateur peut désormais exiger des documents d'un fournisseur de modèles, mener sa propre évaluation et retirer un modèle du marché. Le choix d'un modèle devient une décision d'approvisionnement. **En bref:** Votre fournisseur de modèles a désormais un régulateur, ce qui en fait un fournisseur comme un autre. **Publié:** 2026-09-10 **Dernière mise à jour:** 2026-09-15 Pendant deux ans, le choix d'un grand modèle de langage s'est discuté en termes de qualité. Lequel raisonne le mieux, lequel coûte le moins par jeton, lequel maîtrise votre langue. Ce sont de vraies questions, et ce ne sont plus les questions intéressantes. La question intéressante est ce qui vous arrive lorsqu'il arrive quelque chose à votre fournisseur. C'était jusqu'ici une hypothèse sans mécanisme. Elle en a désormais un, avec des numéros d'article. ## Ce qui a changé en août Les pouvoirs d'exécution du Bureau européen de l'IA à l'égard des fournisseurs de modèles d'IA à usage général sont devenus exerçables le 2 août 2026. Fin août, ils ont été utilisés pour la première fois. Des demandes d'information ont été adressées à des fournisseurs de modèles, portant sur la façon dont ils empêchent le vol de leurs modèles, sur l'accès accordé aux évaluateurs externes, et sur le suivi des usages une fois un modèle rendu public. La commissaire Henna Virkkunen a décrit ces demandes publiquement. Les destinataires n'ont pas été nommés, et certains fournisseurs ont été écartés au motif qu'un dialogue étroit existait déjà avec eux. Par ailleurs, plus de trente entreprises n'ayant publié aucun résumé de leurs données d'entraînement ont été interrogées sur le droit d'auteur. La lettre d'information sur l'AI Act européen l'a traité sous le titre [Powers in Practice](https://artificialintelligenceact.substack.com/ "The EU AI Act Newsletter, numéro 110, 8 septembre 2026") dans son numéro 110. Rien de spectaculaire en soi. Un régulateur a écrit quelques lettres. Ce qui mérite votre attention, c'est l'échelle sur laquelle ces lettres reposent. ## Les quatre articles qui en font une question d'approvisionnement L'article 91 régit la demande d'information, et c'est ce qui a été employé. L'article 92 permet au Bureau de l'IA de mener sa propre évaluation d'un modèle, y compris par un accès aux API ou au code source. L'article 93 porte sur les mesures, et va jusqu'à restreindre un modèle ou le retirer du marché. L'article 101 porte sur les amendes. L'article 101, paragraphe 1, mérite d'être cité, car le montant est souvent rapporté de façon approximative. Le texte prévoit « 3 % au maximum de leur chiffre d'affaires annuel mondial total réalisé au cours de l'exercice précédent, ou 15 000 000 EUR, le montant le plus élevé étant retenu ». Il mentionne en outre, comme motif autonome, le fait de ne pas donner suite à une demande de document ou d'information. Une précision honnête sur la source : il s'agit du texte consolidé tel que publié, et non du PDF du Journal officiel, qui n'a pas voulu s'afficher pour nous. Lisez-le donc comme le texte de l'article et non comme une copie certifiée. La phrase qui devrait faire évoluer une décision d'architecture ne porte pas sur l'argent. C'est l'article 93 : un modèle peut être restreint, ou retiré du marché. Mesurez ce que cela signifie en aval. Non pas qu'un fournisseur puisse subir une panne, augmenter ses prix, ou déprécier une version avec six mois de préavis. Mais qu'un modèle dont dépend votre produit puisse devenir indisponible pour un motif juridique, selon un calendrier fixé par un autre, sans faute technique de personne. ## C'est du risque fournisseur, et nous savons déjà y penser Chaque autre intrant critique de votre activité présente cette propriété, et vous avez des procédures pour cela. Vous ne vous approvisionnez pas auprès d'une source unique pour un composant qui arrêterait votre chaîne de production. Vous qualifiez un second fournisseur avant d'en avoir besoin. Vous maintenez le coût de bascule assez bas pour que basculer reste une décision et non une crise. Personne n'applique cela au choix d'un modèle, parce que pendant deux ans un modèle a paru relever de la technique et non de l'approvisionnement. C'était une API que l'on appelait. L'idée qu'il ait des régulateurs, des obligations et une existence juridique susceptibles d'évoluer indépendamment de sa qualité ne venait pas, car jusqu'en août aucun instrument ne pouvait agir sur elle. Le contre-argument mérite d'être entendu. Changer de modèle n'est pas changer de vis. Les prompts se comportent différemment, la forme des sorties varie, l'évaluation est à refaire, et une équipe qui change de modèle à la légère livrera des régressions à ses clients. Cette objection est juste, et elle porte sur le coût de bascule, non sur la question de savoir si la substituabilité compte. Si basculer coûte cher, la réponse est de faire baisser ce coût avant d'en avoir besoin, non de conclure que vous n'en aurez jamais besoin. ## Ce que nous avons construit, avec ses limites Unless exploite une Constellation IA de grands modèles de langage de fournisseurs indépendants, hébergés en Europe, avec un registre, un routage entre eux et une bascule automatique. Passer de l'un à l'autre ne change rien à la façon dont circulent les données d'un client. Cette architecture existe en raison d'un seul fait technique, et l'affirmation vaut exactement ce que vaut ce fait, pas davantage. Aucune donnée à caractère personnel réidentifiable n'atteint le modèle génératif. Les identifiants sont filtrés et transformés en jetons au niveau de la passerelle, si bien que le modèle qui formule la réponse reçoit des marqueurs. De ce fait, un modèle est un composant remplaçable et non une dépendance, et en changer n'ajoute personne à la liste des sous-traitants ultérieurs d'un client et n'oblige à refaire aucun contrat en aval. Deux précisions, car la tentation d'en dire trop est forte ici. La capacité, c'est de pouvoir bouger délibérément et vite, non de changer de modèle en permanence. Chaque fournisseur est évalué avant d'entrer dans la rotation, et l'instabilité n'est pas un argument de vente. Le contrôle est ce qu'achète réellement un acheteur en secteur régulé. Et l'hébergement européen est un fait de renfort, non le fait porteur. Il serait commode de laisser entendre qu'un modèle européen échappe de ce fait à toute atteinte, et ce serait faux. Les demandes du Bureau de l'IA touchent aussi les fournisseurs européens, ce qui est le bon résultat et, au fond, tout l'argument. Ce qui protège un client, c'est qu'aucun fournisseur ne soit structurellement indispensable, et non le lieu où ce fournisseur est établi. Cet argument vaut à la couche du modèle et nulle part ailleurs. Nous fonctionnons nous-mêmes sur des régions AWS de l'UE : nous ne sommes donc pas en position de défendre une substituabilité de l'infrastructure, et nous ne le faisons pas. ## La question à laisser mûrir Vous n'avez pas à changer de fournisseur de modèles. La plupart des entreprises ne devraient pas le faire, et pour la plupart des usages le modèle que vous utilisez convient. Ce qui mérite d'être fait, c'est de répondre honnêtement à une question ce trimestre, tant que cela coûte peu. Si le modèle sous votre produit devenait indisponible pour un motif étranger à sa qualité, que feriez-vous, et combien de temps cela prendrait-il ? Si la réponse est un plan, vous avez une chaîne d'approvisionnement. Si la réponse est une pause, vous avez une dépendance. Et il existe désormais un régulateur capable de tester laquelle des deux vous détenez.