Le règlement IA européen s'applique : ce qu'une équipe qui met un LLM en production doit avoir en place

---

title: "Le règlement IA européen s'applique : ce qu'une équipe qui met un LLM en production doit avoir en place" seoTitle: "AI Act et LLM en production : quoi mettre en place" description: "Depuis le 2 août 2026, le gros du règlement IA européen est applicable. Voici le tri à faire — fournisseur ou déployeur, haut risque ou non — et les six éléments à avoir réellement en place quand une fonctionnalité LLM tourne déjà en production." seoDescription: "AI Act : le tri entre fournisseur et déployeur, le test du haut risque, et les six éléments à avoir en place quand un LLM tourne déjà en production." date: "2026-09-16" author: "Équipe Raicode" tags: ["IA", "conformité", "architecture", "gestion de projet"] category: "IA & Automatisation" keywords: ["AI Act", "règlement IA européen", "conformité IA entreprise", "LLM en production", "intégration LLM production", "déployeur système IA", "obligations AI Act", "transparence article 50", "haut risque annexe III", "littératie IA"]

La question tombe rarement de la technique. Elle vient du juridique, d'un client grand compte qui fait remplir un questionnaire fournisseur, ou d'un investisseur en due diligence : « notre fonctionnalité IA, elle est conforme ? ». À ce moment-là, la fonctionnalité tourne depuis huit mois, elle traite quelques milliers de requêtes par jour, personne n'a jamais ouvert le texte du règlement, et l'équipe a trois jours pour répondre.

Le réflexe habituel consiste à tout arrêter, à demander un audit juridique à 15 000 €, ou — plus fréquent — à répondre « oui » en espérant que personne ne creuse. Les trois sont de mauvaises réponses. Le règlement européen sur l'intelligence artificielle n'est pas un mur uniforme : c'est une pyramide de risques, et l'écrasante majorité des fonctionnalités LLM qu'on voit en production se situent dans la strate la plus légère. Le vrai travail n'est pas de tout refaire, c'est de savoir précisément dans quelle case on se trouve et d'avoir les quatre ou cinq artefacts qui le prouvent.

Ce qui suit est une grille de lecture technique, pas un avis juridique. Elle sert à préparer la conversation avec votre conseil, pas à la remplacer.

Le calendrier, sans le brouillard

Le règlement est entré en vigueur le 1er août 2024, mais il ne s'est jamais appliqué d'un bloc. Les échéances se sont succédé par paliers :

• 2 février 2025 — les pratiques interdites (notation sociale, manipulation subliminale, moissonnage non ciblé d'images faciales) deviennent illicites, et l'obligation de littératie IA s'applique à tout le monde.
• 2 août 2025 — obligations des fournisseurs de modèles à usage général, gouvernance nationale, régime de sanctions.
• 2 août 2026 — application générale du texte : obligations de transparence, systèmes à haut risque de l'annexe III, surveillance du marché.
• 2 août 2027 — dernier palier, pour les systèmes IA intégrés à des produits déjà soumis à une réglementation sectorielle, et pour les modèles à usage général mis sur le marché avant août 2025.

Le palier d'août 2026 est celui qui concerne le plus d'équipes produit, parce que c'est celui qui porte les obligations de transparence : elles s'appliquent à des systèmes parfaitement banals, un chatbot de support ou un générateur de texte marketing. Le calendrier des obligations haut risque a fait l'objet de discussions d'ajustement au niveau européen ; vérifiez l'état du texte consolidé avant de figer une feuille de route sur ce point précis. Les obligations de transparence et de littératie, elles, sont acquises depuis un moment.

Première question : qui êtes-vous dans le texte ?

C'est le tri qui change tout, et c'est celui que les équipes sautent. Le règlement ne raisonne pas en « entreprises qui font de l'IA ». Il attribue des rôles, et les obligations suivent le rôle.

Le fournisseur développe un système d'IA et le met sur le marché sous son propre nom ou sa propre marque. Le déployeur utilise un système d'IA sous sa propre autorité, dans le cadre d'une activité professionnelle. Il existe aussi des importateurs, des distributeurs et des mandataires, qui concernent surtout les chaînes de distribution matérielles.

Si vous appelez l'API d'un grand fournisseur de modèles depuis votre back-end pour alimenter une fonctionnalité interne — un assistant de rédaction pour vos commerciaux, un résumé automatique de tickets — vous êtes déployeur d'un système bâti sur un modèle à usage général. Le fournisseur du modèle porte l'essentiel de la charge documentaire ; la vôtre est réelle mais courte.

Si vous vendez cette même fonctionnalité à vos clients dans votre SaaS, sous votre marque, vous devenez fournisseur du système d'IA. Vous restez déployeur du modèle sous-jacent, mais vis-à-vis de vos clients, c'est vous le fournisseur. C'est la bascule que la plupart des équipes ne voient pas venir, et elle se produit sans qu'une ligne de code change : elle se produit le jour où le commercial ajoute « assistant IA intégré » sur la page tarifs.

Troisième cas, plus rare mais coûteux : si vous entraînez ou modifiez substantiellement un modèle à usage général — pas un fine-tuning cosmétique sur cinq cents exemples, mais une modification qui change le comportement général du modèle — vous pouvez devenir fournisseur du modèle lui-même, avec la documentation technique, la politique de droits d'auteur et le résumé des données d'entraînement que cela implique. Avant de lancer un fine-tuning « pour améliorer la qualité », posez-vous cette question-là ; elle coûte moins cher avant qu'après.

Ce tri des rôles est aussi la première chose qu'on écrit quand on récupère une base existante. C'est exactement le cadre de notre offre de reprise de projet IA : avant de parler d'architecture ou de coûts, on établit qui est responsable de quoi, parce que la réponse détermine ce qu'il faudra produire et qui devra le signer.

Deuxième question : est-ce du haut risque ?

Le régime lourd du règlement — système de gestion des risques, gouvernance des données, documentation technique, journalisation, surveillance humaine, évaluation de conformité — vise les systèmes à haut risque. Deux familles : ceux qui sont des composants de sécurité de produits réglementés (machines, dispositifs médicaux, jouets), et ceux qui figurent dans la liste de l'annexe III.

Cette liste est courte et concrète. Elle couvre notamment la biométrie, les infrastructures critiques, l'éducation et la formation professionnelle, l'emploi et la gestion des travailleurs, l'accès aux services essentiels publics et privés — dont l'évaluation de solvabilité et la tarification en assurance vie et santé — les autorités répressives, la migration et l'asile, la justice et les processus démocratiques.

Le point que tout le monde rate : ce n'est pas le secteur de votre entreprise qui compte, c'est la fonction de la fonctionnalité. Quelques exemples qui font basculer un produit par ailleurs anodin :

• Un outil de recrutement qui classe les candidatures, même si le classement n'est qu'un « score indicatif ».
• Un module RH qui aide à répartir des tâches, à évaluer la performance ou à décider d'une promotion.
• Une plateforme de formation qui note des devoirs ou détecte la triche pendant un examen.
• Un module de scoring qui conditionne l'accès à un crédit ou à une offre d'assurance.

À l'inverse, le règlement prévoit une échappatoire lorsque le système, bien que couvert par la liste, ne fait qu'une tâche procédurale étroite, améliore le résultat d'une activité humaine déjà achevée, ou se limite à une tâche préparatoire — mais tout profilage de personnes physiques reste, lui, à haut risque. Cette exception se documente : elle exige une évaluation écrite et un enregistrement. Ce n'est pas une case à cocher mentalement pour se rassurer.

Un chatbot de support client, un générateur de descriptions produit, un moteur de recherche sémantique interne, un assistant de rédaction : hors annexe III, donc hors régime haut risque. C'est la situation de quatre fonctionnalités LLM sur cinq, et c'est une bonne nouvelle qu'il faut écrire noir sur blanc dans un document daté plutôt que se répéter en réunion.

Ce qu'il faut avoir en place, même hors haut risque

Voici la liste courte. Elle tient en une semaine de travail pour une équipe qui part de zéro, à condition de ne pas transformer chaque point en projet.

1. La transparence vis-à-vis de l'utilisateur

Une personne qui interagit avec un système d'IA doit le savoir, sauf si c'est évident au vu du contexte. Concrètement : votre chatbot doit s'annoncer comme automatique dès le premier message, et pas dans les CGU en pied de page. Le contenu synthétique — texte, image, audio, vidéo — généré par votre produit doit être marqué dans un format lisible par machine, ce qui veut dire métadonnées ou filigrane technique, pas seulement une mention visuelle. Les contenus d'apparence authentique produits ou modifiés par IA doivent être identifiés comme tels. Si vous faites de la reconnaissance d'émotions ou de la catégorisation biométrique, les personnes concernées doivent en être informées.

Le piège classique : l'escalade vers un humain. Beaucoup de supports basculent du bot vers un agent humain sans jamais l'indiquer, ou l'inverse. L'utilisateur doit pouvoir savoir à qui il parle, à tout moment.

2. La littératie IA

Depuis février 2025, fournisseurs et déployeurs doivent prendre des mesures pour garantir un niveau suffisant de maîtrise de l'IA chez les personnes qui utilisent ces systèmes pour leur compte. Ce n'est pas une formation certifiante ; c'est la capacité, pour un commercial qui utilise un assistant de rédaction, de savoir qu'il peut halluciner et qu'il ne doit pas y coller le contrat d'un client. Une note de deux pages, une session d'une heure, une trace de qui l'a suivie : c'est proportionné et c'est documenté.

3. Le contrat avec votre fournisseur de modèle

Vous avez besoin, par écrit, de quatre choses : la documentation que le fournisseur du modèle met à disposition des intégrateurs, sa politique de conservation des données envoyées par API, un engagement explicite de non-réutilisation de vos données pour l'entraînement, et la localisation du traitement. Ces éléments existent chez tous les grands fournisseurs, mais ils sont répartis entre les conditions d'usage, l'accord de traitement des données et une page de documentation. Rassemblez-les dans un dossier unique — c'est la première chose qu'un questionnaire client demandera.

4. La journalisation qui permet de reconstituer une décision

Le règlement impose la conservation des journaux aux systèmes à haut risque. Hors haut risque, vous n'y êtes pas tenu — mais le jour où un client conteste une réponse, vous devrez expliquer ce qui s'est passé. Cela suppose d'avoir tracé, par interaction : la version du prompt, l'identifiant du modèle et sa version, les documents récupérés le cas échéant, la sortie brute, et l'horodatage. C'est la même instrumentation qui permet de savoir si votre agent IA est fiable avant de l'exposer aux clients : le travail de conformité et le travail de qualité produisent ici exactement le même artefact, ce qui en fait le point le plus rentable de la liste.

Attention au revers : ces journaux contiennent souvent des données personnelles, parfois davantage que la base de production elle-même. Ils ont besoin d'une durée de conservation, d'un contrôle d'accès et d'une purge, sous peine de résoudre un problème de conformité en en créant un autre.

5. L'articulation avec le RGPD

C'est de loin le risque le plus élevé pour une équipe française, et il est antérieur au règlement IA. Si votre fonctionnalité traite des données personnelles — un chatbot qui reçoit des messages clients en reçoit forcément — il vous faut une base légale, une information des personnes, une analyse d'impact si le traitement est susceptible d'engendrer un risque élevé, et une position claire sur les transferts hors Union européenne. Une base vectorielle constituée par aspiration de documents internes est un traitement de données personnelles comme un autre : elle doit pouvoir être purgée sur demande d'effacement, ce qui suppose de savoir quel document a produit quel fragment. Si votre pipeline de récupération ne sait pas remonter du fragment au document source, vous avez un problème de conformité et, accessoirement, une des causes les plus fréquentes de réponses à côté.

6. La fiche système, en une page par fonctionnalité

Le livrable qui rend tous les autres exploitables. Une page par fonctionnalité LLM, qui répond à : quel est son but, qui en est le fournisseur et qui le déployeur, quelles données entrent et sortent, quel modèle et quel hébergement, est-elle couverte par l'annexe III et pourquoi, quelles mesures de transparence sont en place, qui est responsable en interne. Ce document se rédige en deux heures quand on connaît le système, et il répond à 80 % des questionnaires clients.

Les trois erreurs de raisonnement les plus fréquentes

« Notre serveur est aux États-Unis, donc on n'est pas concerné. » Le champ d'application est territorialement large : il vise aussi les fournisseurs et déployeurs établis hors de l'Union lorsque le résultat produit par le système est utilisé dans l'Union. La localisation de l'infrastructure ne fait pas sortir du texte.

« On est en dessous des seuils, c'est pour les gros. » Il n'y a pas de seuil d'effectif ni de chiffre d'affaires qui exonère des obligations. Le règlement prévoit des mesures d'allègement pour les PME et un plafonnement des amendes au montant le plus faible entre la somme fixe et le pourcentage du chiffre d'affaires — ce qui adoucit la sanction, pas l'obligation. L'ordre de grandeur des amendes : jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial pour les pratiques interdites, 15 M€ ou 3 % pour la plupart des autres manquements, 7,5 M€ ou 1 % pour des informations inexactes fournies aux autorités.

« On mettra ça au propre quand la fonctionnalité sera stabilisée. » C'est le même raisonnement qui fait qu'un POC ne franchit jamais le pas de la production, et il produit le même résultat : les artefacts manquants finissent par devenir un chantier de plusieurs semaines au pire moment. Les six murs qu'on décrit dans pourquoi un POC IA validé ne passe pas en production incluent celui-là, et il est rarement technique.

Ce que ça coûte vraiment

Pour une fonctionnalité LLM hors haut risque, déjà en production, l'essentiel de la mise en conformité tient en trois à cinq jours-homme : une demi-journée de tri des rôles et de qualification annexe III, une journée pour les mentions de transparence dans l'interface et les métadonnées de contenu généré, une demi-journée pour rassembler la documentation fournisseur, une journée pour la journalisation si elle n'existe pas, une demi-journée pour les fiches système. Le poste le plus lourd est presque toujours la journalisation — et c'est celui qui sert le plus au quotidien, puisqu'il donne enfin de la visibilité sur le comportement réel du système et sur ce qu'il consomme.

Si vous vous retrouvez dans la case haut risque, l'ordre de grandeur n'est plus le même : système de gestion des risques, documentation technique complète, évaluation de conformité, enregistrement dans la base de données européenne. Là, la bonne question n'est pas « comment se mettre en conformité » mais « peut-on reconcevoir la fonctionnalité pour qu'elle sorte de l'annexe III », par exemple en la ramenant à une aide strictement préparatoire avec décision humaine réelle. C'est un arbitrage produit, pas juridique, et il se prend avant d'écrire le code.

Par où commencer cette semaine

Prenez la liste de vos fonctionnalités qui appellent un modèle de langage — vous en aurez probablement plus que prévu, en comptant les scripts internes et les intégrations no-code montées par les équipes métier. Pour chacune, répondez à trois questions : sommes-nous fournisseur ou déployeur, la fonction figure-t-elle à l'annexe III, l'utilisateur sait-il qu'il parle à une machine. Trois colonnes, une ligne par fonctionnalité, une heure de travail.

Ce tableau vous dira immédiatement où se trouve le vrai sujet. Dans la majorité des cas, il n'y en a qu'un ou deux, et ils se traitent en quelques jours. Le coût de ne pas faire ce tableau, lui, se paie au moment où un client grand compte suspend une signature en attendant votre réponse.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.