AI Act en entreprise : méthode concrète pour la DSI

L’AI Act en entreprise n’est pas un sujet juridique à traiter en fin de projet : pour la DSI, c’est un cadre de conception, d’achat et d’exploitation des systèmes d’IA. La bonne approche consiste à cartographier les cas d’usage, classer les niveaux de risque, exiger des preuves aux fournisseurs et mettre en place une gouvernance simple avant la généralisation des agents et du RAG.

Beaucoup d’entreprises ont déjà des assistants internes, des copilotes métiers ou des automatisations dopées aux LLM. Le vrai enjeu n’est plus de savoir s’il faut utiliser l’IA, mais comment le faire de manière exploitable, sécurisée et défendable vis-à-vis des métiers, de la conformité et de la direction générale.

Pourquoi l’AI Act change-t-il la feuille de route IA de la DSI ?

L’AI Act est le règlement européen qui encadre certains usages de l’intelligence artificielle selon une logique fondée sur le risque. En pratique, il oblige les entreprises à ne plus considérer l’IA comme une simple brique logicielle : il faut documenter, tracer, superviser et parfois limiter certains usages.

Pour une DSI, cela change trois choses.

• Le cadrage : un cas d’usage IA doit être qualifié dès le départ.
• Les achats : un fournisseur d’IA doit fournir des garanties techniques et documentaires.
• L’exploitation : un système d’IA doit être surveillé comme un service critique, avec journalisation, contrôle des accès, gestion des incidents et revue régulière.

Autrement dit, la question n’est pas seulement : "Le modèle répond-il bien ?" La vraie question devient : "Pouvons-nous prouver comment il fonctionne, avec quelles données, quels garde-fous et quelle supervision humaine ?"

C’est pour cela que l’AI Act concerne directement les DSI, les équipes data/IA, la sécurité, les achats et les directions métiers. Il touche la gouvernance autant que l’architecture.

Quels cas d’usage IA sont réellement sensibles en entreprise ?

Tous les projets IA ne se valent pas. Un assistant de recherche documentaire interne n’expose pas le même niveau de risque qu’un système influençant un recrutement, une décision d’octroi ou un contrôle de conformité.

Quelques définitions utiles :

• Un système d’IA est un système logiciel qui produit des résultats comme du contenu, des prédictions, des recommandations ou des décisions à partir de données et d’objectifs donnés.
• Un RAG est une architecture qui combine un modèle de langage avec une base documentaire ou un moteur de recherche, afin d’ancrer les réponses dans des sources connues.
• Un agent IA est un système capable d’enchaîner des actions, d’appeler des outils ou des applications et d’agir sur un processus, parfois avec un certain degré d’autonomie.

Le niveau de vigilance dépend surtout de trois facteurs :

1. L’impact sur les personnes.
2. Le degré d’automatisation.
3. L’accès à des données ou systèmes sensibles.

Cas d’usage	Exemple en entreprise	Niveau de vigilance	Points de contrôle prioritaires
Assistant documentaire interne	Recherche dans procédures, contrats, référentiels	Modéré dans beaucoup de cas	Qualité des sources, droits d’accès, traçabilité des réponses
Agent de support IT	Création de tickets, exécution de scripts, accès CMDB	Élevé côté sécurité et exploitation	Gestion des privilèges, validation humaine, journalisation
Copilote RH	Aide au tri ou à la présélection de candidatures	Très sensible, à examiner de près	Biais, explicabilité, supervision, base légale, preuves fournisseur
Scoring métier	Priorisation de dossiers, risque client, détection d’anomalies	Souvent sensible selon le contexte	Documentation, qualité des données, revue humaine, tests
Assistant commercial externe	Réponses clients, résumé d’échanges, rédaction d’offres	Sensible côté image et données	Contrôles de contenu, confidentialité, validation métier

Le point clé : un même modèle peut être acceptable dans un contexte et problématique dans un autre. Ce n’est pas uniquement la technologie qui compte, mais l’usage réel dans le processus métier.

Comment classer vos projets IA sans sur-réagir ?

Beaucoup d’entreprises tombent dans l’un de ces deux excès :

• tout bloquer par prudence ;
• ou tout traiter comme un simple outil de productivité.

La bonne méthode est de mettre en place une qualification initiale courte, sur une page ou un formulaire, avec des critères stables. Une classification pragmatique peut reposer sur cinq questions.

1. Le système produit-il seulement du contenu ou influence-t-il une décision ?

Un assistant qui propose un brouillon n’a pas le même impact qu’un système qui note, classe ou recommande une action opérationnelle.

2. Le système agit-il seul ou avec validation humaine ?

Un agent qui ouvre un compte, modifie une fiche, déclenche un paiement ou exécute une commande doit être encadré plus fortement qu’un simple copilote.

3. Quelles données manipule-t-il ?

Il faut distinguer :

• données publiques ;
• documents internes ;
• données personnelles ;
• données sensibles au sens métier ou réglementaire ;
• secrets industriels ou informations contractuelles.

Le RGPD reste central dès qu’il y a traitement de données personnelles. L’AI Act ne remplace donc pas les obligations classiques de protection des données : il s’y ajoute.

4. Quel est le périmètre d’accès au SI ?

Un RAG en lecture seule est moins risqué qu’un agent connecté à l’ERP, à l’outil RH, au CRM ou à des systèmes d’administration.

5. Quel dommage concret en cas d’erreur ?

Posez la question simplement :

• perte de temps ?
• erreur financière ?
• impact RH ?
• incident de sécurité ?
• non-conformité réglementaire ?
• atteinte à un client ou à un salarié ?

Avec ces cinq questions, la DSI peut construire une matrice simple : faible, modéré, élevé, critique. Ce n’est pas un avis juridique définitif ; c’est un outil de pilotage pour décider vite et bien.

Quelles preuves et quels contrôles faut-il mettre en place ?

Le sujet central n’est pas seulement la conformité de principe. C’est la capacité de preuve.

Une entreprise doit être capable d’expliquer :

• à quoi sert le système ;
• sur quelles données il s’appuie ;
• quel modèle ou quel fournisseur est utilisé ;
• qui valide les résultats ;
• quels incidents ont eu lieu ;
• quels garde-fous empêchent les usages non prévus.

Concrètement, voici les éléments à mettre en place.

Un inventaire des cas d’usage IA

C’est la base. Sans registre, la gouvernance reste théorique. L’inventaire doit contenir au minimum :

• nom du cas d’usage ;
• sponsor métier ;
• propriétaire DSI ou data/IA ;
• type de données ;
• modèle ou fournisseur ;
• systèmes connectés ;
• niveau de risque estimé ;
• validation conformité et sécurité.

Une documentation d’architecture

Il faut décrire clairement :

• le flux de données ;
• l’endroit où le prompt est enrichi ;
• les connecteurs utilisés ;
• les mécanismes de filtrage ;
• l’hébergement ;
• la journalisation ;
• le rôle des opérateurs humains.

Pour un agent IA, cette documentation doit inclure les actions possibles, les permissions et les conditions de déclenchement.

Des contrôles d’accès et de journalisation

Un agent branché au SI sans traçabilité est un risque majeur. Les bonnes pratiques incluent :

• identité de service dédiée ;
• droits minimaux ;
• séparation lecture/écriture ;
• logs horodatés ;
• conservation adaptée aux règles internes ;
• revue périodique des accès.

Une stratégie de test

Tester un système d’IA ne consiste pas seulement à mesurer la qualité des réponses. Il faut aussi tester :

• les hallucinations ;
• les réponses hors périmètre ;
• les fuites d’information ;
• les contournements de garde-fous ;
• les erreurs d’action outillée ;
• la robustesse en cas de données incomplètes.

Une supervision humaine explicite

La supervision humaine ne doit pas être implicite. Il faut définir :

• qui valide ;
• sur quels cas ;
• selon quels critères ;
• avec quel droit de blocage ;
• et comment la décision humaine est tracée.

Quelle méthode concrète en 6 étapes pour se mettre en ordre ?

Une DSI n’a pas besoin d’attendre un grand programme de transformation pour avancer. Une méthode en six étapes suffit souvent à remettre le portefeuille IA sous contrôle.

1. Recenser les usages réels, y compris ceux déjà lancés

Commencez par les usages visibles, mais cherchez aussi le shadow AI :

• équipes qui utilisent des assistants publics ;
• prototypes faits en métier ;
• connecteurs LLM dans la bureautique ;
• automatisations documentaires non référencées.

Le but est d’obtenir une photographie honnête, pas un inventaire parfait.

2. Qualifier chaque usage avec une grille unique

Appliquez les cinq questions vues plus haut. En moins de 30 minutes, vous devez savoir si le cas d’usage relève :

• d’un déploiement standard ;
• d’un cadrage renforcé ;
• d’un passage obligatoire par sécurité, conformité ou juridique.

3. Exiger un dossier fournisseur minimal

Pour chaque solution achetée ou utilisée via API, demandez un socle documentaire :

• description du service ;
• politique de traitement des données ;
• options de rétention ;
• mesures de sécurité ;
• localisation d’hébergement quand c’est pertinent ;
• éléments de documentation sur les limites du système.

Dans certains contextes sectoriels, les exigences internes peuvent aussi croiser des cadres comme NIS2, DORA ou des attentes de souveraineté. Là encore, le sujet n’est pas seulement technique : il concerne le niveau de contrôle attendu sur un service critique.

4. Standardiser les garde-fous techniques

Créez un socle réutilisable pour éviter que chaque équipe réinvente sa propre sécurité :

• passerelle d’accès aux modèles ;
• filtrage des prompts et des sorties ;
• coffre de secrets ;
• journalisation centralisée ;
• validation humaine sur les actions sensibles ;
• patterns RAG de référence.

C’est exactement le type d’accélérateur qu’une société de conseil et d’expertise IT peut industrialiser avec la DSI, en s’appuyant sur nos expertises et, si besoin, sur nos solutions.

5. Mettre en place une gouvernance légère mais réelle

Le bon format n’est pas forcément un grand comité mensuel. Il faut surtout :

• un sponsor exécutif ;
• un point d’entrée DSI/data/IA ;
• un référent sécurité ;
• un relais conformité ;
• des règles de go/no go.

Une gouvernance légère fonctionne si les rôles sont clairs et si les exceptions sont tracées.

6. Passer en revue les usages tous les trimestres

Un cas d’usage IA évolue vite : nouveaux connecteurs, extension de périmètre, montée en charge, changement de modèle, ajout d’un agent. Un projet initialement peu sensible peut devenir critique après quelques itérations. La revue périodique évite cet angle mort.

Comment encadrer les agents IA et le RAG sans freiner les métiers ?

Le RAG et les agents IA sont souvent les deux trajectoires les plus demandées par les directions métiers.

• Le RAG répond au besoin de fiabilité documentaire.
• Les agents répondent au besoin d’automatisation et d’action.

Leur gouvernance ne doit pas être identique.

Pour un RAG

Les priorités sont :

• la qualité des sources ;
• la fraîcheur des documents ;
• la gestion des droits d’accès ;
• la citation des sources ;
• le contrôle des réponses hors corpus.

Un bon RAG n’est pas seulement un moteur de réponse. C’est un service documentaire gouverné.

Pour un agent IA

Les priorités changent :

• inventaire des outils appelés ;
• politique de permissions ;
• validation humaine avant action sensible ;
• limites de budget, de temps ou d’itérations ;
• journal détaillé des actions ;
• plan de repli en cas d’erreur.

En clair : un agent est plus proche d’un opérateur logiciel supervisé que d’un simple chatbot.

C’est souvent ici que les projets dérapent. L’agent paraît spectaculaire en démonstration, mais devient risqué dès qu’il touche à un annuaire, une base client, un outil RH ou un système financier. Le bon réflexe n’est pas d’interdire, mais de séparer clairement les capacités de lecture, de recommandation et d’action.

Pour les DSI, la question n’est donc pas "LLM ou non ?" mais "quelle architecture, quels garde-fous et quelle exploitabilité ?" Si vous travaillez déjà sur ces sujets, vous pouvez aussi prolonger la réflexion dans Le Lab ou parler à un expert pour cadrer rapidement un cas d’usage concret.

Quel rôle pour la DSI, les métiers et la conformité ?

Un projet IA échoue rarement faute de modèle. Il échoue plus souvent faute de répartition claire des responsabilités.

La répartition la plus saine ressemble à ceci :

• Le métier définit l’objectif, les critères de valeur et les décisions qui peuvent ou non être assistées.
• La DSI sécurise l’intégration, l’identité, les accès, l’exploitation et la réversibilité.
• L’équipe data/IA conçoit l’architecture, les évaluations, les garde-fous et le cycle de vie du système.
• La sécurité valide le niveau d’exposition et les contrôles techniques.
• La conformité ou le juridique aide à qualifier les obligations et à formaliser les preuves.

Quand cette répartition est posée dès le cadrage, la mise en production va plus vite. Quand elle n’existe pas, le projet reste bloqué entre enthousiasme métier et prudence réglementaire.

En résumé

• L’AI Act doit être traité comme un sujet d’architecture et d’exploitation, pas seulement comme un sujet juridique.
• Tous les cas d’usage IA n’ont pas le même niveau de risque : le contexte métier compte autant que la technologie.
• Un inventaire des usages, une grille de qualification et un socle de garde-fous permettent d’avancer vite sans perdre le contrôle.
• Les agents IA demandent un niveau de supervision plus fort que les assistants documentaires ou les RAG en lecture seule.
• La capacité de preuve — documentation, logs, rôles, tests — devient aussi importante que la performance du modèle.

Vous voulez classer vos cas d’usage IA, sécuriser un agent ou cadrer une gouvernance simple et exploitable ? Échangez 30 minutes avec un expert Abalsia : nous pouvons vous aider à passer du prototype à un dispositif robuste, aligné avec vos contraintes métier, sécurité et conformité.