
Intelligence artificielle
Audit IA : comment cartographier vos systèmes pour l'AI Act
Audit IA : comment cartographier vos systèmes pour l'AI Act
Eric Draperi


Si quelqu'un vous demandait aujourd'hui de lister exhaustivement tous les systèmes d'intelligence artificielle actifs dans votre SI (qui les opère, sur quelles données, avec quel niveau d'autonomie), combien de temps vous faudrait-il pour répondre avec certitude ?
C'est exactement la question que pose l'AI Act. Et c'est précisément ce qu'un audit IA interne permet de résoudre. Ce n’est pas un exercice de conformité de plus, mais bien une démarche de gouvernance structurée, qui commence par cartographier ce que vous avez, pour piloter ce que vous faites.
Cet article vous en donne la méthode, étape par étape.
En bref
L'AI Act qualifie chaque organisation utilisant l'IA comme "déployeur", avec des exigences calibrées selon le niveau de risque de chaque usage.
Cartographier exhaustivement ses systèmes IA suppose de combiner trois sources : l'audit DSI, le sondage des métiers, et l'analyse du portefeuille applicatif.
La qualification du risque se fait système par système, selon quatre niveaux allant du risque minimal au risque inacceptable.
Poser la gouvernance (responsable désigné, comité de pilotage) est un prérequis à la cartographie, pas une étape qui suit.
La conformité est une capacité à maintenir, pas un état à atteindre, car un audit prend une photo à un instant donné, alors que le SI évolue en continu.
Les organisations les plus avancées transforment l'audit ponctuel reconduit chaque année en portefeuille IA vivant, piloté en continu.
Qu'est-ce qu'un audit IA interne, et pourquoi l'AI Act le rend incontournable ?
Un audit IA interne est une démarche structurée d'identification, de qualification et de documentation de l'ensemble des systèmes d'intelligence artificielle actifs dans le SI d'une organisation - qu'ils aient été développés en interne, achetés en SaaS ou intégrés via des solutions tierces.
L'AI Act en a fait une nécessité réglementaire. Premier cadre juridique mondial dédié à l'IA, il ne s'applique pas qu'aux éditeurs de logiciels : toute organisation qui utilise un système d'IA dans un contexte professionnel est considérée comme déployeur. Sa logique centrale est celle de la proportionnalité : les exigences sont calibrées selon le risque potentiel de chaque usage, système par système.
C'est une logique de portefeuille, ce qui suppose, en premier lieu, de savoir ce que votre portefeuille contient.

Comment vous mettre en conformité avec l'AI Act ?
Télécharger le guide
L'IA fantôme : ce que votre DSI ne voit pas encore
L'IA fantôme (ou “shadow AI”) désigne l'ensemble des usages IA déployés dans votre organisation sans validation ni recensement par la DSI. Elle s'installe par accumulation de décisions décentralisées : un outil SaaS adopté par les métiers, une API d'IA générative intégrée par un prestataire sans passage en revue Architecture. Résultat : des systèmes actifs, des données mobilisées, des décisions influencées — sans que personne n'en ait de vision d'ensemble.
Ce n'est pas un cas isolé. Selon Flexera (2026), 70 % des responsables IT estiment que les métiers achètent plus d'applications cloud et SaaS que ce dont l'IT a réellement conscience.
Réglementairement, chaque outil non recensé représente une exposition non évaluée, non documentée, non défendable. Le outil de scoring RH acheté en SaaS par la DRH sans passage par la DSI constitue, au sens de l'Annexe III de l'AI Act, un système à haut risque : non qualifié, non supervisé, non documenté. Si les autorités de contrôle venaient à l'identifier, la bonne foi ne suffirait pas à couvrir l'absence de démarche.
Ce que vous ne voyez pas ne peut pas être gouverné. Et ce que vous ne gouvernez pas, vous ne pouvez pas le défendre.
Pour obtenir votre checklist concrète de conformité AI Act et à votre plan d'action de A à Z, téléchargez notre guide.
Fournisseur, déployeur ou les deux ? Ce que l'AI Act attend concrètement de vous
L'AI Act distingue trois rôles réglementaires :
Le fournisseur, qui développe ou met sur le marché un système d'IA
Le déployeur, qui l'utilise dans un contexte professionnel, y compris via un outil SaaS tiers
L'importateur ou le distributeur, qui commercialise des solutions d'origine non-UE.
La DSI cumule fréquemment les trois simultanément : elle est fournisseur lorsqu'elle développe ses propres outils en interne, déployeur lorsqu'elle intègre des solutions tierces dans le SI, et importateur ou distributeur lorsqu'elle redistribue en interne des modèles développés hors UE. Ce qui est le cas de la quasi-totalité des grands modèles de langage.
Ce cumul a une conséquence directe : la DSI ne peut pas déléguer sa conformité AI Act à ses fournisseurs. Même lorsqu'elle achète une solution tierce, elle reste responsable de l'usage qu'elle en fait dans son contexte, de la qualification du risque à la supervision humaine, en passant par la documentation technique.
Le fournisseur est responsable de son système. Le déployeur est responsable de son déploiement. Cette distinction change radicalement le périmètre de votre audit IA : il est, dans la plupart des cas, bien plus large que ce que vous anticipez spontanément.
Comment cartographier exhaustivement vos systèmes IA ?
La cartographie est la colonne vertébrale de votre audit IA en entreprise. Mais elle suppose un prérequis souvent négligé : une gouvernance posée en amont. Sans propriétaire identifié, sans mandat clair, un registre ne sera maintenu par personne... et périmera avant même d'être utile.
Une fois ce cadre posé, il s’agit de prendre le périmètre le plus large possible, en incluant dans votre audit intelligence artificielle :
Les systèmes développés en interne par les équipes IT
Les solutions SaaS intégrant des fonctionnalités IA, qu'elles aient été adoptées par la DSI ou directement par les métiers
Les fonctionnalités IA embarquées dans des solutions tierces (ERP, ATS, CRM), souvent activées silencieusement lors d'une mise à jour
Les systèmes en cours de développement et les projets en cours de planification
Trois sources à combiner pour un recensement sans angle mort
Aucune source unique ne suffit pour réussir votre processus d'audit. La méthodologie recommandée combine trois approches complémentaires :
L'audit DSI : inventaire des systèmes officiels, analyse du portefeuille applicatif existant
Le sondage des directions métiers : identification des usages décentralisés, des outils SaaS adoptés hors DSI, des initiatives IA lancées sans passage en revue Architecture
L'analyse du portefeuille applicatif : détection des fonctionnalités IA activées silencieusement dans des solutions déjà en production
Les trois sont nécessaires. La première source donne le périmètre officiel. La deuxième révèle l'IA fantôme. La troisième attrape ce que les deux premières manquent.
Les variables à documenter pour chaque système identifié
Pour chaque système recensé, un ensemble de variables minimales doit être documenté :
Description et objectif du système
Cas d'usage précis : c'est l'usage qui est qualifié, pas le logiciel
Données mobilisées : nature, origine, sensibilité
Décisions influencées ou automatisées
Responsable désigné
Statut réglementaire : fournisseur ou déployeur
État de déploiement : en production, en développement, en planification
Pour résumer : les pièges classiques qui faussent la cartographie
Ne recensez pas uniquement les systèmes "officiels" DSI : tout ce que les métiers ont adopté de leur côté fait partie du périmètre
Ne négligez pas les fonctionnalités IA embarquées dans vos solutions tierces : ERP, ATS, CRM avec scoring ou recommandation décisionnelle sont souvent les angles morts les plus exposés
Ne confondez pas le logiciel et le cas d'usage : un même outil peut générer des classifications de risque très différentes selon les contextes et les secteurs dans lesquels il est déployé
Ne produisez pas un registre figé sans processus de mise à jour : il sera périmé dès le prochain déploiement ou la prochaine mise à jour fournisseur
Comment qualifier le niveau de risque de chaque usage IA ?
La qualification du risque est le cœur analytique de l'audit IA. L'AI Act structure cette analyse en quatre niveaux, chacun emportant des exigences distinctes.
C'est la bonne nouvelle pour les entreprises qui se lancent dans cette démarche : toutes vos initiatives ne se valent pas réglementairement. L'enjeu est de savoir où se situe chacune d'elles.
La logique de gradation de l'AI Act appliquée à votre portefeuille
Risque inacceptable - interdit depuis février 2025 | Scoring social des citoyens, manipulation subliminale, reconnaissance biométrique en temps réel dans l'espace public. Cette catégorie concerne peu d'entreprises directement, mais mérite vérification (certains systèmes de surveillance ou de profilage comportemental peuvent s'en approcher plus qu'il n'y paraît). |
|---|---|
Haut risque (Annexe III) - échéance au 2 décembre 2027 pour les systèmes standalone | Les exigences sont substantielles : système de gestion des risques documenté (Art. 9), documentation technique conforme à l'Annexe IV, supervision humaine intégrée by design, marquage CE, enregistrement dans la base de données UE. Sanctions : jusqu'à 15 M€ ou 3 % du chiffre d'affaires mondial. |
Risque limité - à partir du 2 août 2026 | Obligations de transparence : tout utilisateur interagissant avec une IA doit en être informé. Le watermarking des contenus synthétiques entre en vigueur au 2 décembre 2026. Sanctions : jusqu'à 7,5 M€ ou 1 % du CA mondial. |
Risque minimal | Aucune obligation spécifique. Mais la frontière avec le risque limité peut être fine : un outil de recommandation qui influence une décision commerciale ou RH peut rapidement changer de catégorie selon son contexte de déploiement. |
Les cas fréquents dans une DSI : RH, scoring, IA générative, SaaS tiers
Dans la pratique, les systèmes à haut risque les plus courants dans une DSI relèvent de quelques domaines bien identifiés par l'Annexe III :
RH et recrutement : tri de CV automatisé, scoring de candidats, évaluation des performances
Services financiers : scoring crédit ou assurantiel
Santé : diagnostic médical assisté par IA
Interfaces conversationnelles : chatbot de support client, agent conversationnel, assistant IA interne sont tous classés en “risque limité”, avec des obligations de transparence à partir d'août 2026
IA générative connectée à un outil métier via API : sa qualification sera à mener selon les décisions qu'elle influence réellement
Documenter la qualification : un élément de conformité à part entière
La traçabilité de la démarche de qualification est en elle-même un élément de conformité. Ce n'est pas seulement le résultat qui compte : c'est la capacité à démontrer comment vous y êtes arrivé, et par qui la décision a été prise.
Pensez donc à :
Documenter chaque qualification : pourquoi ce système a été classé dans telle catégorie, sur quelle base, par qui, à quelle date.
Escalader les cas ambigus au comité de pilotage transversal, et si nécessaire à un expert juridique spécialisé. Une qualification contestable défendue de bonne foi vaut mieux qu'une classification basse non documentée.
Éviter la sous-qualification délibérée : les autorités de contrôle apprécieront la bonne foi dans la démarche, pas l'esquive.
Quelles sont les étapes concrètes pour mettre en œuvre votre audit AI Act ?
Les prérequis essentiels
Avant d'entrer dans le détail des étapes, un prérequis de méthode : traitez votre audit IA comme un projet IT à part entière. Sponsor identifié, équipe constituée, jalons définis, budget alloué - pas un groupe de travail ad hoc qui se réunit entre deux comités.
Mais gardez à l'esprit que ces étapes ne décrivent pas un projet avec une date de fin : elles décrivent la construction d'une capacité permanente. L'objectif n'est pas de "passer" l'AI Act, mais de piloter votre portefeuille IA dans la durée, avec la même rigueur que n'importe quel actif stratégique de votre SI.
Pour les systèmes à haut risque standalone, les quatre premières phases prennent en moyenne quatre à six mois dans une organisation structurée. L'efficacité de la démarche dépend directement du sérieux avec lequel elle est cadrée en amont.
C'est aussi à ce stade que se joue l'adoption interne : une démarche bien cadrée dès le départ génère moins de résistance et des résultats plus durables.
Constituer l'équipe et poser la gouvernance
C'est le point de départ, et l'erreur la plus fréquente est de le sauter pour aller directement à la cartographie. Un registre sans propriétaire n'est maintenu par personne.
La priorité absolue : désigner un responsable conformité IA avec un mandat clair, un accès à la direction générale et une légitimité transversale. Ce rôle peut être porté par le DPO, le RSSI, un consultant spécialisé ou une cellule dédiée... L'essentiel est qu'il soit identifié et doté de ressources.
Autour de lui, un comité de pilotage transversal doit être constitué, réunissant à minima : DSI, DPO, Juridique, Sécurité, et les directions métiers utilisatrices d'IA.
Trois travaux doivent être lancés immédiatement en parallèle :
Formaliser une politique interne de gouvernance IA : périmètre, principes, processus de validation des nouveaux usages
Engager le plan de montée en compétences des équipes : l'obligation de culture IA (Art. 4) est applicable depuis février 2025 - et la montée en compétences des collaborateurs conditionne directement l'efficacité de la conduite du changement
Intégrer la conformité IA aux instances de gouvernance existantes : COMEX, comités de direction IT
Du recensement à la documentation technique
Ces trois phases forment le cœur opérationnel de votre audit IA en entreprise :
Cartographie : recensement exhaustif selon la méthode des trois sources détaillée plus haut, avec constitution d'un registre vivant opposable aux autorités de contrôle.
Qualification : application de la grille AI Act système par système, traçabilité documentée de chaque décision de classification, escalade des cas ambigus. C'est ici que la méthodologie rigoureuse fait toute la différence : une qualification bien documentée est un avantage en cas de contrôle.
Documentation Annexe IV : pour chaque système classé haut risque, la documentation technique est la pièce maîtresse de votre conformité.
Que doit couvrir votre documentation Annexe IV ?
Description générale du système et de ses objectifs
Data d'entraînement, de test et de validation
Métriques de performance et limites connues
Architecture technique et logique de fonctionnement
Mesures de sécurité et de robustesse
Évaluation des risques résiduels
Un point de vigilance opérationnel : toute modification substantielle du système déclenche une mise à jour obligatoire de la documentation. Intégrez ce réflexe dès maintenant dans vos processus de delivery : une documentation à jour au moment du déploiement et périmée six mois plus tard ne vous protège pas.
Gestion des risques et supervision humaine
La gestion des risques requise par l'Article 9 de l’AI Act n’est pas une évaluation ponctuelle à produire avant la mise en production, mais un processus continu tout au long du cycle de vie de chaque système à haut risque. Le quick win ici est de capitaliser sur vos processus de gestion des risques IT existants plutôt que de tout reconstruire. Le lien entre conformité IA et gestion des risques opérationnelle est une opportunité de rationalisation, pas une contrainte supplémentaire.
La supervision humaine est l'autre exigence structurante de l'AI Act pour les systèmes à haut risque. Elle ne signifie pas qu'un humain doit valider chaque décision produite par le système. Le dispositif doit permettre à un collaborateur désigné de comprendre, surveiller et corriger le système si nécessaire.
Ici, trois conditions doivent être réunies :
Intégrer la supervision by design, dès la conception ou l'achat du système.
Tracer les décisions et les interventions humaines : la traçabilité est une exigence réglementaire, pas une option.
Former les auditeurs internes et superviseurs désignés : superviser un système IA suppose de comprendre ses logiques de fonctionnement, ses limites et ses signaux d'alerte.
Construire un pilotage continu
Cette étape est celle qui détermine si votre démarche tient dans la durée ou s'érode dès le premier changement de périmètre.
Concrètement, cela suppose de mettre en place :
Des tableaux de bord de conformité IA : couverture du registre, état de la documentation, alertes sur les systèmes non qualifiés ou à documentation périmée
Des revues régulières du portefeuille : à chaque nouveau déploiement, à chaque modification substantielle, à chaque changement de fournisseur
Une intégration de la conformité IA dans le cycle de vie de chaque nouveau projet IT : un système déployé sans qualification préalable est un problème futur certain
Une remontée aux instances de gouvernance : COMEX, conseil d'administration si pertinent
Pour accéder à la checklist complète de conformité AI Act et à votre plan d'action concret, téléchargez notre guide.

Comment vous mettre en conformité avec l'AI Act ?
Télécharger le guide
Pourquoi un audit IA ponctuel ne suffit pas ?
L'audit IA est une étape nécessaire - pas la destination. La conformité AI Act ne doit pas être traitée comme un projet fermé. Ce serait une illusion de méthode. Et c'est précisément là que se joue la vraie différence entre les entreprises qui maîtrisent leur écosystème IA et celles qui le subissent.
Un audit prend une photo, tandis que votre SI est mouvant
Le SI évolue en permanence : nouveaux outils SaaS adoptés par les métiers, fonctionnalités IA activées automatiquement lors d'une mise à jour fournisseur, agents déployés par des prestataires sans notification DSI. Chaque changement est un angle mort potentiel si la gouvernance n'est pas structurée pour l'absorber.
Ce que l'AI Act exige réellement, ce n'est pas une photo annuelle de votre portefeuille IA : c'est une vision maintenue en continu. Pour chaque système, le règlement impose de relier les agents à leur contexte architectural, de maintenir les responsabilités à jour, de mettre à jour la documentation technique à chaque modification substantielle. Un registre figé, aussi complet soit-il au moment de sa production, est périmé dès le prochain déploiement.
La conformité à l'AI Act n'est pas un état qu'on atteint. C'est une capacité qu'on maintient.
De l'audit ponctuel au portefeuille IA piloté en continu
C'est le vrai changement de paradigme qu'impose l'AI Act. Les approches documentaires statiques (tableurs, audits ponctuels, registres annuels) ont une limite structurelle : elles recensent sans connecter. Elles ne relient pas les systèmes IA à leur contexte architectural, à leurs flux de data, à leurs responsables réels, à leurs processus métier.
Résultat : une documentation formellement présente, et opérationnellement inutile.
Ce qu'il faut construire, c'est un portefeuille IA vivant, pas un audit reconduit chaque année. Un référentiel qui connecte chaque agent à son Architecture, à ses données, à ses responsables, à sa valeur business. Et qui s'adapte automatiquement à chaque changement de périmètre, sans repartir de zéro.
Le lien avec la gouvernance IT existante est ici structurel. Les organisations qui avaient déjà structuré leur portefeuille applicatif et leur gestion des risques IT avant l'AI Act partent avec six à douze mois d'avance.
Pour les autres, les deux chantiers doivent être menés en parallèle. L'AI Act fonctionne comme un révélateur : il met en lumière des lacunes de gouvernance qui existaient bien avant lui - et qu'il aurait fallu corriger de toute façon. Investir dans ce référentiel devient un actif stratégique dont le ROI dépasse largement les exigences réglementaires : alignement stratégique, pilotage du portefeuille, maîtrise des risques opérationnels.
Une gouvernance IA bien structurée aujourd'hui n'est pas seulement une réponse à l'AI Act. C'est un avantage compétitif durable.
Et avec Smoteo, ça donne quoi ?
Smoteo est conçu précisément pour ce passage : de l'audit ponctuel au portefeuille IA piloté en continu. La plateforme structure dans un référentiel unifié tout ce que l'AI Act exige et que votre organisation doit maîtriser dans la durée.
Le Registre des usages centralise en continu tous les outils et initiatives IA actifs par département : contexte applicatif, flux de données, responsables désignés, niveau de risque qualifié
L'AI Value Stream Map cartographie visuellement chaque agent IA dans l'écosystème business et IT, quels domaines il couvre, quelles données il consomme, quelles capacités métier il touche
Les Epic Cards structurent chaque initiative IA dès son origine (objectifs, dépendances, données, risques, valeur business) et constituent directement la base documentaire exigée par l'Annexe IV, sans ressaisie, sans reconstitution en urgence
Le méta-modèle connecte stratégie, Architecture, portefeuille et delivery dans une vue unifiée, pour un pilotage de la conformité intégré au quotidien de la DSI
Résultat : plus de 80 % de couverture des applications, processus et agents dans la cartographie, et une réduction de 30 % du risque de non-conformité avant production.
De l'audit IA à la gouvernance durable : changer de paradigme
L'AI Act n'est pas une contrainte tombée du ciel. C'est la formalisation réglementaire d'un problème que beaucoup de CIO, de DPO et de RSSI connaissent déjà intimement : l'intelligence artificielle se déploie dans les organisations plus vite que la capacité à la gouverner.
Un audit IA interne rigoureux est la première étape pour reprendre le contrôle. Mais ce n'est que le début. Les entreprises qui sortiront renforcées de cette phase réglementaire ne seront pas celles qui auront produit le registre le plus complet avant l'échéance. Ce seront celles qui auront compris que la conformité est un prétexte, et la gouvernance l'enjeu réel. Celles qui auront transformé une obligation réglementaire en infrastructure durable : un portefeuille IA vivant, piloté en continu, aligné sur la stratégie, défendable face aux régulateurs.
Vous souhaitez passer de l'audit ponctuel à un portefeuille IA structuré et piloté en continu ? Smoteo centralise le registre des usages, la cartographie des agents et la documentation technique dans un référentiel unique, maintenu à jour en temps réel. Demandez une démo

Guide pratique
Comment vous mettre en conformité avec l'AI Act ?
Calendrier des obligations, niveaux de risque et checklist complète pour accompagner votre projet
Si quelqu'un vous demandait aujourd'hui de lister exhaustivement tous les systèmes d'intelligence artificielle actifs dans votre SI (qui les opère, sur quelles données, avec quel niveau d'autonomie), combien de temps vous faudrait-il pour répondre avec certitude ?
C'est exactement la question que pose l'AI Act. Et c'est précisément ce qu'un audit IA interne permet de résoudre. Ce n’est pas un exercice de conformité de plus, mais bien une démarche de gouvernance structurée, qui commence par cartographier ce que vous avez, pour piloter ce que vous faites.
Cet article vous en donne la méthode, étape par étape.
En bref
L'AI Act qualifie chaque organisation utilisant l'IA comme "déployeur", avec des exigences calibrées selon le niveau de risque de chaque usage.
Cartographier exhaustivement ses systèmes IA suppose de combiner trois sources : l'audit DSI, le sondage des métiers, et l'analyse du portefeuille applicatif.
La qualification du risque se fait système par système, selon quatre niveaux allant du risque minimal au risque inacceptable.
Poser la gouvernance (responsable désigné, comité de pilotage) est un prérequis à la cartographie, pas une étape qui suit.
La conformité est une capacité à maintenir, pas un état à atteindre, car un audit prend une photo à un instant donné, alors que le SI évolue en continu.
Les organisations les plus avancées transforment l'audit ponctuel reconduit chaque année en portefeuille IA vivant, piloté en continu.
Qu'est-ce qu'un audit IA interne, et pourquoi l'AI Act le rend incontournable ?
Un audit IA interne est une démarche structurée d'identification, de qualification et de documentation de l'ensemble des systèmes d'intelligence artificielle actifs dans le SI d'une organisation - qu'ils aient été développés en interne, achetés en SaaS ou intégrés via des solutions tierces.
L'AI Act en a fait une nécessité réglementaire. Premier cadre juridique mondial dédié à l'IA, il ne s'applique pas qu'aux éditeurs de logiciels : toute organisation qui utilise un système d'IA dans un contexte professionnel est considérée comme déployeur. Sa logique centrale est celle de la proportionnalité : les exigences sont calibrées selon le risque potentiel de chaque usage, système par système.
C'est une logique de portefeuille, ce qui suppose, en premier lieu, de savoir ce que votre portefeuille contient.

Comment vous mettre en conformité avec l'AI Act ?
Télécharger le guide
L'IA fantôme : ce que votre DSI ne voit pas encore
L'IA fantôme (ou “shadow AI”) désigne l'ensemble des usages IA déployés dans votre organisation sans validation ni recensement par la DSI. Elle s'installe par accumulation de décisions décentralisées : un outil SaaS adopté par les métiers, une API d'IA générative intégrée par un prestataire sans passage en revue Architecture. Résultat : des systèmes actifs, des données mobilisées, des décisions influencées — sans que personne n'en ait de vision d'ensemble.
Ce n'est pas un cas isolé. Selon Flexera (2026), 70 % des responsables IT estiment que les métiers achètent plus d'applications cloud et SaaS que ce dont l'IT a réellement conscience.
Réglementairement, chaque outil non recensé représente une exposition non évaluée, non documentée, non défendable. Le outil de scoring RH acheté en SaaS par la DRH sans passage par la DSI constitue, au sens de l'Annexe III de l'AI Act, un système à haut risque : non qualifié, non supervisé, non documenté. Si les autorités de contrôle venaient à l'identifier, la bonne foi ne suffirait pas à couvrir l'absence de démarche.
Ce que vous ne voyez pas ne peut pas être gouverné. Et ce que vous ne gouvernez pas, vous ne pouvez pas le défendre.
Pour obtenir votre checklist concrète de conformité AI Act et à votre plan d'action de A à Z, téléchargez notre guide.
Fournisseur, déployeur ou les deux ? Ce que l'AI Act attend concrètement de vous
L'AI Act distingue trois rôles réglementaires :
Le fournisseur, qui développe ou met sur le marché un système d'IA
Le déployeur, qui l'utilise dans un contexte professionnel, y compris via un outil SaaS tiers
L'importateur ou le distributeur, qui commercialise des solutions d'origine non-UE.
La DSI cumule fréquemment les trois simultanément : elle est fournisseur lorsqu'elle développe ses propres outils en interne, déployeur lorsqu'elle intègre des solutions tierces dans le SI, et importateur ou distributeur lorsqu'elle redistribue en interne des modèles développés hors UE. Ce qui est le cas de la quasi-totalité des grands modèles de langage.
Ce cumul a une conséquence directe : la DSI ne peut pas déléguer sa conformité AI Act à ses fournisseurs. Même lorsqu'elle achète une solution tierce, elle reste responsable de l'usage qu'elle en fait dans son contexte, de la qualification du risque à la supervision humaine, en passant par la documentation technique.
Le fournisseur est responsable de son système. Le déployeur est responsable de son déploiement. Cette distinction change radicalement le périmètre de votre audit IA : il est, dans la plupart des cas, bien plus large que ce que vous anticipez spontanément.
Comment cartographier exhaustivement vos systèmes IA ?
La cartographie est la colonne vertébrale de votre audit IA en entreprise. Mais elle suppose un prérequis souvent négligé : une gouvernance posée en amont. Sans propriétaire identifié, sans mandat clair, un registre ne sera maintenu par personne... et périmera avant même d'être utile.
Une fois ce cadre posé, il s’agit de prendre le périmètre le plus large possible, en incluant dans votre audit intelligence artificielle :
Les systèmes développés en interne par les équipes IT
Les solutions SaaS intégrant des fonctionnalités IA, qu'elles aient été adoptées par la DSI ou directement par les métiers
Les fonctionnalités IA embarquées dans des solutions tierces (ERP, ATS, CRM), souvent activées silencieusement lors d'une mise à jour
Les systèmes en cours de développement et les projets en cours de planification
Trois sources à combiner pour un recensement sans angle mort
Aucune source unique ne suffit pour réussir votre processus d'audit. La méthodologie recommandée combine trois approches complémentaires :
L'audit DSI : inventaire des systèmes officiels, analyse du portefeuille applicatif existant
Le sondage des directions métiers : identification des usages décentralisés, des outils SaaS adoptés hors DSI, des initiatives IA lancées sans passage en revue Architecture
L'analyse du portefeuille applicatif : détection des fonctionnalités IA activées silencieusement dans des solutions déjà en production
Les trois sont nécessaires. La première source donne le périmètre officiel. La deuxième révèle l'IA fantôme. La troisième attrape ce que les deux premières manquent.
Les variables à documenter pour chaque système identifié
Pour chaque système recensé, un ensemble de variables minimales doit être documenté :
Description et objectif du système
Cas d'usage précis : c'est l'usage qui est qualifié, pas le logiciel
Données mobilisées : nature, origine, sensibilité
Décisions influencées ou automatisées
Responsable désigné
Statut réglementaire : fournisseur ou déployeur
État de déploiement : en production, en développement, en planification
Pour résumer : les pièges classiques qui faussent la cartographie
Ne recensez pas uniquement les systèmes "officiels" DSI : tout ce que les métiers ont adopté de leur côté fait partie du périmètre
Ne négligez pas les fonctionnalités IA embarquées dans vos solutions tierces : ERP, ATS, CRM avec scoring ou recommandation décisionnelle sont souvent les angles morts les plus exposés
Ne confondez pas le logiciel et le cas d'usage : un même outil peut générer des classifications de risque très différentes selon les contextes et les secteurs dans lesquels il est déployé
Ne produisez pas un registre figé sans processus de mise à jour : il sera périmé dès le prochain déploiement ou la prochaine mise à jour fournisseur
Comment qualifier le niveau de risque de chaque usage IA ?
La qualification du risque est le cœur analytique de l'audit IA. L'AI Act structure cette analyse en quatre niveaux, chacun emportant des exigences distinctes.
C'est la bonne nouvelle pour les entreprises qui se lancent dans cette démarche : toutes vos initiatives ne se valent pas réglementairement. L'enjeu est de savoir où se situe chacune d'elles.
La logique de gradation de l'AI Act appliquée à votre portefeuille
Risque inacceptable - interdit depuis février 2025 | Scoring social des citoyens, manipulation subliminale, reconnaissance biométrique en temps réel dans l'espace public. Cette catégorie concerne peu d'entreprises directement, mais mérite vérification (certains systèmes de surveillance ou de profilage comportemental peuvent s'en approcher plus qu'il n'y paraît). |
|---|---|
Haut risque (Annexe III) - échéance au 2 décembre 2027 pour les systèmes standalone | Les exigences sont substantielles : système de gestion des risques documenté (Art. 9), documentation technique conforme à l'Annexe IV, supervision humaine intégrée by design, marquage CE, enregistrement dans la base de données UE. Sanctions : jusqu'à 15 M€ ou 3 % du chiffre d'affaires mondial. |
Risque limité - à partir du 2 août 2026 | Obligations de transparence : tout utilisateur interagissant avec une IA doit en être informé. Le watermarking des contenus synthétiques entre en vigueur au 2 décembre 2026. Sanctions : jusqu'à 7,5 M€ ou 1 % du CA mondial. |
Risque minimal | Aucune obligation spécifique. Mais la frontière avec le risque limité peut être fine : un outil de recommandation qui influence une décision commerciale ou RH peut rapidement changer de catégorie selon son contexte de déploiement. |
Les cas fréquents dans une DSI : RH, scoring, IA générative, SaaS tiers
Dans la pratique, les systèmes à haut risque les plus courants dans une DSI relèvent de quelques domaines bien identifiés par l'Annexe III :
RH et recrutement : tri de CV automatisé, scoring de candidats, évaluation des performances
Services financiers : scoring crédit ou assurantiel
Santé : diagnostic médical assisté par IA
Interfaces conversationnelles : chatbot de support client, agent conversationnel, assistant IA interne sont tous classés en “risque limité”, avec des obligations de transparence à partir d'août 2026
IA générative connectée à un outil métier via API : sa qualification sera à mener selon les décisions qu'elle influence réellement
Documenter la qualification : un élément de conformité à part entière
La traçabilité de la démarche de qualification est en elle-même un élément de conformité. Ce n'est pas seulement le résultat qui compte : c'est la capacité à démontrer comment vous y êtes arrivé, et par qui la décision a été prise.
Pensez donc à :
Documenter chaque qualification : pourquoi ce système a été classé dans telle catégorie, sur quelle base, par qui, à quelle date.
Escalader les cas ambigus au comité de pilotage transversal, et si nécessaire à un expert juridique spécialisé. Une qualification contestable défendue de bonne foi vaut mieux qu'une classification basse non documentée.
Éviter la sous-qualification délibérée : les autorités de contrôle apprécieront la bonne foi dans la démarche, pas l'esquive.
Quelles sont les étapes concrètes pour mettre en œuvre votre audit AI Act ?
Les prérequis essentiels
Avant d'entrer dans le détail des étapes, un prérequis de méthode : traitez votre audit IA comme un projet IT à part entière. Sponsor identifié, équipe constituée, jalons définis, budget alloué - pas un groupe de travail ad hoc qui se réunit entre deux comités.
Mais gardez à l'esprit que ces étapes ne décrivent pas un projet avec une date de fin : elles décrivent la construction d'une capacité permanente. L'objectif n'est pas de "passer" l'AI Act, mais de piloter votre portefeuille IA dans la durée, avec la même rigueur que n'importe quel actif stratégique de votre SI.
Pour les systèmes à haut risque standalone, les quatre premières phases prennent en moyenne quatre à six mois dans une organisation structurée. L'efficacité de la démarche dépend directement du sérieux avec lequel elle est cadrée en amont.
C'est aussi à ce stade que se joue l'adoption interne : une démarche bien cadrée dès le départ génère moins de résistance et des résultats plus durables.
Constituer l'équipe et poser la gouvernance
C'est le point de départ, et l'erreur la plus fréquente est de le sauter pour aller directement à la cartographie. Un registre sans propriétaire n'est maintenu par personne.
La priorité absolue : désigner un responsable conformité IA avec un mandat clair, un accès à la direction générale et une légitimité transversale. Ce rôle peut être porté par le DPO, le RSSI, un consultant spécialisé ou une cellule dédiée... L'essentiel est qu'il soit identifié et doté de ressources.
Autour de lui, un comité de pilotage transversal doit être constitué, réunissant à minima : DSI, DPO, Juridique, Sécurité, et les directions métiers utilisatrices d'IA.
Trois travaux doivent être lancés immédiatement en parallèle :
Formaliser une politique interne de gouvernance IA : périmètre, principes, processus de validation des nouveaux usages
Engager le plan de montée en compétences des équipes : l'obligation de culture IA (Art. 4) est applicable depuis février 2025 - et la montée en compétences des collaborateurs conditionne directement l'efficacité de la conduite du changement
Intégrer la conformité IA aux instances de gouvernance existantes : COMEX, comités de direction IT
Du recensement à la documentation technique
Ces trois phases forment le cœur opérationnel de votre audit IA en entreprise :
Cartographie : recensement exhaustif selon la méthode des trois sources détaillée plus haut, avec constitution d'un registre vivant opposable aux autorités de contrôle.
Qualification : application de la grille AI Act système par système, traçabilité documentée de chaque décision de classification, escalade des cas ambigus. C'est ici que la méthodologie rigoureuse fait toute la différence : une qualification bien documentée est un avantage en cas de contrôle.
Documentation Annexe IV : pour chaque système classé haut risque, la documentation technique est la pièce maîtresse de votre conformité.
Que doit couvrir votre documentation Annexe IV ?
Description générale du système et de ses objectifs
Data d'entraînement, de test et de validation
Métriques de performance et limites connues
Architecture technique et logique de fonctionnement
Mesures de sécurité et de robustesse
Évaluation des risques résiduels
Un point de vigilance opérationnel : toute modification substantielle du système déclenche une mise à jour obligatoire de la documentation. Intégrez ce réflexe dès maintenant dans vos processus de delivery : une documentation à jour au moment du déploiement et périmée six mois plus tard ne vous protège pas.
Gestion des risques et supervision humaine
La gestion des risques requise par l'Article 9 de l’AI Act n’est pas une évaluation ponctuelle à produire avant la mise en production, mais un processus continu tout au long du cycle de vie de chaque système à haut risque. Le quick win ici est de capitaliser sur vos processus de gestion des risques IT existants plutôt que de tout reconstruire. Le lien entre conformité IA et gestion des risques opérationnelle est une opportunité de rationalisation, pas une contrainte supplémentaire.
La supervision humaine est l'autre exigence structurante de l'AI Act pour les systèmes à haut risque. Elle ne signifie pas qu'un humain doit valider chaque décision produite par le système. Le dispositif doit permettre à un collaborateur désigné de comprendre, surveiller et corriger le système si nécessaire.
Ici, trois conditions doivent être réunies :
Intégrer la supervision by design, dès la conception ou l'achat du système.
Tracer les décisions et les interventions humaines : la traçabilité est une exigence réglementaire, pas une option.
Former les auditeurs internes et superviseurs désignés : superviser un système IA suppose de comprendre ses logiques de fonctionnement, ses limites et ses signaux d'alerte.
Construire un pilotage continu
Cette étape est celle qui détermine si votre démarche tient dans la durée ou s'érode dès le premier changement de périmètre.
Concrètement, cela suppose de mettre en place :
Des tableaux de bord de conformité IA : couverture du registre, état de la documentation, alertes sur les systèmes non qualifiés ou à documentation périmée
Des revues régulières du portefeuille : à chaque nouveau déploiement, à chaque modification substantielle, à chaque changement de fournisseur
Une intégration de la conformité IA dans le cycle de vie de chaque nouveau projet IT : un système déployé sans qualification préalable est un problème futur certain
Une remontée aux instances de gouvernance : COMEX, conseil d'administration si pertinent
Pour accéder à la checklist complète de conformité AI Act et à votre plan d'action concret, téléchargez notre guide.

Comment vous mettre en conformité avec l'AI Act ?
Télécharger le guide
Pourquoi un audit IA ponctuel ne suffit pas ?
L'audit IA est une étape nécessaire - pas la destination. La conformité AI Act ne doit pas être traitée comme un projet fermé. Ce serait une illusion de méthode. Et c'est précisément là que se joue la vraie différence entre les entreprises qui maîtrisent leur écosystème IA et celles qui le subissent.
Un audit prend une photo, tandis que votre SI est mouvant
Le SI évolue en permanence : nouveaux outils SaaS adoptés par les métiers, fonctionnalités IA activées automatiquement lors d'une mise à jour fournisseur, agents déployés par des prestataires sans notification DSI. Chaque changement est un angle mort potentiel si la gouvernance n'est pas structurée pour l'absorber.
Ce que l'AI Act exige réellement, ce n'est pas une photo annuelle de votre portefeuille IA : c'est une vision maintenue en continu. Pour chaque système, le règlement impose de relier les agents à leur contexte architectural, de maintenir les responsabilités à jour, de mettre à jour la documentation technique à chaque modification substantielle. Un registre figé, aussi complet soit-il au moment de sa production, est périmé dès le prochain déploiement.
La conformité à l'AI Act n'est pas un état qu'on atteint. C'est une capacité qu'on maintient.
De l'audit ponctuel au portefeuille IA piloté en continu
C'est le vrai changement de paradigme qu'impose l'AI Act. Les approches documentaires statiques (tableurs, audits ponctuels, registres annuels) ont une limite structurelle : elles recensent sans connecter. Elles ne relient pas les systèmes IA à leur contexte architectural, à leurs flux de data, à leurs responsables réels, à leurs processus métier.
Résultat : une documentation formellement présente, et opérationnellement inutile.
Ce qu'il faut construire, c'est un portefeuille IA vivant, pas un audit reconduit chaque année. Un référentiel qui connecte chaque agent à son Architecture, à ses données, à ses responsables, à sa valeur business. Et qui s'adapte automatiquement à chaque changement de périmètre, sans repartir de zéro.
Le lien avec la gouvernance IT existante est ici structurel. Les organisations qui avaient déjà structuré leur portefeuille applicatif et leur gestion des risques IT avant l'AI Act partent avec six à douze mois d'avance.
Pour les autres, les deux chantiers doivent être menés en parallèle. L'AI Act fonctionne comme un révélateur : il met en lumière des lacunes de gouvernance qui existaient bien avant lui - et qu'il aurait fallu corriger de toute façon. Investir dans ce référentiel devient un actif stratégique dont le ROI dépasse largement les exigences réglementaires : alignement stratégique, pilotage du portefeuille, maîtrise des risques opérationnels.
Une gouvernance IA bien structurée aujourd'hui n'est pas seulement une réponse à l'AI Act. C'est un avantage compétitif durable.
Et avec Smoteo, ça donne quoi ?
Smoteo est conçu précisément pour ce passage : de l'audit ponctuel au portefeuille IA piloté en continu. La plateforme structure dans un référentiel unifié tout ce que l'AI Act exige et que votre organisation doit maîtriser dans la durée.
Le Registre des usages centralise en continu tous les outils et initiatives IA actifs par département : contexte applicatif, flux de données, responsables désignés, niveau de risque qualifié
L'AI Value Stream Map cartographie visuellement chaque agent IA dans l'écosystème business et IT, quels domaines il couvre, quelles données il consomme, quelles capacités métier il touche
Les Epic Cards structurent chaque initiative IA dès son origine (objectifs, dépendances, données, risques, valeur business) et constituent directement la base documentaire exigée par l'Annexe IV, sans ressaisie, sans reconstitution en urgence
Le méta-modèle connecte stratégie, Architecture, portefeuille et delivery dans une vue unifiée, pour un pilotage de la conformité intégré au quotidien de la DSI
Résultat : plus de 80 % de couverture des applications, processus et agents dans la cartographie, et une réduction de 30 % du risque de non-conformité avant production.
De l'audit IA à la gouvernance durable : changer de paradigme
L'AI Act n'est pas une contrainte tombée du ciel. C'est la formalisation réglementaire d'un problème que beaucoup de CIO, de DPO et de RSSI connaissent déjà intimement : l'intelligence artificielle se déploie dans les organisations plus vite que la capacité à la gouverner.
Un audit IA interne rigoureux est la première étape pour reprendre le contrôle. Mais ce n'est que le début. Les entreprises qui sortiront renforcées de cette phase réglementaire ne seront pas celles qui auront produit le registre le plus complet avant l'échéance. Ce seront celles qui auront compris que la conformité est un prétexte, et la gouvernance l'enjeu réel. Celles qui auront transformé une obligation réglementaire en infrastructure durable : un portefeuille IA vivant, piloté en continu, aligné sur la stratégie, défendable face aux régulateurs.
Vous souhaitez passer de l'audit ponctuel à un portefeuille IA structuré et piloté en continu ? Smoteo centralise le registre des usages, la cartographie des agents et la documentation technique dans un référentiel unique, maintenu à jour en temps réel. Demandez une démo

Guide pratique
Comment vous mettre en conformité avec l'AI Act ?

À propos de l'auteur
Eric Draperi
Cofounder @ Smoteo
J’ai passé une grande partie de ma carrière à décrypter la complexité des systèmes d’information. D’abord architecte omnicanal, j’ai accompagné des entreprises confrontées à un défi commun : connecter leurs mondes (ceux du business et de l’IT) sans perdre en agilité ni en clarté. J’ai contribué à plusieurs transformations numériques, toujours avec la même conviction : une architecture ne vaut que si elle sert concrètement la stratégie et la création de valeur.

À propos de l'auteur
Eric Draperi
Cofounder @ Smoteo
J’ai passé une grande partie de ma carrière à décrypter la complexité des systèmes d’information. D’abord architecte omnicanal, j’ai accompagné des entreprises confrontées à un défi commun : connecter leurs mondes (ceux du business et de l’IT) sans perdre en agilité ni en clarté. J’ai contribué à plusieurs transformations numériques, toujours avec la même conviction : une architecture ne vaut que si elle sert concrètement la stratégie et la création de valeur.
Sommaire
Chacun fait bouger
les lignes, Smoteo
les connecte
Que vous soyez CIO, Architecte, PMO ou Product Owner, nous vous accompagnons.
Chacun fait bouger
les lignes, Smoteo
les connecte
Que vous soyez CIO, Architecte, PMO ou Product Owner, nous vous accompagnons.