L’intelligence artificielle est déjà utilisée pour rédiger des documents, analyser des candidatures, répondre à des clients, générer des images, produire du code ou automatiser certaines opérations. Jusqu’à présent, les entreprises ont surtout choisi leurs outils selon leurs performances, leur prix et leurs conditions de confidentialité. L’AI Act ajoute une nouvelle dimension : le niveau de risque associé à l’usage.

Le règlement européen ne soumet pas toutes les intelligences artificielles aux mêmes obligations. Il distingue les pratiques interdites, les systèmes à haut risque, les usages soumis à des règles de transparence et les applications présentant un risque minimal. Ce sont donc moins les technologies elles-mêmes que leur contexte d’utilisation, les décisions qu’elles influencent et leurs conséquences sur les personnes qui déterminent le cadre applicable.

Pour les entreprises, cette approche modifie la manière de sélectionner un outil, de documenter son fonctionnement et d’organiser la validation humaine. Utiliser une intelligence artificielle ne peut plus être considéré comme une simple décision logicielle prise par un service isolé.

Un règlement fondé sur le niveau de risque

L’AI Act est entré en vigueur le 1er août 2024, avec une application progressive de ses différentes dispositions. Les premières interdictions et les exigences relatives à la maîtrise de l’IA sont applicables depuis février 2025. Les obligations concernant les modèles d’IA à usage général ont commencé à s’appliquer en août 2025. Depuis le 2 août 2026, la Commission européenne et les autorités nationales ont engagé une nouvelle phase d’application du règlement, notamment concernant les obligations de transparence prévues par son article 50.

Le principe central du texte consiste à adapter les obligations au risque réel. Un filtre antispam, un assistant rédactionnel interne et un système utilisé pour sélectionner des candidats ne peuvent pas être évalués de la même façon. Le premier exerce peu d’influence sur les droits d’une personne. Le troisième peut directement affecter son accès à un emploi.

Cette classification oblige les entreprises à partir du cas d’usage. Il ne suffit pas de demander quel modèle est utilisé. Il faut déterminer quelles données lui sont accessibles, quelle décision il prépare, qui reçoit le résultat et quelles conséquences peuvent découler d’une erreur.

Les pratiques interdites

Le niveau le plus strict concerne les utilisations considérées comme incompatibles avec les droits fondamentaux et les valeurs européennes. Certaines pratiques sont interdites plutôt que simplement encadrées.

Le règlement vise notamment certaines formes de manipulation ou de tromperie causant un préjudice significatif, l’exploitation de vulnérabilités liées par exemple à l’âge ou au handicap, ainsi que certaines formes de notation sociale. Il encadre également très strictement plusieurs usages biométriques, la reconnaissance des émotions dans certains contextes professionnels ou éducatifs et la constitution de bases de reconnaissance faciale à partir d’une collecte non ciblée d’images.

Pour une entreprise, la conséquence est directe : une idée techniquement réalisable ne constitue pas nécessairement un usage autorisé. Un outil qui prétendrait déduire l’état émotionnel d’un salarié à partir de son visage ou de sa voix ne doit pas être traité comme un simple module d’analyse. Sa finalité peut le faire entrer dans une catégorie interdite ou fortement réglementée.

Le contrôle doit donc intervenir avant l’achat ou le développement du système. Une expérimentation limitée n’efface pas nécessairement le risque juridique lorsque l’usage lui-même est prohibé.

Les systèmes à haut risque

Les systèmes à haut risque ne sont pas automatiquement interdits. Ils peuvent être utilisés, mais leur conception, leur déploiement et leur supervision doivent répondre à des exigences renforcées.

Cette catégorie peut notamment concerner des systèmes utilisés dans le recrutement, l’éducation, l’accès à certains services essentiels, les infrastructures critiques, la justice, le contrôle des frontières ou certains dispositifs réglementés liés à la santé et à la sécurité.

Prenons le cas des ressources humaines. Un assistant qui reformule une offre d’emploi ne présente pas le même niveau de risque qu’un système qui classe automatiquement les candidatures ou recommande les personnes à écarter. La technologie peut être similaire, mais la seconde utilisation influence directement l’accès à l’emploi.

L’entreprise devra alors mieux documenter le système, ses données, ses limites et ses conditions d’utilisation. Elle devra aussi organiser une supervision humaine réelle, conserver les informations nécessaires à la traçabilité et surveiller le fonctionnement du système dans le temps. Une simple mention indiquant que « l’IA ne fait qu’assister » ne suffit pas si, dans la pratique, les opérateurs suivent systématiquement sa recommandation sans être capables de la remettre en cause.

L’AI Act modifie donc le rôle de la validation humaine. Celle-ci ne peut pas toujours se limiter à un bouton placé à la fin du processus. La personne responsable doit comprendre ce qu’elle valide, disposer d’informations suffisantes et avoir la possibilité effective d’interrompre ou de corriger l’opération.

Les nouvelles obligations de transparence

Depuis le 2 août 2026, certaines obligations de transparence s’appliquent aux systèmes interactifs et aux contenus générés ou modifiés par intelligence artificielle.

Une personne qui échange avec un chatbot doit pouvoir savoir qu’elle interagit avec un système d’IA et non avec un humain, sauf lorsque cette information est déjà évidente compte tenu du contexte. L’objectif est de permettre à l’utilisateur d’adapter son niveau de confiance et de prendre une décision informée.

Les fournisseurs de certains systèmes génératifs doivent également prévoir des mécanismes permettant d’identifier les contenus produits ou manipulés par IA, notamment au moyen de marquages lisibles par machine. Pour les entreprises qui diffusent certains contenus synthétiques, une information compréhensible par le public peut aussi être nécessaire.

Cette évolution concerne directement les communications générées avec l’aide de l’IA. Une image représentant un événement qui n’a jamais existé, une vidéo modifiée ou une voix synthétique reproduisant celle d’une personne ne doivent pas toujours être présentées comme des enregistrements traditionnels.

Le clonage local d’une voix constitue un exemple particulièrement parlant. Une entreprise peut produire une voix off à partir d’échantillons fournis volontairement par son dirigeant, sans envoyer ces fichiers vers une plateforme tierce. Le traitement local répond alors à un objectif de confidentialité et de souveraineté. Il ne supprime toutefois pas la question de la transparence. Selon la nature du contenu et sa qualification juridique, une mention telle que « voix générée localement à partir de la voix du présentateur, avec son autorisation » peut être appropriée.

Le règlement distingue certaines situations artistiques, éditoriales ou manifestement fictives, mais ces exceptions ne doivent pas être interprétées de manière approximative. Le contexte de publication, l’objectif du contenu et le risque de tromperie restent déterminants.

Les usages à risque limité ou minimal

La majorité des systèmes d’intelligence artificielle utilisés en entreprise ne relèveront probablement pas de la catégorie à haut risque. Un outil de traduction, un filtre antispam, un moteur de recherche documentaire interne ou une assistance à la rédaction peuvent généralement présenter un risque limité ou minimal.

Cela ne signifie pas qu’ils échappent à toute règle. Le RGPD continue de s’appliquer aux traitements de données personnelles. Les règles relatives à la propriété intellectuelle, à la protection des consommateurs, à la cybersécurité, à la confidentialité et au droit du travail restent également pertinentes.

Un assistant documentaire interne peut ainsi être considéré comme un usage à faible risque au regard de l’AI Act tout en créant un problème sérieux s’il envoie des contrats, des dossiers clients ou des secrets commerciaux vers un service externe sans cadre approprié. Le règlement ne remplace donc pas les autres obligations. Il ajoute une couche spécifique consacrée aux risques liés à l’intelligence artificielle.

Ce qui change dans les utilisations quotidiennes

La première évolution sera la fin des expérimentations invisibles. Une entreprise doit savoir quels outils sont utilisés, par qui, avec quelles données et pour quelle finalité. L’usage d’un compte personnel ou d’une extension installée sans validation devient plus difficile à concilier avec une gouvernance sérieuse.

La deuxième évolution concerne la qualification des cas d’usage. Les équipes ne peuvent pas simplement déclarer qu’elles utilisent un modèle génératif. Elles doivent distinguer la rédaction, l’analyse, la recommandation et la décision automatisée. Un même modèle peut être associé à plusieurs niveaux de risque selon la fonction qui lui est confiée.

La troisième évolution est documentaire. Les entreprises doivent conserver davantage d’informations sur les systèmes utilisés, les modèles, les fournisseurs, les données accessibles, les instructions, les contrôles humains et les incidents rencontrés. Cette documentation n’est pas une simple formalité administrative. Elle permet aussi de comprendre les dépendances techniques et de reprendre le contrôle lorsqu’un fournisseur, un modèle ou une politique change.

La quatrième évolution concerne les contenus publics. Les services de communication doivent intégrer le signalement de certains contenus synthétiques dans leur processus de publication. L’étiquetage ne devrait pas être ajouté en urgence après la production ; il doit faire partie du workflow, au même titre que la validation éditoriale ou la vérification des droits.

Enfin, les agents capables d’appeler des outils, de modifier des fichiers ou d’interagir avec des systèmes métiers demandent un niveau de contrôle plus précis. Leur classification dépend de leur finalité et de leur contexte, mais leur autonomie augmente naturellement les besoins de traçabilité, d’autorisation et de limitation des accès.

Le rôle de fournisseur ou de déployeur doit être identifié

L’AI Act distingue notamment le fournisseur du système et son déployeur. Une entreprise qui achète un service d’IA et l’utilise dans ses opérations est généralement un déployeur. L’éditeur qui conçoit et commercialise le système est généralement le fournisseur.

Cette répartition peut cependant évoluer. Une entreprise qui modifie substantiellement un système, change sa finalité ou le met sur le marché sous son propre nom peut assumer des responsabilités plus proches de celles d’un fournisseur.

Cette distinction est importante pour les intégrateurs et les entreprises qui développent une couche métier au-dessus d’un modèle existant. Utiliser un modèle open weight ne transfère pas automatiquement toutes les responsabilités à son créateur. L’application finale, son interface, ses données, sa finalité et son mode de déploiement doivent être évalués séparément.

L’IA locale apporte du contrôle, pas une conformité automatique

Une infrastructure locale peut faciliter la maîtrise des données, des modèles et des accès. Elle permet de savoir où l’inférence est exécutée, de limiter les connexions externes, de choisir les informations transmises et de conserver certains journaux dans le périmètre de l’entreprise.

Elle ne rend cependant pas automatiquement un usage conforme à l’AI Act. Un système interdit reste interdit s’il fonctionne dans un serveur privé. Un outil à haut risque reste soumis à des obligations renforcées, même si aucune donnée ne quitte le bâtiment.

La valeur d’une architecture privée réside ailleurs : elle rend certaines décisions techniques plus contrôlables. Les modèles peuvent être identifiés, les flux de données délimités, les droits d’accès appliqués et les actions sensibles soumises à validation.

C’est dans cette logique que s’inscrit la gamme OPA. OPA Core fournit une passerelle privée vers les modèles et sépare les applications des moteurs internes. OPA Companion maintient une distinction explicite entre une proposition de code, son affichage et l’autorisation de l’écrire. OPA Commandor vise à exécuter des agents dans des environnements délimités, avec des outils et des accès associés à leur mission.

Ces mécanismes peuvent soutenir une gouvernance plus précise. Ils ne remplacent ni l’analyse juridique, ni la classification du cas d’usage, ni les procédures organisationnelles exigées par l’entreprise.

Commencer par une cartographie des usages

La mise en œuvre de l’AI Act devrait commencer par une cartographie concrète. Une entreprise doit identifier les systèmes officiellement achetés, mais aussi les comptes personnels, extensions, automatisations et fonctionnalités d’IA déjà intégrées à ses logiciels.

Chaque utilisation doit ensuite être décrite par sa finalité réelle. Il faut déterminer quelles données entrent dans le système, quel résultat en sort, qui l’utilise et quelle décision peut en découler. Cette description permet de distinguer un outil de productivité à faible risque d’un système capable d’influencer les droits d’une personne.

La dernière étape consiste à associer les mesures adaptées au niveau de risque : information des utilisateurs, documentation, validation humaine, limitation des accès, conservation de traces ou interdiction de l’usage.

L’objectif n’est pas de ralentir tous les projets. Il est d’éviter qu’un outil initialement introduit comme une simple assistance devienne progressivement une composante décisionnelle sans que son rôle ait été réévalué.

L’AI Act transforme l’adoption en gouvernance

L’AI Act ne met pas fin à l’utilisation de l’intelligence artificielle en entreprise. Il transforme la manière dont cette utilisation doit être pensée.

Les usages ordinaires restent possibles, mais ils doivent être mieux identifiés. Les systèmes interactifs et certains contenus synthétiques deviennent plus transparents. Les applications à haut risque exigent une documentation, une supervision et une gestion plus rigoureuses. Certaines pratiques sont tout simplement exclues.

Pour les entreprises, le principal changement consiste à passer d’une logique d’adoption d’outils à une logique de gouvernance des usages. Il ne suffit plus de savoir si une intelligence artificielle fonctionne. Il faut pouvoir expliquer ce qu’elle fait, quelles données elle utilise, qui contrôle son résultat et quelles conséquences elle peut produire.

Une infrastructure privée comme OPA peut fournir une base technique plus maîtrisable. La conformité dépend toutefois toujours de l’usage réel, de son niveau de risque et de l’organisation mise en place autour du système.

Cet article présente une lecture générale du cadre européen et ne constitue pas un avis juridique. La qualification d’un système doit être réalisée à partir de son usage, de sa finalité et de sa configuration effective.

Sources

Commission européenne — AI Act, cadre réglementaire européen

Commission européenne — application des nouvelles règles de transparence depuis le 2 août 2026

Commission européenne — lignes directrices sur les obligations de transparence de l’article 50

Construire une utilisation maîtrisée de l’IA

OPA aide les entreprises à rapprocher modèles, données et agents de leur propre infrastructure, avec des périmètres d’accès et des validations explicites. Le point de départ reste une analyse du cas d’usage réel.

Étudier un usage d’IA privée

Tom Cheniaux - rephrased using AI