La plupart des articles sur l’AI Act européen s’interrogent sur ce qu’il signifie pour les nouveaux projets d’IA. C’est la moitié la plus facile de la question.
La moitié la plus difficile (celle qui atterrit sur les équipes techniques) concerne les systèmes que vous exploitez déjà. L’ERP avec un module de scoring ajouté par quelqu’un en 2022. La plateforme de support avec tri automatisé. L’assistant client mis en ligne l’an dernier. Ils tournent aujourd’hui en production, et l’AI Act les concerne.
Cet article couvre ce qu’est l’AI Act dans les grandes lignes, ce qu’il change pour la maintenance et l’évolution des systèmes existants, et comment l’aborder concrètement.
Une précision : il s’agit de conseils pratiques d’un point de vue d’ingénierie, non d’un avis juridique. Pour les décisions de classification et tout ce qui a des conséquences, impliquez votre conseil juridique.
L’AI Act dans les grandes lignes
L’AI Act européen est la première réglementation horizontale complète sur l’intelligence artificielle. Il est entré en vigueur le 1er août 2024 et s’applique par étapes plutôt que d’un seul coup.
Deux idées font l’essentiel du travail.
D’abord, il est fondé sur le risque. Les obligations dépendent de ce que fait le système d’IA, pas de la technologie employée :
- Pratiques interdites : un petit ensemble d’usages purement prohibés. Applicables depuis février 2025.
- Systèmes à haut risque : une liste définie incluant l’IA utilisée dans le recrutement, la notation de crédit, l’éducation, la catégorisation biométrique, les forces de l’ordre, ainsi que l’IA intégrée à des produits réglementés comme les dispositifs médicaux et les machines. Ce sont les obligations les plus lourdes : gestion des risques, gouvernance des données, documentation technique, journalisation, supervision humaine et évaluation de conformité.
- Risque limité / transparence : les systèmes qui interagissent avec des personnes ou génèrent du contenu synthétique. L’exigence centrale est l’information : les gens doivent savoir qu’ils ont affaire à une IA ou qu’ils voient un contenu généré par IA.
- Risque minimal : tout le reste, sans obligations spécifiques.
Ensuite, votre rôle compte. L’AI Act distingue les fournisseurs (ceux qui développent et mettent un système d’IA sur le marché) des déployeurs (ceux qui l’utilisent sous leur propre autorité). La plupart des PME sont déployeurs, mais dès lors que vous faites développer un système d’IA sur mesure, ou que vous en modifiez un substantiellement, vous pouvez vous retrouver avec des obligations de fournisseur.
Où en est le calendrier
L’échelonnement a évolué depuis l’adoption du texte, mieux vaut donc être précis :
- Pratiques interdites et obligation de maîtrise de l’IA : applicables depuis le 2 février 2025.
- Règles sur les modèles d’IA à usage général : applicables depuis le 2 août 2025.
- Obligations de transparence (article 50) : applicables depuis le 2 août 2026. Elles sont actives et concernent un large éventail d’organisations utilisant l’IA générative. Pour les systèmes générant ou manipulant du contenu synthétique déjà présents sur le marché avant cette date, l’exigence de marquage lisible par machine a été reportée au 2 décembre 2026.
- Obligations haut risque : reportées par le Digital Omnibus de 2026. Les systèmes autonomes à haut risque (annexe III : recrutement, notation de crédit, etc.) s’appliquent désormais à partir du 2 décembre 2027 ; l’IA intégrée à des produits réglementés (annexe I) à partir du 2 août 2028.
Le report des échéances haut risque offre un vrai répit, mais il faut le lire correctement : tout n’a pas été reporté. Les interdictions, les règles GPAI et les obligations de transparence sont restées à leurs dates d’origine. Si votre système parle à des clients ou génère du contenu, la date pertinente est déjà passée.
Ce que cela change pour la maintenance des systèmes existants
C’est ici que cela devient concret pour les équipes techniques. Six choses changent.
1. On ne peut pas se conformer à ce qu’on n’a pas inventorié
Le premier problème pratique n’est pas juridique mais archéologique. La plupart des entreprises n’ont pas de liste complète des endroits où l’IA se trouve déjà dans leurs systèmes. Un moteur de recommandation ici, un modèle de classification là, un pipeline d’OCR, un module fournisseur dont la fonction « intelligente » s’avère être un modèle. Une partie a été ajoutée il y a des années par des personnes qui sont parties depuis.
Avant de pouvoir répondre à toute question de classification, quelqu’un doit cartographier : quelle IA tourne, ce qu’elle fait, quelles données elle touche, à qui appartient le modèle, et dans quel système il est intégré. Pour une entreprise avec des systèmes historiques, c’est véritablement un exercice de maintenance et de documentation, pas un exercice juridique.
2. Les obligations de transparence touchent des systèmes déjà en production
L’article 50 est celui qui exige le plus souvent des modifications de code sur des logiciels que vous exploitez déjà. Si un système interagit avec des personnes, celles-ci doivent généralement savoir qu’elles ont affaire à une IA. S’il génère ou manipule du contenu, cette sortie doit généralement être marquée comme générée artificiellement.
Pour un chatbot ou un assistant mis en ligne il y a deux ans, ce n’est pas une décision de politique interne. C’est une modification de l’interface, du pipeline de sortie et éventuellement du modèle de données. C’est du travail de maintenance, sur un système en production, avec une échéance à la clé.
3. Une « modification substantielle » peut changer vos obligations
C’est le point le plus pertinent pour la maintenance, et le plus facilement oublié.
Les obligations s’attachent aux systèmes tels qu’ils ont été mis sur le marché, mais des changements significatifs de la finalité prévue ou de la conception d’un système d’IA peuvent le faire rentrer dans le champ d’application, ou vous faire passer de déployeur à fournisseur. Concrètement, une décision de maintenance peut avoir une conséquence réglementaire : étendre un modèle de tri pour qu’il classe aussi des candidats à l’embauche n’est pas qu’une fonctionnalité ; cela peut faire basculer ce système en catégorie haut risque.
Implication pratique pour l’ingénierie : les modifications de fonctionnalités d’IA appellent une revue de classification avant la mise en production, pas après. Cela change la façon de trier un backlog de maintenance.
4. Documentation et journalisation cessent d’être une hygiène optionnelle
Pour les systèmes à haut risque, la documentation technique, la tenue de registres et la journalisation automatique sont des exigences explicites. Mais même en dessous de ce seuil, pouvoir répondre à « que fait ce modèle, sur quelles données, et qu’a-t-il décidé en mars dernier » fait la différence entre une demande gérable et une gestion de crise.
La plupart des systèmes historiques échouent aujourd’hui à ce test, non par négligence, mais parce que personne ne l’avait demandé auparavant. Rétro-installer journalisation et documentation dans un système en fonctionnement est un travail de maintenance classique, et cela prend un temps qu’une échéance n’accorde pas rétroactivement.
5. La supervision humaine doit exister dans le flux de travail, pas dans la politique
Là où les obligations s’appliquent, la supervision humaine doit être effective : une personne capable de comprendre, surveiller et outrepasser la sortie du système. C’est une propriété d’architecture, pas un paragraphe dans un manuel. Si un système approuve, rejette ou envoie automatiquement sans point d’intervention pratique, en ajouter un est une modification du flux de travail et souvent du système lui-même.
6. Le sol bouge sous vos pieds
Le modèle que votre système appelle est déprécié. Le fournisseur change ses conditions, ou sa région de traitement. Une nouvelle version du modèle se comporte différemment sur les mêmes entrées. Les normes et lignes directrices continuent de paraître, et les calendriers eux-mêmes ont déjà bougé une fois.
Un système doté d’IA n’est pas un actif « on le construit et on l’oublie ». Il exige la même attention continue que tout système critique, plus une dimension de conformité qui n’existait pas auparavant.
Comment Dink peut aider
C’est, au fond, le travail que nous faisons déjà, appliqué à un problème plus récent. Dink maintient et modernise les systèmes dont dépendent les PME en Belgique et aux Pays-Bas, et l’AI Act transforme plusieurs de nos habitudes en exigences.
Trouver ce qui existe réellement. Notre technology assessment est une revue structurée d’une plateforme existante : ce qui tourne, sur quoi, intégré à quoi. L’étendre à un inventaire des composants d’IA et des données qu’ils touchent est la première étape naturelle vers toute décision de classification.
Effectuer les modifications en sécurité. Ajouter l’information de transparence, rétro-installer la journalisation, intégrer une étape de supervision : ce sont des modifications sur des systèmes en production qui ne peuvent pas tomber. Déploiements progressifs, changements réversibles et tests : c’est déjà notre manière de travailler sur des logiciels critiques.
Documenter ce qui ne vit que dans les têtes. La documentation technique est désormais un artefact de conformité. C’est aussi ce que nous produisons systématiquement lorsque nous reprenons un système, parce que c’est ce qui rend la maintenance à long terme possible.
Examiner les changements avant leur mise en production. Traiter la question « est-ce que cela change ce que fait l’IA ? » comme partie intégrante du flux de maintenance, pour qu’une amélioration de routine ne reclassifie pas discrètement un système.
Le maintenir opérationnel ensuite. Les modèles sont dépréciés, les fournisseurs changent leurs conditions, les lignes directrices évoluent. La maintenance continue est ce qui garde un système doté d’IA à la fois fonctionnel et défendable dans la durée.
Vous ne savez pas quelle IA tourne dans vos systèmes, ni ce que l’AI Act implique pour les évolutions prévues à votre feuille de route ? C’est un bon premier échange, et une bonne raison de commencer par un assessment plutôt que par une reconstruction.
Questions fréquentes
L’AI Act européen s’applique-t-il aux systèmes d’IA déjà en production ? Oui. Le texte concerne les systèmes déjà en usage, même si les obligations dépendent de la catégorie de risque et de la date applicable. Les obligations de transparence de l’article 50 s’appliquent depuis le 2 août 2026 et peuvent exiger des modifications sur des systèmes en fonctionnement, comme indiquer qu’un utilisateur interagit avec une IA ou marquer les contenus générés par IA.
Les échéances haut risque ont-elles été reportées ? Oui, mais uniquement celles-là. Sous le Digital Omnibus de 2026, les systèmes autonomes à haut risque (annexe III) s’appliquent à partir du 2 décembre 2027 et l’IA intégrée à des produits réglementés (annexe I) à partir du 2 août 2028. Les pratiques interdites, les règles sur l’IA à usage général et les obligations de transparence restent à leurs dates d’origine.
La plupart des systèmes d’entreprise sont-ils à haut risque ? Non. La plupart des usages courants (extraction documentaire, recherche dans les connaissances internes, résumé, routage) relèvent de catégories de risque inférieures où la transparence est l’exigence principale. Les catégories à haut risque couvrent des usages définis comme le recrutement, la notation de crédit, l’éducation, la biométrie et l’IA intégrée à des produits réglementés. Si votre système touche ces domaines, traitez-le comme à haut risque jusqu’à confirmation du contraire.
Modifier un système d’IA existant peut-il créer de nouvelles obligations ? Cela le peut. Des changements significatifs de la finalité prévue ou de la conception d’un système d’IA peuvent le faire entrer dans le champ d’application ou faire passer votre rôle de déployeur à fournisseur. C’est pourquoi la revue de classification a sa place dans le processus de maintenance, avant la mise en production plutôt qu’après.
Quelle est la première étape pratique pour une entreprise avec des systèmes existants ? L’inventaire. Cartographiez quelle IA tourne réellement dans vos systèmes, ce qu’elle fait, quelles données elle touche et qui la fournit. On ne peut ni classifier ni se conformer à ce qu’on n’a pas catalogué, et pour la plupart des entreprises disposant de systèmes historiques, cette cartographie est d’abord un exercice d’ingénierie avant d’être juridique.