AI Act : trois approches de conformité, et une seule qui ne vous rend pas tributaire d'un hyperscaler américain

# AI Act : trois approches de conformité, et une seule qui ne vous rend pas tributaire d'un hyperscaler américain

En 2026, l'AI Act est entré en vigueur dans sa quasi-totalité. Les obligations de conformité sont réelles, les délais s'appliquent, et les éditeurs américains ont été prompts à repositionner leurs offres existantes sous l'étiquette « AI Act ready ». Avant de signer, il vaut la peine d'examiner ce que chaque approche implique concrètement — en termes d'architecture, de gouvernance des données, de contrôle opérationnel, et d'exposition budgétaire.

Le cadre de l'analyse

L'AI Act introduit des obligations graduées selon le niveau de risque des systèmes d'IA déployés. Pour les systèmes à risque élevé — recrutement, crédit, accès aux services publics, sécurité d'infrastructure — les exigences portent notamment sur : la traçabilité des décisions automatisées, la documentation technique des modèles, la supervision humaine effective, la gestion des biais, et la conservation des logs dans des conditions auditables.

Ces exigences ne sont pas neutres du point de vue de l'architecture. Elles supposent un contrôle réel sur les données traitées, sur les modèles utilisés et sur les journaux produits. C'est précisément là que les trois approches divergent.

Approche 1 — La conformité déléguée à l'hyperscaler américain

C'est l'option que les acteurs dominants US proposent sous des noms variés : suites de gouvernance IA intégrées à leurs plateformes cloud, tableaux de bord de conformité, modules d'audit automatisé. Le principe : la conformité est traitée comme une couche de service supplémentaire, facturée en complément de l'infrastructure sous-jacente.

Architecture

Les données restent hébergées dans les environnements cloud de l'éditeur. Les logs d'audit, les métadonnées des modèles et les enregistrements de décisions sont stockés dans des buckets ou des services propriétaires. L'accès à ces données par l'entreprise cliente est conditionné à l'API de l'éditeur — il n'existe pas d'export natif standardisé dans la majorité des offres actuelles.

Gouvernance

L'entreprise cliente signe un contrat de conformité partagée (*shared responsibility model*). En théorie, elle reste responsable de la conformité finale vis-à-vis des autorités européennes. En pratique, la documentation technique des modèles — obligatoire sous l'AI Act pour les systèmes à risque élevé — reste partiellement opaque : les modèles fondateurs utilisés ne sont pas auditables par le client, et les mises à jour de modèles peuvent intervenir sans notification préalable formelle.

Risque budgétaire

C'est ici que l'exposition est la plus structurelle. Les modules de conformité sont facturés séparément de l'infrastructure. Un changement de politique tarifaire de l'éditeur — hausse de licence, restructuration des tiers de service, fin d'un module — place l'entreprise dans une position de dépendance directe : migrer les logs d'audit, les modèles documentés et l'historique de supervision vers une autre solution représente un coût de sortie réel, difficile à anticiper au moment de la signature initiale.

Par ailleurs, la localisation des données dans des régions AWS, Azure ou GCP en Europe ne supprime pas la juridiction américaine sur ces données — en vertu du Cloud Act, toujours en vigueur. Ce point est directement pertinent pour les entreprises soumises au RGPD et à l'AI Act simultanément.

Approche 2 — La conformité via un éditeur européen spécialisé

Depuis 2025, plusieurs acteurs européens ont structuré des offres spécifiquement orientées conformité IA : c'est le cas notamment de Cleyrop (France), qui propose une plateforme de gouvernance de données et d'IA hébergée on-premise ou en cloud souverain européen, ou encore de Dataiku, dont les fonctionnalités de traçabilité et d'audit ont été significativement renforcées en réponse aux exigences de l'AI Act.

Architecture

Les deux modèles permettent un déploiement sur infrastructure maîtrisée par l'entreprise cliente : serveurs internes, cloud privé, ou hébergeurs européens certifiés SecNumCloud. Les logs d'audit sont générés dans des formats ouverts (JSON structuré, standards OCSF ou équivalents), exportables sans dépendance à une API propriétaire.

La documentation technique des modèles — registre des modèles, versioning, traçabilité des jeux de données d'entraînement — est gérée en interne, avec des droits d'accès configurables par l'entreprise elle-même.

Gouvernance

L'entreprise conserve la maîtrise complète de la chaîne de conformité. Elle peut mandater un auditeur tiers sans passer par l'éditeur. La supervision humaine des décisions automatisées est configurable selon ses propres processus métier, sans contrainte imposée par une architecture cloud externe.

Les mises à jour de modèles sont sous contrôle de l'entreprise : aucune modification n'intervient sans validation interne. C'est un point non négligeable pour les systèmes à risque élevé, où l'AI Act exige que tout changement substantiel d'un système déployé soit documenté et potentiellement requalifié.

Risque budgétaire

Le coût initial est plus élevé — intégration, paramétrage, formation des équipes. Mais la structure de coût est prévisible et découplée des décisions tarifaires d'un tiers. Il n'existe pas de dépendance à un écosystème propriétaire pour accéder à ses propres données de conformité.

Approche 3 — La conformité par stack open source auto-hébergée

Une troisième voie existe, adoptée par des équipes IT ayant les ressources internes pour l'assumer : construire une chaîne de conformité à partir de briques open source — MLflow pour le registre de modèles, OpenLineage pour la traçabilité des données, des solutions de monitoring comme Evidently AI pour la détection de biais et de dérive.

Architecture

Totalement maîtrisée. L'entreprise choisit son infrastructure, ses outils, ses formats de stockage. La chaîne peut être auditée de bout en bout, y compris par des autorités nationales de contrôle, sans intermédiaire commercial.

Gouvernance

Maximale en théorie. En pratique, elle suppose une équipe capable de maintenir la stack, d'assurer les mises à jour de sécurité, et de produire elle-même la documentation technique exigée par l'AI Act. Ce n'est pas une option réaliste pour toutes les PME/ETI — elle convient à des organisations avec un niveau de maturité data élevé et des équipes MLOps structurées.

Risque budgétaire

Pas de risque tarifaire externe. En revanche, le coût caché est le temps-homme : la maintenance, la veille réglementaire pour adapter la stack aux évolutions de l'AI Act, et la production de la documentation normative ne sont pas triviales. Pour une ETI sans équipe dédiée, ce coût peut dépasser celui d'une solution packagée.

Tableau comparatif

| Critère | Hyperscaler américain | Éditeur européen spécialisé | Stack open source auto-hébergée |

|---|---|---|---|

| Contrôle des données de conformité | Partiel — dépend de l'API éditeur | Complet — formats ouverts | Complet — maîtrise totale |

| Auditabilité externe | Limitée par l'opacité des modèles tiers | Possible sans intermédiaire | Possible, mais charge interne élevée |

| Conformité Cloud Act / juridiction US | Risque résiduel | Absent si hébergement EU souverain | Absent si infrastructure EU maîtrisée |

| Stabilité budgétaire | Exposée aux décisions tarifaires éditeur | Prévisible — contrat européen | Prévisible — dépend des ressources internes |

| Charge opérationnelle interne | Faible (mais dépendance forte) | Modérée | Élevée |

| Compatibilité AI Act risque élevé | Partielle — documentation modèles opaque | Forte | Forte si ressources disponibles |

Ce que cela implique pour les budgets IT en 2026

La conformité à l'AI Act n'est pas une dépense ponctuelle. C'est une fonction continue : les systèmes évoluent, les modèles dérivent, les périmètres d'usage s'élargissent. Chaque changement substantiel d'un système à risque élevé peut déclencher une obligation de re-documentation, voire de re-qualification.

Choisir l'approche déléguée à un acteur américain, c'est externaliser non seulement la technique, mais la capacité de répondre à ces obligations de manière autonome. Si l'éditeur modifie son architecture, son modèle de facturation ou décide de retirer un module, l'entreprise se retrouve en situation de non-conformité potentielle sans avoir les moyens d'y répondre seule.

Les DSI qui ont commencé à intégrer ce raisonnement dans leurs appels d'offres 2025-2026 posent des exigences nouvelles : portabilité des logs d'audit, documentation technique accessible sans interface propriétaire, clauses contractuelles sur la localisation et la juridiction des données de gouvernance IA. Ce sont des critères que les acteurs européens spécialisés sont structurellement mieux placés pour satisfaire.

L'AI Act, paradoxalement, crée les conditions d'une réévaluation budgétaire que la seule rhétorique souverainiste n'avait pas suffi à déclencher. La conformité réglementaire est un argument concret, mesurable, opposable à la direction générale — là où « reprendre le contrôle de son SI » restait souvent un objectif diffus. C'est peut-être l'ouverture la plus tangible qu'offre cette réglementation aux acteurs européens du marché.