Au 2 décembre 2027, les obligations des déployeurs en vertu du règlement européen sur l'IA s'appliquent 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é en 2026 n'attendent pas décembre 2027 pour se positionner. Elles rédigent dès maintenant des questionnaires de diligence envers les fournisseurs, et les achats d'IA en entreprise butent sur ces questionnaires à un rythme qui a très peu à voir avec la technologie achetée. La solution n'est pas une meilleure démonstration. C'est un recadrage de ce dont la conversation d'achat parle réellement.

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

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

L'enquête entreprise d'a16z a identifié la forme de ce schéma en formation : des cycles de négociation qui « prenaient auparavant plus d'un an à se conclure sont désormais accélérés en 2 ou 3 mois » pour les produits répondant aux nouvelles exigences [4]. L'implication fonctionne aussi dans l'autre sens. Les achats pour des produits ne répondant pas aux nouvelles exigences prennent toujours un an. De solides pilotes techniques ne changent rien à cela.

Ce que l'on demande réellement aux achats de justifier

Le règlement européen sur l'IA distingue entre le fournisseur d'un système d'IA et le déployeur de celui-ci [1]. Une banque utilisant une API LLM tierce pour évaluer 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 démonstration de ces capacités sur demande. Ces obligations s'appliquent à la banque, pas au fournisseur du LLM — et l'équipe achats de la banque est le point de contact où la sélection du fournisseur décide si les obligations sont pratiques à satisfaire.

Cette orientation n'est pas propre à l'UE. Le NIST a publié une note conceptuelle pour un profil AI RMF sur l'IA digne de confiance dans les infrastructures critiques le 7 avril 2026 [2], la première définition fédérale des obligations des déployeurs AI RMF pour les opérateurs d'infrastructures critiques aux États-Unis. L'Observatoire des politiques d'IA de l'OCDE maintient un référentiel vivant « provenant de plus de 80 juridictions et organisations » [3]. La convergence inter-juridictionnelle sur les obligations côté déployeur est la tendance, pas une exception.

Les équipes achats dans les secteurs réglementés lisent ces signaux et se positionnent à l'avance. Elles ne peuvent pas attendre le 2 décembre 2027 pour savoir si une architecture fournisseur leur permettra de satisfaire leurs obligations.

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

La réponse axée sur le contrôle fournisseur qui a historiquement résolu les discussions d'approvisionnement en entreprise — SOC 2 Type II, ISO 27001, DPA conforme au RGPD — concerne les contrôles côté fournisseur. Ils sont nécessaires. Ils ne suffisent pas aux obligations du déployeur qui apparaissent désormais.

Les obligations du déployeur exigent que celui-ci démontre, sur demande, quelles données ont transité par le système d'IA. Il s'agit d'une question portant sur les propres journaux du déployeur, non sur ceux du fournisseur. Un fournisseur conforme SOC-2 qui détient la requête et la réponse dans un cloud géré ne peut combler cette lacune, car celle-ci se situe du côté du déployeur : ce dernier ne peut produire un journal de quelque chose qu'il ne voit pas.

C'est ce décalage structurel qui bloque la conversation d'approvisionnement. L'équipe conformité rédige une note contre les obligations du déployeur. Le fournisseur répond avec des certifications côté fournisseur. Les deux positions passent à côté l'une de l'autre.

Le cadre qui résout le blocage

Trois propriétés de l'architecture de déploiement, nommées dès le départ dans le questionnaire fournisseur, font disparaître le blocage :

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

Ce ne sont pas des propriétés du fournisseur à certifier. Ce sont des propriétés de l'architecture de déploiement à spécifier. Une fois le questionnaire fournisseur cadré sur ces points, la note de conformité s'écrit d'elle-même : chaque obligation du déployeur correspond à une propriété architecturale que le déployeur peut indiquer.

À quoi cela ressemble dans la forme que nous livrons

AI Suite de Software Tailor est livré sous forme d'installateurs de bureau qui communiquent avec un processus d'inférence local. AI Admin Console est la surface de gestion utilisée par l'équipe informatique du déployeur pour appliquer la politique, gérer les licences et afficher l'audit. Six clients du Fortune Global 500 dans les secteurs pharmaceutique, financier, gouvernemental, juridique, défense et énergie ont déployé selon cette forme depuis 2007 (anciens clients), et chacun de ces engagements a suivi une version du cadre ci-dessus avant la signature du contrat.

La manière la plus rapide de concrétiser cela est de le parcourir 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 — suffisant pour que l'équipe conformité rédige la note contre les obligations auxquelles elle est réellement confrontée.

Références

  1. Commission européenne. « Loi sur l'IA — Cadre réglementaire sur l'IA. » https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consulté le 03-06-2026.
  2. NIST. « Cadre de gestion des risques liés à l'IA. » https://www.nist.gov/itl/ai-risk-management-framework. Consulté le 03-06-2026. La note conceptuelle sur les infrastructures critiques a été publiée le 7 avril 2026.
  3. Observatoire des politiques de l'OCDE sur l'IA. « Tableaux de bord du Policy Navigator. » https://oecd.ai/en/dashboards. Consulté le 03-06-2026.
  4. Andreessen Horowitz. « État de l'IA générative en entreprise. » https://a16z.com/generative-ai-enterprise-2024/. Publié le 21 mars 2024. Consulté le 03-06-2026.