Pourquoi les déploiements d'IA on-prem s'enlisent en phase d'achats (et le cadrage qui débloque la situation)

À compter du 2 décembre 2027, les obligations du déployeur au titre de l'EU AI Act s'appliqueront aux systèmes d'IA à haut risque utilisés dans la biométrie, les infrastructures critiques, l'éducation, l'emploi, la migration, l'asile et le contrôle aux frontières ^[1]. Les équipes conformité ne se positionnent pas en attendant décembre 2027 ; en 2026, elles rédigent déjà leurs questionnaires de diligence fournisseur, et les achats d'IA en entreprise s'enlisent sur ces questionnaires à une cadence qui n'a que peu à voir avec la technologie évaluée. La solution n'est pas une meilleure démonstration. C'est un recadrage de ce que recouvre véritablement la conversation d'achat.

À quoi ressemble réellement un « enlisement » en 2026

La preuve de concept technique est concluante. Le modèle produit des résultats utiles sur la charge de travail réelle du client. L'évaluateur technique rédige une note positive et transmet le dossier aux achats. Puis le dossier dort. Trois semaines plus tard, l'équipe conformité du client revient avec une note : « Nous ne pouvons pas démontrer nos obligations de déployeur sur ce workflow si l'inférence se produit sur un point d'extrémité que nous ne contrôlons pas. »

L'enquête d'a16z auprès des entreprises a identifié la forme de ce schéma alors qu'il se dessinait : des cycles de vente qui « prenaient autrefois plus d'un an à conclure se font désormais en 2 ou 3 mois » pour les produits qui répondent aux nouvelles exigences ^[4]. L'implication vaut dans l'autre sens également. Les achats pour les produits qui ne répondent pas aux nouvelles exigences prennent encore une année entière. Des pilotes techniques solides n'y changent rien.

Ce que les achats doivent réellement démontrer

L'EU AI Act distingue le fournisseur d'un système d'IA et son déployeur ^[1]. Une banque qui s'appuie sur une API LLM tierce pour noter des demandes de prêt est le déployeur. Les obligations du déployeur incluent la supervision humaine, la surveillance, le signalement des incidents et la capacité de démontrer ces dispositifs sur demande. Ces obligations incombent à la banque, pas au fournisseur du LLM — et l'équipe achats de la banque constitue la surface où le choix du fournisseur détermine si les obligations sont concrètement satisfiables.

Cette dynamique n'est pas propre à l'UE. Le NIST a publié une note conceptuelle pour un AI RMF Profile sur l'IA digne de confiance dans les infrastructures critiques le 7 avril 2026 ^[2], premier cadrage fédéral des obligations du déployeur au titre du NIST AI RMF pour les opérateurs d'infrastructures critiques aux États-Unis. L'AI Policy Observatory de l'OECD maintient un référentiel évolutif « provenant de plus de 80 juridictions et organisations » ^[3]. La convergence transjuridictionnelle sur les obligations côté déployeur est la tendance de fond, pas une exception.

Les équipes achats des secteurs réglementés lisent ces signaux et se positionnent par anticipation. Elles ne peuvent pas attendre le 2 décembre 2027 pour découvrir si l'architecture d'un fournisseur leur permettra de satisfaire à leurs obligations.

Pourquoi « nous sommes SOC 2 » est la mauvaise réponse

La réponse fournisseur qui résolvait historiquement les conversations d'achats en entreprise — SOC 2 Type II, ISO 27001, DPA aligné RGPD — traite des contrôles côté fournisseur. Ils sont nécessaires. Ils ne sont pas suffisants pour les obligations du déployeur qui s'imposent désormais.

Les obligations du déployeur lui imposent de démontrer, sur demande, quelles données ont transité par le système d'IA. C'est une question qui porte sur les journaux du déployeur lui-même, pas sur ceux du fournisseur. Un fournisseur certifié SOC 2 qui détient le prompt et la réponse dans un cloud managé ne peut pas combler ce manque, car celui-ci se situe du côté déployeur de la frontière : le déployeur ne peut pas produire le journal d'une chose qu'il ne voit pas.

C'est le décalage structurel qui enlise la conversation d'achats. L'équipe conformité rédige une note portant sur les obligations du déployeur. Le fournisseur répond avec des certifications côté fournisseur. Les deux navires se croisent sans se voir.

Le cadrage qui débloque la situation

Trois propriétés de l'architecture de déploiement, nommées en amont dans le questionnaire fournisseur, font tomber l'enlisement :

1. Inférence locale au déployeur. Soit sur l'appareil de l'utilisateur, soit sur un serveur exploité par le déployeur. Les prompts et les réponses ne quittent jamais le périmètre du déployeur.
2. Journaux d'audit sans contenu, détenus par le déployeur. Toute action administrative est journalisée avec horodatage et acteur, dans le SIEM du déployeur. Aucun prompt ni réponse n'apparaît dans la ligne d'audit. La ligne constitue la preuve ; le contenu reste à la main du déployeur, conservé selon sa propre politique de rétention.
3. Identité via l'IdP du déployeur. OIDC adossé à Microsoft Entra ID ou Google Workspace. Les contrôles d'accès et politiques SSO existants du déployeur s'appliquent sans changement.

Ce ne sont pas des propriétés fournisseur à certifier. Ce sont des propriétés d'architecture de déploiement à spécifier. Une fois le questionnaire fournisseur cadré autour d'elles, la note de conformité s'écrit d'elle-même : chaque obligation du déployeur a une propriété architecturale correspondante sur laquelle il peut s'appuyer.

À quoi cela ressemble dans la forme que nous livrons

L'AI Suite de Software Tailor se livre sous forme d'installateurs de bureau qui dialoguent avec un processus d'inférence local. AI Admin Console est la surface de gestion qu'utilise l'équipe IT du déployeur pour appliquer la politique, gérer les licences et exposer l'audit. Six clients du Fortune Global 500 dans la pharmacie, la finance, le gouvernement, le juridique, la défense et l'énergie ont déployé selon cette forme depuis 2007 (clients antérieurs), et chacun de ces engagements est passé par une version du cadrage ci-dessus avant la signature du contrat.

Le moyen le plus rapide de rendre cela concret est de le dérouler sur une charge de travail réelle. Un pilote gratuit d'une semaine place le modèle sur le matériel du client, la ligne d'audit dans le SIEM du client et l'identité via l'IdP du client — de quoi permettre à l'équipe conformité de rédiger sa note face aux obligations qui lui incombent réellement.

Références

1. Commission européenne. « AI Act — Regulatory framework on AI. » digital-strategy.ec.europa.eu. Consulté le 2026-06-03.
2. NIST. « AI Risk Management Framework. » nist.gov/itl/ai-risk-management-framework. Consulté le 2026-06-03. La note conceptuelle sur les infrastructures critiques a été publiée le 7 avril 2026.
3. OECD AI Policy Observatory. « Policy Navigator dashboards. » oecd.ai/en/dashboards. Consulté le 2026-06-03.
4. Andreessen Horowitz. « State of Generative AI in the Enterprise. » a16z.com/generative-ai-enterprise-2024. Publié le 21 mars 2024. Consulté le 2026-06-03.

Articles connexes

• Le basculement du cloud-first vers le residency-first dans les achats d'IA en entreprise
• OECD AI Policy Observatory : ce qui a changé sur les douze derniers mois
• Journaux d'audit sans contenu : comment nous prouvons ce que le modèle a fait sans conserver les prompts
• EU AI Act en 2026 : ce que le déploiement on-prem change à la conformité
• Pourquoi nous livrons l'IA sous forme de binaires installables, et non en SaaS cloud
• Tous les articles →