IA Act : ce que
votre SI doit anticiper

Le règlement européen sur l'intelligence artificielle, l'IA Act, ne classe pas les technologies, mais les usages, par niveau de risque. Savoir où tombe le vôtre n'est plus l'affaire du seul service juridique : c'est devenu une compétence de base pour tout professionnel du système d'information. Un chef de projet qui cadre un outil de scoring, un product owner qui embarque un modèle dans une application, un data analyst qui automatise une décision : chacun manipule, sans toujours le savoir, la matière que le régulateur observe.

Cet article vous donne une lecture opérationnelle du texte, pensée pour le SI et non pour le contentieux. Vous allez pouvoir classer un cas d'usage en un clic, comprendre ce que chaque niveau de risque implique concrètement, voir la traduction métier par métier, situer les échéances du calendrier, et repartir avec une checklist d'audit prête à l'emploi. Testez d'abord un cas d'usage ci-dessous : le classificateur vous donne le niveau et les obligations associées.

Les 4 niveaux, en un coup d'œil

Pourquoi c'est un sujet SI, pas seulement juridique

Beaucoup d'organisations rangent l'IA Act dans la pile « conformité », à traiter par le juridique et le DPO. C'est une erreur de casting. Le juridique peut lire le texte, mais il ne sait pas ce que fait réellement l'assistant que vos développeurs ont branché sur la base documentaire, ni quelles données transitent par le connecteur que votre devops a déployé la semaine dernière. La qualification d'un usage dépend de détails techniques : la nature des données d'entrée, le rôle de la sortie dans une décision, la présence ou non d'un humain qui tranche. Ces détails vivent dans le SI.

Autrement dit, la conformité IA Act est d'abord une affaire de cartographie et de conception. Un système bien pensé au départ (données propres, journalisation, point de contrôle humain) est conforme presque par construction. Le même système bricolé après coup coûte dix fois plus cher à mettre aux normes, quand ce n'est pas impossible. C'est pour cela que le texte parle autant aux architectes et aux chefs de projet qu'aux juristes : la décision de conformité se prend au moment où l'on dessine le flux, pas au moment où l'on rédige le registre.

Le texte distingue deux rôles principaux. Le fournisseur développe ou met sur le marché un système d'IA sous son nom. Le déployeur l'utilise dans le cadre de son activité. La plupart des SI sont déployeurs : ils achètent ou intègrent des outils existants. Mais attention, dès que vous adaptez un système, le renommez ou modifiez sensiblement sa finalité, vous pouvez basculer dans le rôle de fournisseur, avec les obligations plus lourdes qui vont avec. Savoir dans quel rôle on se trouve est la première question à se poser sur chaque cas d'usage.

Les quatre niveaux, décodés pour le SI

La logique du règlement tient en une phrase : plus un usage peut porter atteinte aux droits ou à la sécurité des personnes, plus les obligations sont lourdes. Voici ce que chaque niveau signifie concrètement quand on travaille dans un système d'information.

Risque inacceptable : la liste rouge

Certains usages sont interdits, point final. Il n'existe pas de démarche de mise en conformité qui les rende acceptables. On y trouve la notation sociale généralisée des personnes, la manipulation comportementale qui exploite des vulnérabilités (âge, handicap, situation économique), la catégorisation biométrique fondée sur des données sensibles, ou encore la moisson non ciblée d'images de visages pour constituer des bases de reconnaissance faciale. Dans un SI d'entreprise classique, on croise rarement ces cas, mais ils méritent d'être connus : un projet RH ambitieux qui voudrait « scorer » globalement les salariés sur des critères comportementaux flirte dangereusement avec cette catégorie. La bonne réaction est d'écarter l'idée en amont, pas de chercher à l'aménager.

Haut risque : le cœur du sujet

C'est là que se joue l'essentiel du travail de conformité. Un usage est à haut risque quand il joue un rôle déterminant dans une décision qui affecte les droits d'une personne : trier des candidatures et évaluer des salariés, décider d'un crédit ou d'une prime d'assurance, orienter un parcours scolaire, aider un diagnostic médical, appuyer une décision de justice ou de service public, piloter une infrastructure critique. Ces systèmes ne sont pas interdits, mais ils doivent respecter un socle exigeant : un système de gestion des risques tenu à jour, des jeux de données de qualité et documentés, une documentation technique complète, une journalisation des événements, une supervision humaine réelle (un humain qui peut comprendre, contester et reprendre la main), un niveau suffisant de robustesse et de cybersécurité, et une information claire des personnes concernées. Pour un SI, cela veut dire intégrer ces exigences dans le cycle projet, dès le cadrage.

Risque limité : la transparence suffit

Beaucoup d'usages courants relèvent d'une obligation légère mais réelle : dire que c'est de l'IA. Un chatbot doit signaler qu'il n'est pas humain. Un contenu généré (texte, image, audio) doit pouvoir être identifié comme tel, notamment pour les contenus susceptibles d'induire en erreur. Ce n'est pas un chantier, c'est un réflexe de conception : prévoir la mention, prévoir le marquage. L'oublier, en revanche, transforme un usage anodin en manquement facile à constater.

Risque minimal : la liberté encadrée par le bon sens

La très grande majorité des usages professionnels de l'IA générative (résumer une réunion, reformuler un e-mail, brouillonner un support, explorer une piste d'analyse) ne déclenche aucune obligation spécifique. Le règlement ne vous demande rien de plus ici. Mais « aucune obligation IA Act » ne veut pas dire « aucune précaution » : la protection des données que vous confiez à l'outil, la vérification des sorties et le respect du RGPD restent de mise. Le risque minimal est un permis de faire, pas un blanc-seing.

Trois façons d'aborder la conformité (et une seule qui tient)

Face à l'IA Act, les organisations adoptent en général l'une de ces trois postures. Comparez-les : la différence ne se voit pas le premier jour, mais elle décide de qui subit un audit et de qui le passe sans stress.

La troisième posture demande un investissement modeste au départ (quelques jours de cartographie, un cadre partagé) et supprime la panique de fin de parcours. Les deux premières donnent l'illusion de la tranquillité et reportent, en l'aggravant, le coût réel.

Ce que chaque métier du SI doit repérer

« Se mettre en conformité » ne veut rien dire tant qu'on ne descend pas au niveau du poste. Voici, pour huit rôles typiques d'une DSI, le réflexe IA Act à intégrer dans le quotidien.

• DSI. Tenir le registre des usages d'IA, arbitrer les cas à haut risque, poser la politique de gouvernance des données et désigner qui répond en cas de contrôle. Vous êtes le garant de la vue d'ensemble.
• Chef de projet. Inscrire la qualification de risque dans le cadrage de tout projet embarquant de l'IA, prévoir les jalons de documentation et de supervision humaine, et ne pas lancer en production un usage sensible non classé.
• Product owner. Traduire les obligations en critères d'acceptation testables : mention « IA » visible, marquage des contenus générés, point de contrôle humain sur une décision. La conformité devient une exigence produit comme une autre.
• Business analyst. Repérer, dès l'expression du besoin, si l'usage vise à décider sur des personnes. C'est le signal qui fait basculer vers le haut risque, et il se voit dès l'atelier de cadrage, avant la moindre ligne de code.
• Data analyst. Interroger la qualité et la représentativité des données qui nourrissent un usage sensible, documenter leur provenance, et contrôler les sorties avant qu'elles n'alimentent une décision.
• Architecte SI. Concevoir la journalisation, la traçabilité et le point de reprise humaine dès le schéma d'architecture. Choisir des briques (API, modèle hébergé, RAG) compatibles avec les exigences de documentation et de confidentialité.
• Devops. Outiller la journalisation exigée pour les usages à haut risque, sécuriser les données et secrets confiés aux systèmes, intégrer des garde-fous dans la chaîne de déploiement.
• Développeur. Implémenter les mentions de transparence et le marquage des contenus générés, ne pas court-circuiter le point de supervision humaine, et signaler tout usage qui glisse vers une décision automatisée sur des personnes.

Aucun de ces profils n'a besoin d'être juriste. Chacun a besoin d'un même réflexe : reconnaître, dans son propre travail, le moment où un usage change de catégorie. C'est une compétence qui s'apprend, sur des cas concrets, bien plus qu'une charte à faire signer.

Le calendrier : ce qui s'applique, et quand

Le règlement est entré en vigueur le 1^er août 2024, mais ses obligations s'ouvrent par vagues, pour laisser aux organisations le temps de se préparer. Retenez les grandes bornes.

• Depuis février 2025 : les interdictions. Les usages à risque inacceptable sont proscrits. Si l'un d'eux existe encore dans un coin de votre SI, il devait déjà avoir disparu.
• Depuis août 2025 : les modèles à usage général. Les fournisseurs de grands modèles (dits GPAI) portent des obligations de transparence et de documentation. Côté déployeur, cela se traduit par des fournisseurs qui vous transmettent davantage d'informations à intégrer dans vos propres dossiers.
• À partir d'août 2026 : le régime haut risque. Le socle exigeant (gestion des risques, données, documentation, supervision, journalisation) devient pleinement opposable pour les usages listés. C'est l'échéance qui structure les feuilles de route SI en cours.

La lecture pratique de ce calendrier est simple : le temps qui reste ne sert pas à attendre, il sert à cartographier et à documenter. Un usage à haut risque non préparé aujourd'hui ne se met pas en conformité en une nuit, parce que l'essentiel du travail (qualité des données, traçabilité, supervision) se construit dans la durée.

Testez votre réflexe de qualification

Un cas concret vaut mieux qu'un long exposé. Mettez-vous en situation de cadrage.

Haut risque : les obligations, sans jargon

Si un de vos usages tombe dans la catégorie haut risque, voici ce qu'il faut mettre en place, traduit en langage de projet plutôt qu'en articles de règlement.

• Gestion des risques. Un processus vivant qui identifie ce qui peut mal tourner (erreur, biais, détournement) et les mesures pour l'éviter, revu régulièrement.
• Qualité des données. Des jeux de données pertinents, représentatifs et documentés. On sait d'où ils viennent et ce qu'ils valent.
• Documentation technique. De quoi expliquer ce que fait le système, comment et sur quelles bases. C'est aussi ce qui vous sauve le jour d'un contrôle.
• Journalisation. Une trace des événements permettant de reconstituer une décision après coup.
• Supervision humaine. Un humain formé, capable de comprendre la sortie, de la contester et de reprendre la main. Pas un simple bouton « valider » cliqué à la chaîne.
• Robustesse et sécurité. Un comportement stable, résistant aux erreurs et aux tentatives de manipulation.
• Transparence. Une information claire des personnes concernées sur le fait qu'une IA intervient dans la décision qui les touche.

Aucune de ces exigences n'est exotique pour un SI qui pratique déjà la gestion de projet sérieuse. La difficulté n'est pas technique, elle est d'anticipation : ces éléments doivent exister avant la mise en production, pas être reconstitués après.

Cet article est une vulgarisation à visée pédagogique et ne constitue pas un conseil juridique. Pour un usage à haut risque, faites valider votre analyse par votre DPO ou un juriste.

Le vocabulaire de l'IA Act, retourné

Les mots du règlement reviennent en réunion et servent parfois à impressionner plutôt qu'à clarifier. Voici les principaux, décodés en une phrase. Cliquez une carte pour la retourner.

Pour piloter le chantier de bout en bout — calendrier, gouvernance, fournisseurs, formation tracée — nous avons publié la version longue : AI Act : le guide de conformité du DSI en 6 étapes. L'obligation de formation de l'article 4 se traite avec la formation conformité IAPLC (attestations nominatives + registre employeur).

Par où commencer, concrètement

Si vous deviez ne retenir que trois gestes de cette lecture, ce seraient ceux-là. D'abord, recenser : dressez la liste honnête des usages d'IA déjà présents dans votre organisation, y compris ceux que personne n'a officiellement validés. On ne classe pas ce qu'on ne voit pas. Ensuite, qualifier : passez chaque usage dans la grille des quatre niveaux, en vous concentrant sur ceux qui touchent des décisions sur des personnes. Enfin, documenter les cas sensibles : pour chaque usage à haut risque, commencez le dossier (données, journalisation, point de supervision) sans attendre l'échéance.

Ces trois gestes ne demandent pas d'être expert du règlement. Ils demandent que les bonnes personnes, dans le SI, sachent reconnaître un usage sensible quand elles en croisent un. C'est précisément ce qui s'apprend le mieux sur des cas concrets, tirés de votre propre métier.