AI Act : le calendrier réel,
et ce qu'il change
pour votre application.

Le calendrier officiel

Le règlement (UE) 2024/1689, dit AI Act, ne s'applique pas d'un bloc. D'après le cadre réglementaire publié par la Commission européenne :

• 1^er août 2024 — entrée en vigueur du règlement.
• 2 février 2025 — application des interdictions visant certaines pratiques, et des obligations de littératie en IA.
• 2 août 2025 — application des règles de gouvernance et des obligations pesant sur les modèles à usage général.
• 2 août 2026 — application générale du règlement, incluant les règles de transparence.
• 2 décembre 2027 — obligations pour les systèmes à haut risque relevant de domaines énumérés (biométrie, infrastructures, éducation, emploi, migration).
• 2 août 2028 — systèmes à haut risque intégrés à des produits déjà soumis à une réglementation sectorielle.

Un texte dit « AI Omnibus », entré en vigueur le 27 juillet 2026, a étendu certaines périodes de transition pour les systèmes à haut risque et apporté des clarifications. Un article publié en 2024 ou 2025 sur le sujet est donc probablement dépassé sur ce point précis.

La question qui compte : êtes-vous concerné, et à quel titre ?

Le règlement raisonne par niveau de risque et par rôle. Deux distinctions déterminent presque toute la réponse.

Fournisseur ou déployeur ?

Le texte ne traite pas de la même façon celui qui met un système d'IA sur le marché et celui qui l'utilise dans son activité. La plupart des entreprises qui intègrent un modèle existant dans leur produit se situent du côté de l'utilisation, avec des obligations sensiblement plus légères que celles des fournisseurs de modèles.

Quel niveau de risque ?

La catégorie « haut risque » est souvent invoquée à tort. Elle vise des usages énumérés — biométrie, infrastructures critiques, éducation, emploi, accès aux services essentiels, migration — et non toute application qui utilise de l'IA. Un assistant qui rédige des réponses, résume des documents ou aide à la recherche interne ne relève pas automatiquement de cette catégorie.

Pour la majorité des produits, l'essentiel se résume à des obligations de transparence : indiquer à l'utilisateur qu'il interagit avec un système d'IA quand ce n'est pas manifeste, et signaler les contenus générés artificiellement.

Ce qui pose problème en pratique, et qui n'est pas dans l'AI Act

D'expérience, les difficultés rencontrées par les applications intégrant un LLM relèvent rarement de la qualification réglementaire. Elles sont techniques, et souvent antérieures à l'AI Act :

• Des données personnelles envoyées au modèle sans base légale ni information — un sujet RGPD, immédiatement applicable, dont l'AI Act ne dispense en rien.
• Des instructions système exfiltrables par un utilisateur qui formule sa demande habilement, révélant règles métier, prix ou consignes internes.
• Une injection de prompt indirecte : le modèle traite un document ou une page fournie par un tiers, dans laquelle des instructions ont été dissimulées.
• Aucun garde-fou déterministe en sortie : la réponse du modèle est utilisée telle quelle pour décider ou afficher, sans validation.
• Aucun plafond de coût : une boucle d'appels ou un usage abusif se traduit directement en facture.

Ce sont ces points qu'un audit technique peut établir et corriger — voir l'audit d'application IA. Sur le volet données personnelles, voir la conformité technique RGPD.

Ce qu'Avisers fait — et ne fait pas

Avisers n'accompagne pas la mise en conformité AI Act et ne qualifie pas juridiquement un système au regard du règlement : cela relève d'un conseil juridique spécialisé. Cette page est informative.

Le travail d'Avisers commence là où la question devient technique : que votre application envoie-t-elle réellement au modèle, que fait-elle de la réponse, et que se passe-t-il si quelqu'un cherche à en détourner l'usage.