Un assistant rédige les réponses du service client, un logiciel classe les candidatures, une équipe marketing fabrique des visuels : l’intelligence artificielle s’est installée sans toujours passer par la direction informatique. Le règlement européen sur l’IA, dit AI Act, oblige désormais à poser des questions très pratiques. Qui utilise quoi ? Pour quelle décision ? Avec quelles garanties ? À l’horizon de septembre 2026, la conformité devient un chantier d’organisation autant qu’un dossier juridique.
Cette analyse s’appuie sur le règlement adopté en 2024 et son calendrier initial. Les échéances présentées sont celles de ce texte ; les projections opérationnelles ne constituent pas un constat de leur mise en œuvre effective en septembre 2026. D’éventuels ajustements législatifs et les textes d’accompagnement doivent être vérifiés dans leur version applicable.
Un calendrier progressif, pas un interrupteur unique
Entré en vigueur le 1er août 2024, l’AI Act organise une application par étapes. Son principe : adapter les exigences aux risques, plutôt qu’imposer le même dossier à un correcteur de texte et à un système de recrutement. Il encadre aussi les modèles d’IA à usage général, qui peuvent alimenter de nombreux services.
- 2 février 2025 : application des interdictions visant certaines pratiques et de l’obligation de prendre des mesures pour assurer une maîtrise suffisante de l’IA par les personnels concernés.
- 2 août 2025 : application notamment des règles relatives aux modèles d’IA à usage général et d’une partie du dispositif de gouvernance.
- 2 août 2026 : application générale prévue par le règlement, comprenant notamment les obligations de transparence et une large partie du régime des systèmes à haut risque.
- 2 août 2027 : échéance prévue pour les systèmes à haut risque liés à certains produits réglementés. Les modèles à usage général commercialisés avant le 2 août 2025 bénéficient également d’une transition jusqu’à cette date.
Ces jalons ne suffisent pas à trancher tous les cas. Pour les systèmes à haut risque déjà mis sur le marché ou en service avant août 2026, des dispositions transitoires existent, notamment en fonction de modifications importantes de leur conception. La date d’achat d’un logiciel n’est donc pas, à elle seule, une réponse juridique.
La première difficulté : savoir quelle IA on utilise
Dans une entreprise, l’inventaire commence rarement par un grand modèle développé en interne. Il commence par les fonctions ajoutées aux outils habituels : résumé de visioconférence, génération de présentations, analyse de dossiers. Il faut aussi retrouver les services utilisés directement par les salariés, parfois avec un abonnement individuel.
Une cartographie utile associe chaque système à son fournisseur, sa finalité, ses utilisateurs, ses données d’entrée et ses conséquences possibles. Un assistant qui reformule une annonce de recrutement n’a pas nécessairement le même statut qu’un outil destiné à filtrer les candidats. La qualification dépend de l’usage prévu et des critères du règlement, pas simplement de l’étiquette « IA ».
Il faut ensuite déterminer le rôle de l’entreprise. Celle qui utilise un système sous son autorité est généralement un déployeur. Celle qui le développe, ou le fait développer et le commercialise sous son nom, peut être un fournisseur. Une modification substantielle ou un changement de destination peut déplacer les responsabilités. Acheter une solution ne transfère donc pas toute la conformité au vendeur.
Transparence : informer, mais surtout au bon endroit
Le règlement n’impose pas d’apposer « créé par IA » sur chaque courriel corrigé automatiquement. Il prévoit des obligations ciblées. Lorsqu’une personne interagit directement avec un système d’IA, elle doit en principe en être informée, sauf si cela ressort manifestement du contexte. Pour un agent conversationnel de service client, l’information doit accompagner l’interaction, pas dormir dans des conditions générales.
Les fournisseurs de systèmes générant des contenus synthétiques doivent prévoir un marquage détectable dans un format lisible par machine, selon les conditions du texte. Les déployeurs ont, de leur côté, des obligations de divulgation pour les hypertrucages et certains textes publiés afin d’informer le public sur des questions d’intérêt public. Des exceptions et adaptations existent, notamment pour les œuvres créatives et certains contenus soumis à contrôle éditorial humain.
Conséquence pratique : communication, marketing et service client doivent examiner leurs parcours de publication. Qui vérifie la présence du marquage ? Qui décide de l’avertissement visible ? Qui conserve la trace du contrôle éditorial ? Une charte générale ne remplace pas ces décisions de production.
Documentation : un dossier proportionné au risque
Pour les systèmes à haut risque, la conformité est plus exigeante. Côté fournisseur, elle comprend notamment gestion des risques, documentation technique, traçabilité, instructions d’utilisation, supervision humaine et exigences de robustesse. Côté déployeur, il faut notamment respecter les instructions, confier la supervision à des personnes compétentes et surveiller le fonctionnement du système.
Les journaux générés automatiquement, lorsqu’ils sont sous le contrôle du déployeur, doivent en principe être conservés au moins six mois, sauf disposition contraire du droit applicable. Dans le travail, l’utilisation d’un système à haut risque implique aussi d’informer les représentants des travailleurs et les salariés concernés avant sa mise en service ou son utilisation.
L’analyse d’impact sur les droits fondamentaux n’est toutefois pas une formalité universelle : elle vise certaines catégories de déployeurs et certains usages. Elle ne se confond pas avec l’analyse d’impact relative à la protection des données du RGPD. Les deux réglementations peuvent s’appliquer simultanément.
Former les équipes, au-delà du tutoriel de prompts
L’obligation de maîtrise de l’IA concerne fournisseurs et déployeurs. Elle demande des mesures adaptées aux connaissances, à l’expérience et à la formation des personnes, ainsi qu’au contexte d’utilisation. Le règlement n’impose pas une certification unique ni un nombre uniforme d’heures de cours.
Un recruteur doit comprendre les risques de discrimination et les limites d’un classement automatisé. Un conseiller clientèle doit savoir quand reprendre la main. Un développeur doit identifier les données qu’il ne peut pas transmettre à un service externe. Pour tous, une compétence centrale demeure : reconnaître qu’une réponse convaincante peut être fausse.
Documenter les formations, tester les acquis et organiser une procédure d’alerte peuvent rendre cette démarche crédible. Une signature au bas d’une charte ne démontre pas, à elle seule, que les équipes savent utiliser l’outil de façon responsable.
Faire de la conformité une routine d’achat
Le levier le plus efficace pourrait être le processus d’achat. Avant tout déploiement, quelques questions structurent le dialogue : quelle classification le fournisseur retient-il ? Quelles instructions fournit-il ? Comment signale-t-il une évolution du modèle ? Quels journaux restent accessibles ? L’évaluation doit réunir métier, informatique, sécurité, juridique et protection des données, plutôt que circuler entre services après un incident.
Et maintenant ? Le scénario le plus plausible est celui d’une conformité intégrée aux gestes ordinaires : acheter, configurer, former, publier, contrôler. Les entreprises qui auront relié leur inventaire à des responsabilités claires pourront plus facilement adapter leurs pratiques aux précisions réglementaires. L’enjeu ne sera pas de produire le plus gros classeur, mais de pouvoir expliquer ce que fait l’IA, pourquoi elle est utilisée et qui peut arrêter son fonctionnement.
