Conformité AI Act PME : par où commencer ? Le guide pratique

Dirigeants de PME, conformité AI Act PME : par où commencer si un client vous demande quels outils d’IA vous utilisez et que personne ne sait les recenser ? ChatGPT, un logiciel RH ou une fonction intégrée au CRM peuvent déjà servir dans vos usages professionnels.

Nous vous proposons une démarche concrète : cartographier les usages, classer les systèmes, nommer un référent, documenter les décisions et former les équipes. Le déployeur est l’organisation qui utilise un système d’IA sous son autorité dans un cadre professionnel ou organisationnel. Cette définition concerne aussi les entreprises qui n’ont pas créé l’outil utilisé.

Un tableur partagé peut suffire au départ. L’essentiel est de faire remonter les usages réels, y compris ceux que les salariés ont adoptés seuls ou ceux activés dans un logiciel acheté. Nous pourrons ensuite décider quels contrôles appliquer, sans traiter chaque outil de la même façon. La première décision consiste à vérifier si votre entreprise et ses usages entrent dans le champ du règlement.

À retenir

1. Nous commençons par recenser les systèmes et fonctions d’IA réellement utilisés.
2. Nous évaluons chaque usage selon son rôle, sa finalité et ses effets possibles.
3. Nous désignons un référent et des relais adaptés à l’organisation.
4. Nous gardons une trace des décisions et de leurs justifications.
5. Nous formons les équipes aux limites des outils qu’elles utilisent.

Conformité AI Act PME : par où commencer

Une PME française peut être concernée même si elle ne développe aucune IA. La conformité dépend du rôle, de la finalité et des risques associés à chaque système, et non de la taille de l’entreprise.

Le règlement (UE) 2024/1689, couramment appelé AI Act, est entré en vigueur le 1er août 2024. Il peut s’appliquer aux organisations qui développent, fournissent, importent, distribuent ou déploient des systèmes d’IA. Une petite structure ne bénéficie pas d’une exemption générale liée à son effectif.

La taille de l’entreprise ne suffit pas à écarter l’AI Act : nous examinons chaque activité, chaque système et chaque usage.

Des opérations ordinaires peuvent donc entrer dans son champ. Une entreprise peut acheter un logiciel doté d’IA, utiliser un chatbot pour son service client ou sélectionner des candidatures avec un outil spécialisé. Une fonction ajoutée à un logiciel métier peut aussi modifier la manière dont une décision est préparée.

La finalité prévue compte davantage que l’étiquette commerciale. Un fournisseur peut présenter un service comme un assistant généraliste, alors que l’entreprise l’emploie pour classer des candidats ou évaluer des demandes de crédit. C’est la tâche confiée au système qui oriente l’analyse.

Le champ peut aussi couvrir des acteurs établis hors de l’Union européenne lorsque les résultats de leurs systèmes sont utilisés dans l’Union. Pour choisir les obligations pertinentes, nous clarifions donc le rôle réellement exercé pour chaque outil, plutôt que de tirer une conclusion générale pour toute l’entreprise.

Quel rôle votre entreprise joue-t-elle pour chaque système ?

Une PME peut acheter un chatbot pour son site et développer en parallèle une fonction d’IA intégrée à un produit vendu sous sa marque. Elle n’aura pas nécessairement le même rôle pour ces deux systèmes.

Nous qualifions le rôle outil par outil, car une même organisation peut être fournisseur, déployeur, importateur ou distributeur selon les activités concernées. Le contrat ne fixe pas, à lui seul, le statut réglementaire.

Les responsabilités peuvent changer si l’entreprise modifie substantiellement un système, change sa finalité prévue ou le commercialise sous sa propre marque. Elle peut alors devoir réexaminer son rôle, notamment lorsqu’elle intègre une IA dans un produit vendu sous son nom.

Une entreprise peut aussi avoir des responsabilités de fabricant si elle intègre un système d’IA dans un produit commercialisé sous sa marque. Les équipes doivent donc regarder ce qu’elles font réellement, pas seulement le nom donné au contrat ou au projet.

Cette qualification permet de cibler les vérifications utiles et d’éviter une étiquette unique pour toute l’organisation. Nous passons ensuite à l’inventaire concret des outils concernés, y compris ceux que les équipes utilisent sans projet officiellement déclaré.

Comment cartographier les usages d’IA dans toute la PME ?

Une fonctionnalité d’IA activée dans un logiciel déjà acheté peut être absente de la liste des projets IA. Pour la faire apparaître, nous interrogeons les équipes sur les fonctions qu’elles utilisent au quotidien, et pas seulement sur les nouveaux outils.

L’inventaire IA réunit les outils et fonctionnalités d’IA repérés dans l’organisation. Il doit couvrir les systèmes achetés, les fonctions activées par défaut et les usages informels qui échappent parfois aux circuits habituels.

Recenser aussi les fonctions intégrées et les usages informels

Nous examinons les logiciels métier, les plateformes marketing, les outils RH et les solutions de support client. Une fonction de rédaction, de résumé ou de génération d’images dans un logiciel bureautique peut compter, même si l’entreprise n’a acheté aucun produit vendu comme « IA ».

Le recensement inclut aussi les projets pilotes et les outils publics utilisés par des salariés. Nous demandons aux responsables de vérifier les options activées dans leurs services. Un court échange avec chaque équipe révèle souvent des usages que les achats ou la DSI ne voient pas.

Enregistrer les informations utiles pour chaque outil

Pour chaque entrée, nous consignons cinq éléments concrets :

1. Le nom du système et celui de son fournisseur.
2. La finalité prévue et la tâche réellement confiée à l’outil.
3. Le responsable métier et les utilisateurs autorisés.
4. Les données d’entrée et les personnes concernées.
5. Les résultats produits et le niveau d’intervention humaine.

Un tableur partagé peut suffire au démarrage, à condition de nommer une personne chargée de sa mise à jour. Nous distinguons clairement une fonction disponible d’une fonction effectivement activée. Cette nuance évite de traiter comme réel un usage qui n’existe pas encore, ou d’ignorer une option déjà employée.

Nous faisons de l’inventaire IA un registre vivant, puis nous lançons la classification de chaque entrée. Une revue après chaque nouveau déploiement aide à maintenir une vision fidèle de l’utilisation dans toute l’organisation.

Comment classer les systèmes selon leur niveau de risque ?

Le même outil peut appeler des contrôles différents selon la tâche à laquelle nous l’affectons. Un assistant de rédaction n’a pas le même impact qu’un système qui aide à décider de l’accès à un emploi.

Nous classons chaque usage selon sa finalité prévue et son utilisation réelle, pas selon la sophistication technique du système. L’inventaire IA fournit les éléments de départ : tâches, données, personnes concernées et résultats.

Distinguer les quatre niveaux de risque

Le règlement distingue quatre catégories. Le tableau ci-dessous donne un premier repère, sans remplacer l’analyse juridique de la finalité et des conditions réelles d’utilisation.

Vérifier la finalité prévue et l’usage réel

Nous commençons par définir le système et sa tâche. Nous comparons ensuite son usage prévu avec son utilisation effective, puis vérifions si celle-ci relève d’une catégorie juridique particulière.

Un outil peut évoluer après son achat. Une fonction de classement activée par un manager peut changer la tâche confiée au produit. Nous examinons donc les pratiques réelles, les personnes touchées et les effets possibles, au lieu de nous fier à une description générale.

Consigner le raisonnement de classification

Pour chaque système, nous notons les éléments examinés, la décision prise, le responsable et la date de révision. Cette trace permet de comprendre pourquoi un niveau a été retenu et de rouvrir l’analyse si la finalité change.

Nous traitons d’abord tout usage susceptible d’être interdit, avant d’examiner les obligations applicables aux systèmes à haut risque. Un doute sur une pratique potentiellement interdite justifie une analyse avant de poursuivre son utilisation.

Quelles pratiques d’IA faut-il exclure immédiatement ?

Le nom commercial « bien-être au travail » ne suffit pas à déterminer si une fonction est acceptable. Un outil présenté comme un soutien aux équipes peut, par exemple, inférer leurs émotions à partir de comportements au travail.

Nous suspendons tout usage potentiellement interdit le temps d’obtenir une analyse adaptée. L’article 5 de l’AI Act encadre des pratiques interdites, dont certaines formes de manipulation préjudiciable, de notation sociale, de reconnaissance des émotions au travail et de catégorisation biométrique.

Lors d’un achat ou d’un pilote, nous vérifions en particulier les fonctions suivantes :

1. L’analyse ou l’inférence des émotions, notamment dans le cadre professionnel.
2. La collecte ou l’analyse de données biométriques à des fins sensibles.
3. La notation sociale ou comportementale des personnes.
4. La manipulation ou le ciblage de personnes vulnérables.
5. La collecte ou l’extraction non ciblée d’images faciales.

Une solution de bien-être peut suivre des interactions ou des expressions pour déduire un état émotionnel. La finalité annoncée ne répond pas à la question centrale : quelles données sont traitées, quelles inférences sont produites et dans quel contexte ? Nous demandons une analyse précise de ces fonctions avant toute poursuite.

Un pilote n’est pas une exception qui permettrait d’ignorer une interdiction. Nous suspendons l’usage concerné pendant l’examen, limitons les accès si nécessaire et conservons les informations utiles à l’analyse. Cela évite qu’une expérimentation devienne un usage régulier sans décision claire.

Une fois ces pratiques repérées, nous passons aux critères qui permettent de reconnaître les systèmes à haut risque. Cette étape distingue les usages à exclure de ceux qui peuvent rester autorisés sous obligations renforcées.

Quels systèmes d’IA peuvent être à haut risque dans une PME ?

Un outil de tri des candidatures peut relever du haut risque même s’il est acheté comme un service standard. La finalité et les effets potentiels sur les droits, la santé ou la sécurité guident l’analyse, pas la complexité du logiciel.

Nous examinons les systèmes qui influencent des décisions ou des conditions importantes pour les personnes. Une solution courante, fournie en ligne, peut avoir des conséquences sensibles selon la tâche qu’on lui confie.

Repérer les usages de l’annexe III

Pour une PME, les usages liés au travail méritent une attention particulière. Cela comprend le recrutement et la sélection, les décisions relatives à l’emploi, l’attribution de tâches et le suivi des performances.

Nous vérifions aussi les outils qui interviennent dans l’accès à certaines formations ou l’évaluation de la solvabilité. Un système qui aide à classer des candidats, à répartir des tâches ou à estimer la capacité de remboursement peut entrer dans les catégories concernées.

La présence d’un humain dans le processus ne suffit pas, à elle seule, à écarter l’analyse. Nous regardons ce que la personne examine réellement, le poids du résultat produit et la possibilité de corriger une erreur avant qu’elle n’affecte la décision.

Vérifier les systèmes intégrés à des produits réglementés

Un autre cas concerne les systèmes qui sont des composants de sécurité de produits soumis à des règles européennes. Il peut aussi s’agir de produits pour lesquels une évaluation de conformité est nécessaire avant la mise sur le marché.

Nous examinons alors le lien entre le système d’IA et le produit, ainsi que les exigences sectorielles applicables. Un dispositif qui contribue à une fonction de sécurité ne se traite pas comme une simple aide interne à la rédaction.

Cette analyse repose sur la fonction réelle du système, les personnes exposées et les conséquences possibles d’une erreur. Nous pouvons ensuite aborder les obligations qui concernent certains systèmes même lorsqu’ils ne relèvent pas de la catégorie haut risque.

Quelles obligations de transparence et règles sur les modèles d’usage général s’appliquent ?

Une personne qui échange avec un chatbot doit pouvoir comprendre la nature de l’interaction lorsque l’obligation de transparence s’applique. Nous informons les personnes dans les situations prévues par le règlement, en veillant à ce que l’information soit compréhensible au moment utile.

Ces obligations peuvent concerner les agents conversationnels et certains contenus synthétiques, comme des images, des vidéos ou des textes. Elles incluent aussi les deepfakes, c’est-à-dire des contenus artificiels qui représentent des personnes ou des événements de façon réaliste.

La transparence ne consiste pas à ajouter une mention générique dans les conditions d’utilisation. Nous regardons où la personne rencontre le système, ce qu’elle peut croire et si une information claire permet de comprendre qu’une IA intervient.

Les modèles d’usage général soulèvent une autre question : quel rôle joue l’entreprise dans leur mise à disposition ? Acheter un accès à un modèle ne revient pas automatiquement à développer ou mettre ce modèle sur le marché sous son propre nom.

Une organisation qui développe un modèle ou le met sur le marché sous sa marque peut avoir des responsabilités différentes de celles d’une entreprise qui l’utilise via un service. Dans les deux cas, un usage particulier du modèle peut devoir être classé selon sa finalité.

Nous utilisons le calendrier d’application pour séquencer les travaux plutôt que traiter tous les systèmes en même temps. Cela permet de distinguer les règles déjà applicables des actions à organiser autour d’autres obligations.

Quel calendrier d’application prévoir pour votre mise en conformité ?

Le calendrier sert à séparer les obligations déjà applicables de celles à préparer. Il a été modifié en 2026 : le règlement dit « Digital Omnibus sur l’IA », approuvé par le Parlement européen le 16 juin 2026 et adopté par le Conseil de l’UE le 29 juin 2026, reporte les obligations relatives aux systèmes à haut risque.

Les échéances à retenir après le Digital Omnibus

Utiliser le report sans relâcher l’effort

Le report ne suspend pas les obligations déjà en vigueur : les interdictions, la maîtrise de l’IA par les équipes, les règles sur les modèles d’usage général et la transparence s’appliquent aujourd’hui.

Il donne en revanche du temps pour préparer les systèmes à haut risque. Pour un outil de recrutement ou de scoring, ce délai se consomme vite entre l’inventaire, les échanges avec les fournisseurs et la mise en place des contrôles.

Nous suivons les publications officielles (Journal officiel de l’UE, lignes directrices de la Commission) pour ajuster le plan, puis traduisons chaque échéance en responsabilités internes et en dispositif de gouvernance.

Qui doit piloter la gouvernance IA dans votre organisation ?

Même dans une petite structure, un nom doit être associé à la décision d’autoriser un nouvel usage. Nous désignons un référent IA et des relais capables de faire remonter les questions, sans créer une équipe disproportionnée.

Le référent organise les décisions, suit les actions et fait circuler les changements vers les personnes concernées. La gouvernance doit rester assez simple pour s’intégrer aux pratiques de l’organisation.

Nommer un référent et répartir les responsabilités

Le référent peut s’appuyer sur la DSI, les équipes métier, le juridique ou la conformité, les RH et les achats. Nous mobilisons ces relais selon les systèmes utilisés, plutôt que de réunir toutes les fonctions pour chaque décision.

Nous définissons qui valide un usage, qui peut l’escalader et qui organise sa revue. Une demande de pilote peut, par exemple, suivre le circuit métier, puis passer à la DSI si elle touche des données ou des services sensibles.

Un canal de déclaration interne aide les salariés à signaler un nouvel outil ou une fonction activée. Sans ce point de remontée, la gouvernance ne voit que les achats officiels et manque les usages apparus dans les équipes.

S’appuyer sur ISO/IEC 42001 sans la confondre avec le règlement

ISO/IEC 42001 est un standard de système de management de l’intelligence artificielle. Il peut structurer la gouvernance, l’amélioration continue et les contrôles liés à l’IA.

Ce standard ne remplace ni l’AI Act ni le RGPD. Il ne garantit pas automatiquement la conformité : les obligations dépendent toujours des rôles, des systèmes et des usages de l’entreprise.

Une gouvernance utile associe donc une personne qui arbitre à des processus réellement suivis. Les fournisseurs doivent y contribuer en transmettant des informations vérifiables sur leurs systèmes et leurs changements.

Quels contrôles demander aux fournisseurs d’IA ?

Un fournisseur qui décrit un outil comme « assistant » ne répond pas encore à la question de son usage réel. Nous examinons les fonctions activées et les preuves disponibles avant l’achat.

Les contrôles portent sur le système effectivement utilisé, pas seulement sur sa fiche commerciale. Les équipes achats et DSI peuvent partager les vérifications, puis faire intervenir le métier selon la finalité du service.

Vérifier le système avant l’achat

Nous testons les fonctions réellement activées : génération, classement, résumé ou recommandation. Une fonction masquée dans un menu peut modifier les données transmises ou les résultats produits. Le fournisseur doit expliquer les limites utiles à l’équipe qui exploitera le système.

Suivre les changements et les incidents

Nous prévoyons une notification des mises à jour qui changent la finalité, les fonctionnalités ou les conditions d’utilisation. Un incident doit aussi pouvoir être signalé selon un processus connu, avec un contact et une trace de traitement.

Une évolution importante peut imposer une nouvelle analyse, même si le nom du produit et le contrat restent identiques. Nous relions les échanges avec les fournisseurs à une documentation interne qui conserve les décisions et leurs preuves.

Quelle documentation conserver pour démontrer votre démarche ?

Face à une question de conformité, une décision datée et justifiée est plus utile qu’une déclaration générale d’intention. Nous gardons des preuves proportionnées au rôle et au niveau de risque de chaque système.

Un dossier lisible permet de répondre aux questions d’un client, d’un partenaire ou d’une autorité. Il aide aussi les équipes à reprendre une décision après un changement de personne ou de fournisseur.

Constituer un dossier proportionné à chaque système

Nous conservons au minimum cinq éléments utiles :

1. La fiche du système et sa finalité prévue.
2. La décision de classification et sa justification.
3. Les rôles exercés et les personnes responsables.
4. Les informations reçues du fournisseur et les mesures de contrôle.
5. Les preuves de formation et de supervision adaptées au cas.

La documentation technique détaillée dépend du rôle de l’entreprise et du niveau de risque. Un déployeur n’a pas nécessairement le même dossier technique qu’un fournisseur qui met un système sur le marché sous son nom.

Nous conservons des éléments compréhensibles, pas une accumulation de fichiers sans lien. La personne qui relit le dossier doit pouvoir retrouver la décision, les raisons retenues et les contrôles qui ont été mis en place.

Mettre à jour les preuves après un changement

Un changement de fournisseur, de fonctionnalité, de données, de finalité ou de responsables déclenche une mise à jour. Nous datons la révision et indiquons ce qui a changé, afin de distinguer une décision actuelle d’un document devenu obsolète.

Une mise à jour doit aussi suivre les incidents qui révèlent un usage différent de celui qui était prévu. Nous vérifions ensuite que les dossiers relatifs aux données personnelles et aux systèmes d’IA se répondent.

Comment articuler l’AI Act et le RGPD ?

Un outil de sélection de candidats peut soulever à la fois des questions de données personnelles et de décision assistée par IA. Le RGPD et l’AI Act peuvent s’appliquer simultanément, sans que l’un remplace l’autre.

Nous partons des données traitées, puis examinons séparément les obligations liées au traitement et celles liées au système d’IA. Cette distinction évite de considérer un dossier RGPD comme une réponse complète à toutes les questions.

Repérer les traitements de données personnelles

Nous identifions les données personnelles, les finalités et les personnes concernées. En RH, il peut s’agir des candidatures ou des informations de salariés. En relation client, un outil peut traiter des échanges, des demandes ou des historiques de service.

Cette analyse aide à comprendre qui fournit les données, qui accède aux résultats et quelles conséquences le traitement peut avoir. Nous vérifions notamment si les données sont utilisées pour une finalité différente de celle annoncée aux personnes.

Réutiliser les analyses sans fusionner les obligations

Les analyses déjà menées au titre du RGPD peuvent servir de base. Nous les complétons par les questions propres aux risques algorithmiques, à la supervision humaine et à la sécurité du système.

Un socle de gouvernance commun évite les registres contradictoires et les décisions dispersées. Il ne doit pas effacer les exigences propres à chaque règlement, ni confondre les responsabilités associées au traitement de données et à l’utilisation d’un système d’IA.

Nous relions donc les analyses utiles, tout en gardant visibles leurs objectifs distincts. Les conclusions doivent ensuite devenir des consignes compréhensibles pour les équipes qui utilisent les outils, notamment en RH et dans le service client.

Comment former les équipes à un usage responsable de l’IA ?

Un recruteur et un utilisateur d’assistant de rédaction n’ont pas besoin des mêmes consignes pratiques. Nous adaptons la sensibilisation aux tâches, aux systèmes et aux personnes qui les utilisent ou les supervisent.

Une session générale peut poser un socle commun, mais elle ne suffit pas à expliquer les limites d’un outil RH ou d’un assistant bureautique. Les consignes doivent porter sur les situations que les équipes rencontrent réellement.

Adapter la sensibilisation aux métiers et aux systèmes

Nous abordons les capacités et les limites de chaque outil, les risques associés et les données à ne pas transmettre. Nous rappelons aussi quand un résultat doit faire l’objet d’un contrôle humain et comment signaler une réponse erronée.

Les consignes peuvent varier selon les rôles :

• Un recruteur vérifie les critères utilisés et ne délègue pas une décision à un score sans examen.
• Un manager contrôle les résultats avant de les utiliser pour attribuer des tâches.
• Une équipe support vérifie les réponses générées avant de les envoyer à un client.
• Un salarié utilisant un assistant de rédaction évite d’y saisir des données confidentielles sans validation.

Garder une trace et prévoir les échanges internes

Nous conservons la date de chaque sensibilisation, le public concerné, le contenu présenté et les consignes diffusées. Ces éléments montrent si les équipes ont reçu une information adaptée à leur usage.

L’introduction d’un système qui touche aux conditions de travail peut nécessiter des échanges ou consultations internes, selon le cadre applicable en France. Nous associons les interlocuteurs concernés avant le déploiement, plutôt que d’annoncer l’outil une fois les pratiques installées.

Quelle checklist suivre pour lancer votre mise en conformité ?

Le premier livrable utile n’est pas un dossier exhaustif, mais une liste de systèmes avec un responsable pour chacun. Nous lançons la mise en conformité par étapes, en donnant la priorité aux usages réels.

Cette méthode permet aux dirigeants, à la DSI et à la DAF de suivre les décisions sans attendre une cartographie parfaite. Chaque étape doit produire un résultat vérifiable et une personne chargée de la suite.

Dans les premières semaines, rendre les usages visibles

Nous faisons valider le référent IA et demandons aux métiers de déclarer les usages. Les responsables repèrent les fonctions intégrées aux logiciels et les outils utilisés en dehors des achats officiels.

Nous constituons ensuite un registre initial avec un responsable pour chaque entrée. Il reste volontairement simple : la priorité est de rendre les systèmes visibles et de savoir qui peut répondre à une question sur leur usage.

Après le premier inventaire, traiter les risques prioritaires

Nous organisons les actions suivantes dans un ordre suivi :

1. Examiner les usages potentiellement interdits et suspendre ceux qui appellent une analyse.
2. Classer les autres systèmes selon leur finalité et leur utilisation réelle.
3. Vérifier les systèmes susceptibles d’être à haut risque.
4. Contacter les fournisseurs des outils prioritaires.
5. Lancer la formation adaptée aux équipes concernées.
6. Fixer une date et un responsable pour la prochaine revue.

Une checklist signée ne remplace pas les vérifications de fond. Nous vérifions que les décisions reposent sur les fonctions réellement utilisées et que les actions ont été faites, pas seulement cochées.

Les usages et les règles évoluent : nous maintenons donc le dispositif par des revues déclenchées par les changements et une date de suivi définie. Cette routine transforme un premier état des lieux en travail continu.

Comment maintenir la démarche à jour et mobiliser les dispositifs d’aide ?

Une fonctionnalité ajoutée à un outil existant peut rendre nécessaire une nouvelle revue, même si aucun projet IA n’a officiellement été lancé. Nous réexaminons un système lorsqu’évoluent son fournisseur, sa finalité, ses données ou son usage.

Nous intégrons aussi les évolutions de la réglementation dans le suivi interne. Les guides, canaux de communication et autres dispositifs européens peuvent aider les entreprises à comprendre leurs obligations et à organiser leurs travaux.

Un changement de fonction ou de contexte peut modifier l’analyse d’un système déjà utilisé. Une revue régulière évite de laisser l’inventaire décrire une situation dépassée.

Les bacs à sable réglementaires peuvent offrir un environnement encadré pour tester certains projets. Ils soutiennent l’innovation et une mise en œuvre proportionnée, mais ne dispensent pas les PME des obligations applicables et ne réduisent pas automatiquement leur portée.

Nous distinguons l’appui opérationnel d’un conseil juridique. Un accompagnement peut aider à organiser l’inventaire ou les contrôles, tandis que les arbitrages juridiques peuvent demander une analyse adaptée au cas de l’entreprise.

Les dispositifs de soutien ne remplacent pas la responsabilité de l’organisation. Nous pouvons transformer l’état des lieux en diagnostic de maturité et en feuille de route priorisée, en commençant par les usages qui appellent le plus d’attention.

Conclusion

Une feuille de route utile commence par quelques décisions vérifiables plutôt que par un programme trop vaste. Nous pouvons d’abord rendre les usages visibles, nommer un responsable et conserver les raisons de chaque choix.

Pour structurer les priorités, demandez un diagnostic de maturité IA à Nitrolabz, cabinet de conseil IT en cybersécurité, IA et agilité basé à La Défense. Ce travail aide à transformer les besoins de votre PME en actions adaptées à son organisation.

Prenez contact avec Nitrolabz pour cadrer votre diagnostic de maturité IA et définir les prochaines étapes de votre mise en conformité.

Cet article a une vocation informative et ne constitue pas un avis juridique. Calendrier à jour au 20 octobre 2026.

FAQ

Les fonctionnalités d’IA intégrées à un logiciel que nous avons déjà acheté doivent-elles figurer dans l’inventaire ?

Oui, si elles répondent à la définition d’un système d’IA et sont utilisées dans un cadre professionnel. Nous vérifions les fonctions activées, leur finalité et les tâches auxquelles elles servent réellement. Une option disponible mais jamais activée ne correspond pas nécessairement à un usage effectif. Le registre doit toutefois permettre de la repérer si son activation est prévue.

Un salarié peut-il utiliser un outil d’IA public avec des données de l’entreprise ?

La réponse dépend des données, des règles internes et des paramètres du service. Avant tout transfert d’informations confidentielles ou personnelles, nous demandons une validation au responsable désigné. Les équipes doivent aussi vérifier ce que le service conserve ou réutilise, ainsi que les conditions d’accès. Une règle interne claire évite que chaque salarié prenne seul cette décision.

Le report du Digital Omnibus permet-il d’attendre 2027 pour agir ?

Non. Le report concerne les obligations des systèmes à haut risque, désormais applicables au 2 décembre 2027 pour l’annexe III. Les interdictions, la maîtrise de l’IA, les règles sur les modèles d’usage général et la transparence s’appliquent déjà. L’inventaire et la classification doivent donc commencer maintenant.

Faut-il traiter un modèle d’IA à usage général comme un système à haut risque dans tous les cas ?

Non, nous classons l’usage précis et sa finalité, pas le modèle dans l’abstrait. Un accès général à un modèle ne correspond pas automatiquement à un système à haut risque. En revanche, un usage lié à une décision sensible peut entraîner des exigences différentes. Nous examinons alors la tâche confiée, les personnes concernées et les effets possibles du résultat.

À quelle fréquence faut-il revoir la classification d’un système ?

Nous la revoyons à chaque changement de finalité, de fonctionnalité, de fournisseur, de données ou de contexte d’utilisation. Une revue est aussi prévue selon le cycle défini en interne, même sans changement signalé. Nous datons chaque réexamen et indiquons s’il confirme ou modifie l’analyse précédente.

Une analyse d’impact RGPD suffit-elle à couvrir toutes les questions de l’AI Act ?

Non, une analyse d’impact RGPD peut fournir un socle utile, mais elle ne couvre pas automatiquement toutes les questions de l’AI Act. Nous la complétons par l’examen des risques propres au système, de la supervision humaine et de la sécurité. Les deux règlements peuvent s’appliquer simultanément, avec des obligations qui restent distinctes.

Une PME peut-elle utiliser un bac à sable réglementaire pour tester un projet d’IA ?

Oui, certains dispositifs permettent de tester des projets dans un cadre encadré. L’accès dépend des critères du dispositif, de l’autorité compétente et des règles applicables au projet. Un bac à sable ne constitue ni une exemption générale ni une réduction automatique des obligations.