Construire votre inventaire d'IA avant le 2 août 2026 : guide pratique pour les PME de l'UE

En bref

L'essentiel des obligations matérielles du règlement IA s'applique à compter du 2 août 2026 : obligations à haut risque de l'annexe III au titre des articles 8 à 22, devoirs des déployeurs prévus à l'article 26, exigences de transparence de l'article 50, et enregistrement dans la base de données européenne au titre de l'article 49. Aucune de ces obligations ne peut être satisfaite sans un inventaire complet, à jour et nominativement attribué de tous les systèmes d'IA en périmètre. Les interdictions de l'article 5 sont applicables depuis le 2 février 2025 et les obligations relatives aux modèles à usage général depuis le 2 août 2025 (art. 113) : un inventaire bâti aujourd'hui doit donc déjà couvrir le filtrage des pratiques interdites, la traçabilité des informations transmises par les fournisseurs d'IAGP et le travail courant de classification. Bonne nouvelle pour les PME aux ressources contraintes : vous tenez très probablement déjà des registres analogues au titre de l'article 30 du RGPD, des inventaires d'actifs NIS2, ainsi qu'une cartographie au titre de l'annexe A.5.9 d'ISO 27001. L'inventaire IA gagne à être bâti comme un prolongement de ces registres, plutôt que comme un livrable parallèle. Ce guide vous donne le schéma de l'inventaire, la cartographie de réutilisation, trois cas concrets de PME, les angles morts qui surprennent les organisations et un plan en soixante jours pour livrer le registre avant l'échéance.

Pourquoi un inventaire d'IA s'impose avant le 2 août 2026

Le règlement IA n'érige pas l'inventaire au rang d'obligation autonome et nommée. Il fait pourtant peser sur les organisations plus d'une douzaine d'obligations qu'aucun responsable conformité ne peut honorer sans connaître précisément les systèmes d'IA présents dans son organisation, leur finalité, leur propriétaire et leur niveau de risque. La gestion des risques de l'article 9 suppose qu'une liste de systèmes ait été dressée préalablement à l'analyse. La documentation technique exigée par l'article 11 suppose, elle aussi, l'identification préalable des systèmes en périmètre. Les devoirs de l'article 26 — supervision humaine, surveillance, journalisation, information des travailleurs concernés — s'apprécient système par système, et ne peuvent l'être sans registre système par système. L'enregistrement au titre de l'article 49 dans la base de données européenne est lui-même une formalité par système. À défaut d'inventaire, rien d'autre ne peut être ordonné, hiérarchisé ni démontré.

Le barème des amendes a précisément vocation à rendre la lacune coûteuse. L'article 99 fixe les sanctions administratives à 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel pour les manquements aux pratiques interdites (art. 99 §3), à 15 millions d'euros ou 3 % pour la non-conformité aux obligations à haut risque (art. 99 §4), et à 7,5 millions d'euros ou 1 % pour la fourniture d'informations incorrectes, incomplètes ou trompeuses aux organismes notifiés et autorités compétentes (art. 99 §5). Les PME bénéficient d'une atténuation partielle au titre de l'article 99 §6 — l'amende peut être plafonnée au plus bas du montant absolu ou du pourcentage, plutôt qu'au plus élevé — mais cette atténuation ne supprime pas le plafond et ne joue aucunement sur la catégorie d'erreur la plus dommageable : découvrir, en cours de procédure, que l'organisation ignore quels systèmes d'IA elle exploite. Un inventaire incomplet est précisément la condition préalable du troisième type d'amende, puisque chaque réponse fournie à l'autorité devient nécessairement une estimation.

Une dimension d'accès au marché complète le tableau. L'article 79 permet à l'autorité de surveillance du marché d'imposer des mesures correctives aux systèmes à haut risque non conformes, jusqu'au retrait du marché européen. Pour un éditeur SaaS B2B dont les contrats grands comptes incluent des garanties de conformité — et dont les clients commenceront, dès le second semestre 2025, à exiger des attestations relatives au règlement IA dans leurs procédures d'achat —, l'incapacité à produire à la demande un inventaire système par système constitue un risque commercial bien avant d'être un risque réglementaire. Les premiers clients à formuler la demande seront les grandes entreprises allemandes, françaises et néerlandaises qui font déjà tourner des processus matures de diligence RGPD à l'égard de leurs fournisseurs. Elles n'accepteront pas la réponse « notre cartographie est en cours » à la fin 2026.

Ce que recouvre la notion de « système d'IA » au sens de l'article 3 §1

L'article 3 §1 définit un système d'IA comme un système automatisé conçu pour fonctionner à différents niveaux d'autonomie, qui peut faire preuve d'une capacité d'adaptation après son déploiement et qui, pour des objectifs explicites ou implicites, déduit, à partir des entrées qu'il reçoit, la manière de générer des sorties — prédictions, contenus, recommandations ou décisions — pouvant influencer des environnements physiques ou virtuels. Cette définition est délibérément alignée sur la définition de l'OCDE révisée en 2023, et son champ a été voulu large. Toute organisation qui en prend lecture attentive a la même réaction : son périmètre dépasse ce que l'on supposait.

Trois conséquences en découlent pour la délimitation de l'inventaire. Premièrement, l'apprentissage automatique n'est pas une condition. Un système expert à base de règles qui infère des sorties à partir d'entrées, en s'appuyant sur une base de connaissances, entre dans la définition — alors même que la majorité des ingénieurs hésiteraient à le qualifier d'IA. Le considérant 12 exclut certaines techniques classiques d'analyse statistique ou d'optimisation lorsqu'elles ne comportent aucun élément inférentiel, mais cette exclusion est étroite et discutée à la marge. En cas de doute, mieux vaut inscrire le système à l'inventaire et documenter la raison pour laquelle il ne nécessite pas de classification de niveau.

Deuxièmement, la formule « à différents niveaux d'autonomie » signifie que la frontière entre IA et logiciel conventionnel ne suit pas la ligne de l'« humain dans la boucle ». Un système soumis à validation humaine systématique pour chaque sortie reste un système d'IA dès lors qu'il infère ces sorties. La supervision humaine prévue par l'article 14 devient alors un attribut de conception du système d'IA, et non une porte de sortie hors du règlement. Les outils de tri de CV qui présentent à un recruteur une liste classée à partir de laquelle ce dernier choisit demeurent des systèmes d'IA, quand bien même la décision d'embauche est, formellement, prise par le recruteur.

Troisièmement, la formule « sorties pouvant influencer des environnements physiques ou virtuels » englobe une longue liste de logiciels opérationnels que les organisations qualifient rarement d'IA : moteurs de tarification dynamique, modèles de scoring de fraude, prédicteurs d'attrition, classifieurs de modération de contenus, systèmes de recommandation, routage automatisé des courriels, prévision de la demande, modèles de maintenance prédictive. La plupart se révéleront être à risque minimal après l'analyse des niveaux, mais ils ont vocation à figurer à l'inventaire dans tous les cas. L'objet du registre est de démontrer qu'une classification a bien été conduite, non de ne lister que les systèmes effectivement classés en haut risque.

Cartographier l'inventaire selon les niveaux de risque du RIA

Chaque entrée de l'inventaire porte un niveau de risque, et ce niveau commande la suite du dossier. Les cinq catégories — risque inacceptable, haut risque, risque limité, risque minimal, plus la couche IAGP — se superposent sur le même registre, et un produit unique peut donner lieu à plusieurs entrées d'inventaire dès lors qu'il abrite plusieurs cas d'usage d'IA distincts. Mieux vaut traiter les entrées comme des unités de travail conformité que comme un catalogue fournisseurs.

Les systèmes à risque inacceptable au titre de l'article 5 — huit familles de pratiques interdites couvrant les techniques manipulatrices, l'exploitation des vulnérabilités, la notation sociale, la police prédictive par profilage seul, le scraping facial non ciblé, la reconnaissance des émotions au travail et dans l'enseignement, la catégorisation biométrique selon des attributs sensibles, ainsi que l'identification biométrique à distance en temps réel dans les lieux publics à des fins répressives — n'ont pas vocation à apparaître dans une entrée d'inventaire active. Si un système existant ou un projet d'achat correspond à l'une de ces interdictions, l'entrée d'inventaire ne sert qu'à documenter la décision d'arrêt. Les interdictions sont applicables depuis le 2 février 2025, il ne s'agit donc plus d'une obligation prospective.

Les entrées en haut risque — catégories de l'annexe III, augmentées des composants de sécurité de produits relevant de l'annexe I au titre de l'article 6 §1 — appellent le jeu de champs le plus lourd. Les treize obligations cumulées des articles 9 à 49 engendrent des exigences documentaires qu'une entrée d'inventaire trop maigre ne peut pas porter. Pour ces entrées, l'inventaire gagne à être traité comme un index renvoyant à un dossier technique distinct, constitué au titre de l'article 11 et de l'annexe IV — l'entrée elle-même se contentant alors des métadonnées dont un auditeur a besoin pour naviguer vers le dossier. Les obligations matérielles s'appliquent à compter du 2 août 2026 pour les systèmes à haut risque de l'annexe III, et à compter du 2 août 2027 pour le volet « sécurité des produits » de l'annexe I au titre de l'art. 6 §1.

Un second filtre opère au sein de l'annexe III. L'article 6 §3 instaure une dérogation pour les systèmes annexe III qui ne présentent pas de risque significatif de préjudice, dès lors qu'ils accomplissent une tâche procédurale étroite, améliorent le résultat d'une activité humaine déjà réalisée, détectent des schémas ou des écarts décisionnels sans se substituer à l'évaluation humaine, ou exécutent une tâche préparatoire à une évaluation visée par l'annexe III. Le profilage des personnes physiques disqualifie la dérogation dans tous les cas. Chaque entrée annexe III appelle ainsi une analyse écrite au titre de l'article 6 §3 : soit une conclusion positive (avec mention du tiret précis invoqué) et son raisonnement, soit une conclusion négative confirmant le maintien du système en haut risque.

Les entrées à risque limité — agents conversationnels, outils d'hypertrucage, textes ou contenus médias générés par IA, systèmes de reconnaissance des émotions hors prohibition — portent les obligations de transparence de l'article 50. L'inventaire doit consigner, système par système, le mécanisme d'information : emplacement du bandeau de discussion, technique de filigrane employée pour les sorties synthétiques, journal de revue éditoriale pour les textes générés par IA publiés sur des questions d'intérêt public, mécanisme de notification côté déployeur pour les hypertrucages. Les obligations en risque limité s'appliquent également à compter du 2 août 2026, et, à la différence du parcours haut risque, aucune voie dérogatoire ne décharge le devoir : tout agent conversationnel doit faire l'objet d'une information, et l'inventaire doit en apporter la preuve.

Les entrées à risque minimal forment le gros du registre. Aucune obligation contraignante au titre du règlement IA ne pèse sur ces systèmes, mais l'inventaire doit néanmoins consigner la conclusion négative — le raisonnement documenté établissant que le système ne relève pas de l'annexe III, n'interagit pas directement avec des personnes physiques et ne génère pas de contenus synthétiques. Le devoir général d'éducation à l'IA prévu à l'article 4 s'applique quant à lui quel que soit le niveau, et l'inventaire doit donc identifier la cohorte de salariés qui exploite chaque système à risque minimal et confirmer qu'elle est intégrée au programme d'éducation à l'IA.

L'IAGP est une couche, et non un niveau. La quasi-totalité des entrées d'inventaire d'une PME bâties au-dessus d'un modèle de fondation — GPT-4o, Claude, Gemini, Mistral Large, Llama, Command — relèvent d'une fiche déployeur au titre de l'article 53 §1, point b, avec reprise des informations transmises en aval par le fournisseur amont. L'inventaire requiert ici un champ dédié à l'identité et à la version du modèle amont, au fournisseur, à la référence du résumé public des données d'entraînement, ainsi qu'à la date à laquelle le dernier jeu d'instructions d'utilisation publié par le fournisseur a été examiné. Deux règles distinctes méritent ici d'être nettement séparées. L'article 25 fait basculer les obligations de fournisseur haut risque sur un acteur en aval dans trois hypothèses au sens de l'article 25 §1, points a) à c) : mise sur le marché d'un système d'IA à haut risque sous son propre nom ou sa propre marque ; modification substantielle d'un système à haut risque déjà placé sur le marché ; modification de la finalité d'un système qui n'était pas à haut risque (y compris d'un IAGP) de telle manière qu'il devient à haut risque au sens de l'article 6. Le considérant 109 traite, lui, d'un cas différent : celui d'une organisation qui réalise un fine-tuning ou une autre modification d'un IAGP sans le faire basculer en haut risque. Les obligations qui pèsent alors sur l'acteur aval (au titre de l'article 53 §1, point b, et de l'annexe XI section 2) sont limitées à la modification elle-même — typiquement, compléter la documentation technique amont par les informations relatives aux changements apportés, y compris à toute nouvelle source de données d'entraînement. La plupart des PME ne franchissent ni l'un ni l'autre de ces seuils, mais l'inventaire est le seul endroit où la ligne, système par système, est consignée.

Champs requis dans l'inventaire

Un inventaire d'IA défendable comporte une quinzaine de champs par entrée. Mieux vaut résister à la tentation d'en ajouter — chaque champ supplémentaire est une charge de maintenance, et le seul registre soutenable est celui que les équipes mettent effectivement à jour quand les systèmes évoluent. La liste qui suit constitue l'ensemble minimal requis pour porter les obligations applicables à compter du 2 août 2026.

• Nom du système et identifiant unique — un libellé stable employé de la même façon dans le dossier technique, dans l'enregistrement à la base de données européenne, dans les contrats fournisseurs et dans les tickets internes de gestion du changement.
• Responsable nommé — une personne physique unique au sein de l'organisation, à qui incombe la mise à jour de l'entrée et le déclenchement d'une nouvelle classification lorsque le système évolue de façon substantielle. Une équipe ou un service ne sont pas un responsable.
• Indicateur interne / fournisseur tiers — selon que le système est développé en interne, acquis en SaaS, ou intégré au sein d'un produit plus large. Ce champ détermine si l'organisation est fournisseur, déployeur, ou les deux, au sens des articles 25 et 26.
• Niveau de risque RIA — risque inacceptable, haut risque (art. 6 §1, ou art. 6 §2 / annexe III avec mention du point précis de l'annexe III), risque limité (avec le paragraphe précis de l'article 50), risque minimal, augmenté d'un drapeau « couche IAGP » lorsque pertinent.
• Justification de la classification — un raisonnement bref en prose, mentionnant tout recours à la dérogation de l'article 6 §3. Les justifications vagues ne tiennent pas en audit ; le critère est : « documenté parce que motivé ».
• Modèle amont — pour les fiches déployeur d'IAGP, l'identité et la version du modèle, son fournisseur, et la date à laquelle les instructions d'utilisation amont au titre de l'article 53 §1, point b, ont été revues pour la dernière fois.
• Finalité — le cas d'usage précis tel qu'il est décrit aux déployeurs, dans la formulation des instructions d'utilisation au titre de l'article 13. Le glissement entre la finalité déclarée et l'usage effectif compte parmi les constats d'audit les plus fréquents.
• Base légale RGPD — pour tout système qui traite des données personnelles, la base de l'article 6 du RGPD (et la condition de l'article 9 lorsque des catégories particulières de données sont en jeu). Renvoi croisé à l'entrée correspondante du registre de l'article 30 du RGPD.
• Origine des données d'entraînement — synthèse de la provenance, couvrant la source, les conditions de licence, le respect des opt-out en matière de droit d'auteur, et toute mesure de minimisation ou de désidentification appliquée. Pour les fiches déployeur d'IAGP, le champ peut renvoyer au résumé public des données d'entraînement publié par le fournisseur amont.
• Type de sortie — prédiction, recommandation, classification, génération de contenu, décision. Le type de sortie commande les obligations de transparence de l'article 50 et l'analyse au titre de l'article 22 du RGPD.
• Impact décisionnel — selon que les sorties influencent ou non des décisions à conséquences pour des personnes physiques identifiables, et, dans l'affirmative, la population concernée (salariés, candidats, clients, patients, allocataires). C'est le champ qui signale le moment où une AIPD distincte au titre de l'article 35 du RGPD ou une analyse d'impact sur les droits fondamentaux au titre de l'article 27 du règlement IA s'impose.
• Conception de la supervision humaine — les mesures effectivement mises en place au titre de l'article 14 : revue avant déploiement, validation des sorties, capacité d'override, seuils d'intervention, voies d'escalade. Une mention générique du type « un humain revoit la sortie » ne tient pas le standard d'audit.
• Statut de l'évaluation de conformité — pour les entrées en haut risque, la voie retenue (contrôle interne au titre de l'annexe VI, évaluation par tiers au titre de l'annexe VII pour la biométrie, évaluation intégrée pour les produits annexe I), la date de la dernière évaluation, et la référence de la déclaration UE de conformité au titre de l'article 47.
• Enregistrement à la base de données européenne — pour les entrées en haut risque relevant de l'article 49, l'identifiant d'enregistrement et la date de la dernière mise à jour.
• Date de dernière revue et déclencheur de la prochaine — la date calendaire de la dernière revue de classification et les événements qui imposeront un nouvel examen (changement de modèle, modification des données d'entraînement, extension de la finalité, intégration à un nouveau processus métier).

Réutiliser les registres existants

L'inventaire d'IA le moins coûteux est celui que l'on prolonge à partir des registres existants, plutôt que de le bâtir à partir de zéro. Trois artefacts préexistants couvrent l'essentiel des champs ci-dessus, ainsi que la discipline de gouvernance qu'il faut ensuite tenir dans le temps.

Le registre des activités de traitement au titre de l'article 30 du RGPD couvre la colonne vertébrale « données personnelles » de tout système d'IA qui traite des données relatives à des personnes physiques identifiables. Ce registre consigne déjà la base légale, les catégories de données, les catégories de personnes concernées, les destinataires, les transferts internationaux et les durées de conservation — autant d'éléments que l'inventaire d'IA doit, soit reproduire, soit référencer. Le geste pragmatique consiste à ajouter au registre RGPD existant une colonne « identifiant du système d'IA », et, du côté de l'inventaire d'IA, à renvoyer à l'entrée RGPD correspondante plutôt qu'à dupliquer les champs « données personnelles ». Les AIPD au titre de l'article 35 du RGPD, ainsi que les éventuelles analyses d'impact sur les droits fondamentaux au titre de l'article 27 du règlement IA — applicables aux déployeurs qui sont des organismes de droit public ou des entités privées fournissant un service public, et applicables, séparément, à tout déployeur (public ou privé) d'un système d'évaluation de la solvabilité au titre de l'annexe III §5(b) ou d'un système d'évaluation des risques et de tarification en assurance vie ou santé au titre de l'annexe III §5(c) — gagnent toutes à être chaînées par lien depuis l'entrée d'inventaire, plutôt que recopiées à l'intérieur.

Les inventaires d'actifs NIS2, lorsqu'ils existent, couvrent la colonne vertébrale « opérations » et « sécurité de l'information ». Les lois nationales de transposition de NIS2 — la date butoir de transposition était le 17 octobre 2024, et la Commission européenne a ouvert en novembre 2024 une procédure d'infraction contre 23 États membres en retard ; la transposition s'est poursuivie par vagues durant 2025 et 2026 — imposent aux entités essentielles et importantes la tenue d'un registre des actifs et dépendances TIC. Pour les PME entrant dans le champ de NIS2, ce registre comprend en général déjà les plateformes cloud, les dépendances SaaS et les logiciels critiques sur lesquels reposent les charges d'IA. Étiqueter les systèmes d'IA dans le registre NIS2 et croiser les références avec l'inventaire d'IA aligne les deux régimes et évite la situation, malheureusement courante, où l'inventaire NIS2 d'une organisation laisse apparaître un SaaS tiers sans signaler que ce SaaS embarque un cas d'usage d'IA en périmètre du règlement IA.

L'annexe A.5.9 d'ISO/IEC 27001:2022 (anciennement A.8.1.1 dans la version 2013) impose la tenue d'un inventaire des informations et des autres actifs associés, en ce compris les logiciels, services et informations elles-mêmes. Pour les PME certifiées ISO, l'inventaire d'actifs imposé par la mesure A.5.9 constitue le porteur naturel du registre IA. La piste d'audit exigée par ISO 27001 — propriétaire, classification, registre des changements — recoupe déjà les champs de l'inventaire IA listés plus haut. Traiter l'inventaire d'IA comme un sous-ensemble de l'inventaire d'actifs ISO 27001, plutôt que comme un nouvel artefact, évite la double maintenance, fait bénéficier le registre IA de la cadence de revue déjà inscrite dans le SMSI, et prémunit l'organisation contre la situation, trop fréquente, où le registre d'actifs du SMSI et l'inventaire d'IA divergent vers des versions mutuellement incohérentes.

Au-delà de ces trois socles, deux registres adjacents méritent d'être touchés : le registre des fournisseurs tenu par la fonction achats — qui consigne en général tous les SaaS externes utilisés par l'organisation, et offre souvent la voie la plus rapide pour un balayage exhaustif de l'IA fantôme — et le registre des consentements ou des bases contractuelles, qui sous-tend déjà la dimension RGPD de tout système d'IA en contact avec les clients. Lorsque l'inventaire d'IA est conçu comme une fédération de renvois entre ces registres existants, plutôt que comme un nouveau tableur, la charge de maintenance baisse de moitié environ, et la cohérence inter-régimes que les auditeurs recherchent émerge naturellement.

Trois exemples d'inventaires de PME

Les exemples concrets affûtent la discipline. Les trois cas brefs qui suivent illustrent la manière dont le schéma d'inventaire prend forme, en pratique, pour un éditeur HR-tech, une fintech et une medtech, chacun représentatif des PME européennes en phase précoce les plus exposées à l'échéance du 2 août 2026.

HR-tech : un éditeur SaaS de cinquante personnes à Munich

Le produit propose un système de suivi des candidatures intégrant deux fonctionnalités d'IA : un résumé automatique de CV bâti sur GPT-4o, et un classement interne des candidats entraîné sur l'historique de recrutement du client. L'inventaire compte deux entrées distinctes, et non une seule. L'entrée A — résumé de CV — est un système à risque limité en propre (transparence de type chatbot au titre de l'article 50 §1, le recruteur voyant un résumé clairement étiqueté comme généré par IA), avec une couche déployeur d'IAGP renvoyant à OpenAI comme fournisseur amont. L'entrée B — classement des candidats — est sans ambiguïté en haut risque au titre de l'annexe III, point 4 a) (emploi, recrutement, sélection des candidats), l'éditeur étant fournisseur puisque le système est mis sur le marché européen sous son propre nom. L'entrée B porte l'ensemble des treize obligations cumulées des articles 9 à 49 ; l'entrée A ne porte que la mention de l'article 50 §1 et la fiche de transmission d'IAGP. Le responsable partagé entre les deux entrées est le directeur produit, secondé par un référent IA Act du service juridique en tant que propriétaire de second rang. L'inventaire renvoie au registre d'actifs ISO 27001 (l'éditeur est certifié) pour les deux entrées et au registre RGPD pour les champs « données personnelles ». Les deux entrées portent la date du 2 août 2026 comme déclencheur d'achèvement du dossier technique au titre de l'article 11 et de l'annexe IV.

FinTech : une jeune pousse de crédit à la consommation de trente personnes à Vilnius

Le produit propose une application de crédit à la consommation comportant deux briques d'IA : un modèle de scoring de crédit entraîné sur des données internes augmentées de signaux d'open banking, et un modèle de détection de fraude superposé à la télémétrie des transactions. Le modèle de scoring de crédit relève de l'annexe III, point 5 b) — évaluation de la solvabilité de personnes physiques — et est, par défaut, à haut risque ; la société est fournisseur, met le système sur sa propre plateforme, et conduit l'évaluation de conformité par contrôle interne au titre de l'annexe VI. Le modèle de détection de fraude bénéficie de l'exclusion textuelle inscrite directement dans l'annexe III §5(b), qui exclut « les systèmes d'IA utilisés aux fins de la détection de fraudes financières » de la catégorie « évaluation de la solvabilité » dès l'origine — il s'agit d'une exclusion distincte de la dérogation procédurale de l'article 6 §3 qui filtre les systèmes annexe III en général, et l'entrée d'inventaire doit indiquer clairement laquelle des deux portes de sortie elle emprunte. L'exclusion étant étroite — elle vise la détection de fraudes, et non l'ensemble de l'évaluation des risques sur les transactions — l'équipe juridique de l'entreprise tient à juste titre une position défensive en maintenant un jeu partiel de contrôles « haut risque » sur le modèle de fraude, et en prévoyant une nouvelle classification dès que la finalité du modèle dépasse la stricte détection de fraudes. Cas limite : un agent conversationnel de support client bâti sur Mistral Large devient une entrée C à risque limité, dotée d'une couche déployeur d'IAGP. Le renvoi vers le registre RGPD est ici crucial, car l'article 22 du RGPD (décision individuelle automatisée) s'applique à l'entrée « scoring de crédit », et l'inventaire doit attester du droit, pour la personne concernée, d'obtenir une intervention humaine, d'exprimer son point de vue et de contester la décision. L'article 27 du règlement IA mord également ici : tout déployeur d'un système annexe III §5(b) doit conduire une analyse d'impact sur les droits fondamentaux, qu'il soit public ou privé. Le DPO est désigné comme responsable des deux entrées en haut risque ; le responsable des opérations clientèle est responsable de l'agent conversationnel.

MedTech : une jeune pousse de télésurveillance de vingt personnes à Dublin

Le produit est une application de télésurveillance des patients reposant sur un cas d'usage d'IA unique : un algorithme qui signale des évolutions cliniquement significatives des constantes vitales, à partir d'une télémétrie continue issue d'un dispositif portable. Le système est régi, en tant que dispositif médical, par le règlement (UE) 2017/745 (MDR), et porte le marquage CE délivré sous ce régime. L'entrée d'inventaire IA est classée en haut risque au titre de l'article 6 §1 — l'IA est un composant de sécurité d'un produit relevant de la législation d'harmonisation européenne énumérée à l'annexe I (les dispositifs médicaux), produit lui-même soumis à une évaluation de conformité par tiers. Les obligations matérielles « haut risque » du règlement IA s'appliquent à cette entrée à compter du 2 août 2027, et non du 2 août 2026, en raison du calendrier différé prévu, pour l'article 6 §1, par l'article 113. L'évaluation de conformité est intégrée à la procédure MDR existante au titre de l'article 43 §3 ; l'organisme notifié intervenant au titre du MDR couvre également le travail de conformité spécifique à l'IA, les livrables propres au règlement IA (documentation technique de l'article 11, gestion des risques de l'article 9, transparence à l'égard des professionnels de santé prévue à l'article 13) venant s'ajouter au dossier technique existant. L'entrée d'inventaire renvoie au dossier technique MDR plutôt que de le dupliquer, le responsable du SMQ est la même personne qui assume déjà les responsabilités de l'article 10 du MDR en matière de management de la qualité, et l'inventaire renvoie au registre RGPD pour le traitement des données de santé au titre de l'article 9 §2, point h, du RGPD. C'est ici que se cache le piège : une medtech qui prendrait par erreur le 2 août 2026 comme déclencheur en viendrait à mener un travail de conformité parallèle douze mois trop tôt.

Les angles morts qui prennent les PME au dépourvu

Trois familles d'angles morts reviennent avec régularité dans les chantiers d'inventaire des PME, et chacune mine discrètement le registre tant qu'on ne va pas la débusquer délibérément.

L'IA fantôme est, de loin, la plus volumineuse. Les équipes marketing adoptent Jasper, ChatGPT Team ou Copy.ai pour rédiger des contenus. Les équipes commerciales connectent Gong, Apollo ou Lavender à leurs enregistrements d'appels et à leurs séquences d'e-mails sortants. Les équipes d'ingénierie utilisent GitHub Copilot, Cursor ou Codeium en dehors de toute décision d'achat formelle. Les RH font passer des enquêtes par ChatGPT et envoient les réponses ouvertes dans des classifieurs de sentiment. Chacun de ces déploiements est un cas d'usage d'IA dans le champ de l'article 3 §1, presque toujours en risque limité ou minimal pris isolément, mais invisible pour la fonction conformité centrale tant que personne n'aura posé la question. La parade est procédurale : un formulaire de déclaration d'une page adressé à chaque chef de service, lui demandant de lister tous les outils d'IA utilisés par son équipe au cours des six derniers mois, à renouveler tous les trimestres, et à recouper avec les relevés de carte bancaire d'entreprise et le grand livre des dépenses SaaS. La première vague de déclarations, dans une PME SaaS de cinquante personnes typique, fait remonter entre douze et vingt outils d'IA dont la fonction conformité centrale ignorait l'existence.

L'IA embarquée dans les SaaS est la deuxième famille d'angles morts. De plus en plus, le SaaS B2B classique que l'organisation utilise depuis des années a discrètement intégré, en 2024 et 2025, des fonctionnalités d'IA — Salesforce Einstein, HubSpot AI, Notion AI, Slack AI, Zoom AI Companion, Microsoft 365 Copilot, fonctionnalités Gemini de Google Workspace, Atlassian Intelligence. L'organisation hôte est déployeuse de chacun de ces sous-systèmes d'IA, alors même que l'achat initial portait sur l'outil de productivité sous-jacent. L'inventaire doit consigner chaque sous-fonctionnalité d'IA comme une entrée distincte, et non l'agréger dans la ligne du SaaS parent. Chaque éditeur est, à son tour, un déployeur d'IAGP au-dessus d'un fournisseur de modèle amont : la chaîne de transmission descend ainsi sur trois niveaux — modèle de fondation (OpenAI/Anthropic/Google), éditeur SaaS (HubSpot/Microsoft/Slack), organisation hôte. L'entrée d'inventaire doit nommer les trois niveaux pour que les obligations de déployeur soient effectivement opposables.

Les changements de modèle constituent la troisième famille d'angles morts, et la plus glissante. Un éditeur SaaS modifie son IAGP sous-jacent — par exemple en passant de GPT-4 à GPT-4o, ou de Claude 3.5 à Claude 4 — sans changement perceptible côté produit, et l'entrée d'inventaire chez le déployeur devient silencieusement inexacte. La parade consiste à ajouter à l'inventaire un champ « version de modèle figée » et à imposer un déclencheur de nouvelle classification chaque fois que le modèle amont change. Pour les éditeurs matures, le changement est généralement annoncé par une note de version à laquelle l'équipe achats devrait être abonnée ; pour les éditeurs moins matures, l'entrée d'inventaire doit explicitement consigner le caractère volatil de l'identité du modèle amont, et la cadence de revue de cette entrée doit être resserrée (trimestrielle plutôt qu'annuelle).

Problèmes courants d'attribution de la responsabilité

La raison la plus fréquente pour laquelle un inventaire d'IA dérive vers l'inutilisable est que la responsabilité a été confiée à une équipe ou à un service plutôt qu'à une personne physique nommée. La formule « l'équipe produit est responsable de l'entrée 7 » est un faux-fuyant lorsque le système évolue substantiellement et que personne ne met l'entrée à jour, parce que personne, à titre individuel, n'en avait la charge. La discipline qui tient debout tout autre registre réglementaire — le DPO nommé derrière le registre RGPD, le RSSI nommé derrière l'inventaire ISO 27001, le contact NIS2 nommé pour la notification à l'autorité nationale — est exactement la discipline qu'appelle l'inventaire d'IA.

Trois schémas fonctionnent en pratique. Le premier consiste à désigner un référent IA Act unique, en général logé dans la fonction juridique ou conformité, qui détient le registre central et est nommément responsable des entrées les plus sensibles (les systèmes annexe III en haut risque pour lesquels la documentation technique de l'article 11 réclame une coordination interfonctionnelle). Le deuxième est un modèle fédéré dans lequel le référent IA Act détient le registre lui-même et la méthode, tandis que les responsables produits ou de fonctionnalités sont nommément attachés à chaque entrée — schéma adapté aux organisations SaaS qui livrent de nouvelles fonctionnalités d'IA chaque trimestre, et où une responsabilité centralisée par entrée serait un goulet d'étranglement. Le troisième est un modèle de coresponsabilité dans lequel chaque entrée en haut risque a un responsable métier désigné (le chef de produit, ou le responsable de la fonction concernée) et un responsable de contrôle désigné (le DPO ou le référent IA Act) — le responsable métier répondant de la mise à jour de l'entrée au fil des évolutions du système, le responsable de contrôle répondant du respect du jeu d'obligations. Chacun des trois schémas se défend ; ce qui ne se défend pas, c'est de laisser des entrées avec une responsabilité au niveau d'une équipe, ou laissée vacante.

Un second problème d'attribution tient à l'absence de coresponsable sur les entrées interfonctionnelles. Le cas type est l'exemple HR-tech ci-dessus : le chef de produit du moteur de classement des candidats est, naturellement, en position de tenir le dossier technique à jour, mais l'obligation d'information des travailleurs concernés au titre de l'article 26 §7 incombe à la fonction RH côté déployeur — c'est-à-dire chez le client —, et non chez l'éditeur. Si l'entrée d'inventaire de l'éditeur ne nomme pas un homologue côté client pour chaque organisation cliente, les obligations en cascade au titre de l'article 26 ne pourront pas être démontrées, et les instructions d'utilisation prévues à l'article 13, du côté de l'éditeur, ne pourront pas être correctement adressées. Les documents d'on-boarding clients et le contrat-cadre type doivent comporter, l'un et l'autre, une clause exigeant du client qu'il nomme un responsable IA Act côté déployeur avant la mise en service.

L'article 26 §5 mérite enfin une mention finale, parce qu'il est l'une des rares obligations de déployeur qui prend même les inventaires bien tenus à contre-pied. Les déployeurs de systèmes d'IA à haut risque doivent surveiller le fonctionnement du système sur la base des instructions d'utilisation et, le cas échéant, en informer les fournisseurs conformément à l'article 72. Lorsque le déployeur a des raisons de considérer que l'utilisation conforme aux instructions est susceptible de présenter un risque au sens de l'article 79 §1, il doit, sans retard injustifié, en informer le fournisseur ou le distributeur ainsi que l'autorité de surveillance du marché compétente — et suspendre l'utilisation du système. Concrètement, cela signifie que toute entrée en haut risque appelle, du côté déployeur, un responsable de surveillance nommé, une voie d'escalade documentée se terminant à l'autorité nationale compétente, et un protocole de suspension écrit pouvant être déclenché sans nouvelle validation interne. Désigner ces responsabilités tardivement, alors que le système est déjà en production, figure parmi les constats les plus fréquents dans les premières revues de mise en application.

Plan de mise en place sur 60 jours

Soixante jours suffisent à livrer une première version défendable de l'inventaire, à condition d'enchaîner les phases sans rupture, d'obtenir l'engagement du comité de direction sur la cadence dès le départ, et de réutiliser les registres existants au lieu de les redoubler. Le plan ci-dessous suppose une PME typique de trente à cent personnes, sans fonction de gouvernance d'IA préexistante, dotée d'un référent IA Act interfonctionnel désigné pour le chantier.

Jours 1 à 10 — cadrage et cartographie de réutilisation. Le référent IA Act rassemble le registre RGPD existant, l'inventaire d'actifs ISO 27001 (lorsqu'il s'applique), le registre NIS2 (lorsqu'il est applicable), la liste des fournisseurs tenue par les achats et le grand livre des dépenses SaaS. Chaque entrée de ces registres est passée en revue à l'aune de la pertinence IA, et celles qui touchent à l'IA sont marquées en vue de l'inventaire. Le référent rédige le schéma d'inventaire — le jeu de quinze champs ci-dessus, augmenté des extensions propres à l'organisation — et le fait viser par le DPO, le RSSI (lorsqu'il existe), et un sponsor au sein du comité de direction. L'outillage est arbitré dans la même fenêtre : tableur, plateforme GRC, ou extension de l'outil portant le registre RGPD. Pour les PME sans plateforme GRC, un tableur structuré tenu sous gestion de versions, doté de champs de revue obligatoires, suffit pour la première version.

Jours 11 à 30 — découverte et alimentation. Le balayage de l'IA fantôme se déroule dans cette fenêtre : formulaire de déclaration d'une page adressé à chaque chef de service, rapprochement avec les dépenses SaaS, et entretiens structurés avec chaque responsable de fonction (produit, ingénierie, marketing, vente, support client, RH, finance, opérations). Chaque déclaration devient une ébauche d'entrée d'inventaire. Le référent IA Act alimente les champs de métadonnées à partir du registre RGPD existant et des inventaires d'actifs partout où la donnée existe déjà, et n'ouvre une nouvelle collecte que pour les champs réellement spécifiques à l'IA (finalité, type de sortie, modèle amont, origine des données d'entraînement, conception de la supervision humaine). À la fin du jour 30, chaque cas d'usage d'IA connu de l'organisation doit avoir une ébauche d'entrée d'inventaire, même si la classification de niveau est provisoire et la justification encore squelettique.

Jours 31 à 50 — classification et analyse d'écarts. Le référent IA Act fait passer chaque ébauche d'entrée par l'arbre de décision (huit questions couvrant l'article 5, l'annexe III, l'article 6 §1, l'article 6 §3, le statut fournisseur / déployeur, la couche IAGP, l'interaction au titre de l'article 50 §1, les contenus synthétiques au titre de l'article 50 §§ 2 et 4, le risque systémique au titre de l'article 51). Chaque entrée se voit attribuer un niveau, accompagné d'une justification écrite. Pour les entrées en haut risque et en risque limité, le référent conduit une analyse d'écarts au regard du jeu d'obligations correspondant : pour le haut risque, la base de treize obligations cumulées des articles 9 à 49 ; pour le risque limité, les quatre obligations d'information de l'article 50. Chaque écart devient une tâche de remédiation, avec un responsable nommé et une échéance, ordonnée en regard du 2 août 2026 (ou du 2 août 2027 pour les entrées en annexe I au titre de l'article 6 §1). Le périmètre des AIPD et des analyses d'impact sur les droits fondamentaux au titre de l'article 27 est arbitré dans la même fenêtre : toute entrée en haut risque qui traite des données personnelles déclenche une AIPD, et toute entrée en haut risque déployée par un organisme public, par une entité privée fournissant un service public, ou par tout déployeur d'un système d'évaluation de la solvabilité au titre de l'annexe III §5(b), ou d'un système de tarification en assurance vie ou santé au titre de l'annexe III §5(c), déclenche une AIDF au titre de l'article 27.

Jours 51 à 60 — visa et cadence d'exploitation. L'inventaire et l'arriéré d'analyse d'écarts sont présentés au comité de direction pour visa. Le sujet « règlement IA » est inscrit à l'ordre du jour permanent du conseil sur une cadence trimestrielle. Le responsable de chaque entrée en haut risque est désigné formellement par écrit, et les responsables de surveillance côté déployeur prévus à l'article 26 §5 sont confirmés, ainsi que leur autorité de suspension. Les contrats clients et les documents d'on-boarding sont passés en revue pour intégrer les clauses « instructions d'utilisation » au titre de l'article 13 et les clauses de transmission au titre de l'article 26. Le programme d'éducation à l'IA prévu à l'article 4 est cadré, l'inventaire servant à identifier les cohortes de salariés qui exploitent ou utilisent chaque système. Un premier audit interne du registre est planifié pour la fin du premier trimestre 2027 — soit six mois après l'entrée en vigueur des obligations, délai suffisant pour que l'exploitation en conditions réelles ait fait remonter le premier lot de difficultés, et délai suffisamment court pour que les écarts puissent encore être traités avant le premier cycle d'audit externe. La revue de seconde version de l'inventaire lui-même est planifiée pour la fin du deuxième trimestre 2027.

Conclusion et étapes suivantes

L'échéance du 2 août 2026 est figée et asymétrique : le coût d'un retard sur l'inventaire est sans commune mesure avec le coût d'un démarrage anticipé, parce que pratiquement toutes les autres obligations du règlement IA en dépendent. Le chantier est, par ailleurs, particulièrement bien aligné sur ce que les PME européennes savent déjà bien faire — registre RGPD au titre de l'article 30, inventaires d'actifs NIS2, inventaires d'actifs ISO 27001 — si bien que l'effort marginal est notablement plus faible que ce que la lecture brute du règlement laisse craindre. Le piège tient à traiter l'inventaire d'IA comme un livrable parallèle, plutôt que comme une extension des registres déjà tenus. Il convient de le bâtir comme une fédération, de nommer une personne physique unique pour chaque entrée, et de traiter l'IA fantôme, l'IA embarquée dans les SaaS et les changements de modèle comme les trois familles d'angles morts qui mineront discrètement le registre si on ne va pas les débusquer.

Concrètement, les soixante prochains jours, pour une PME qui partirait de zéro, ressemblent à ceci : nommer un référent IA Act la première semaine ; arrêter le schéma et le plan de réutilisation la deuxième ; conduire le balayage d'IA fantôme les troisième et quatrième semaines ; alimenter une première version complète du registre les quatrième et cinquième semaines ; classifier et analyser les écarts pour chaque entrée les sixième et septième semaines ; présenter au comité de direction, lors de la neuvième semaine, un registre visé et une feuille de route de remédiation. Dès la dixième semaine, l'inventaire n'est plus un projet — il est devenu un actif d'exploitation pérenne, doté d'une cadence de revue trimestrielle et d'un responsable nommé pour chaque entrée. C'est la posture que récompense l'échéance du 2 août 2026, et c'est elle qui rend traitable le reste de l'arriéré de mise en conformité au règlement IA.