Le règlement IA européen est entré en vigueur en août 2024 et ses obligations se déploient tout au long de 2026 et 2027. Si vous construisez des logiciels incluant de l'IA — ou conseillez une entreprise qui le fait — vous devez comprendre ce qu'il exige vraiment. Pas le style RGPD "on verra plus tard". Des obligations réelles, des délais réels, des conséquences réelles.
Ceci n'est pas un aperçu juridique. C'est un guide de développeur : ce que la classification signifie pour votre système, quelle documentation vous devez produire, et ce qui change dans la façon dont vous écrivez et déployez du code.
Le système de classification des risques
Le règlement divise les systèmes IA en quatre catégories de risque. L'endroit où se situe votre système détermine presque tout le reste.
Risque inacceptable — interdit purement et simplement
Un petit ensemble de systèmes est totalement interdit : la surveillance biométrique en temps réel dans les espaces publics (avec des exceptions étroites pour les forces de l'ordre), la notation sociale par les gouvernements, la manipulation subliminale, l'exploitation de groupes vulnérables. Si vous construisez l'un de ces systèmes, arrêtez.
Risque élevé — la catégorie qui touche la plupart des logiciels d'entreprise sérieux
C'est là que le règlement a le plus de poids pratique. Les systèmes IA à risque élevé comprennent :
- L'IA utilisée dans le recrutement, la gestion des performances ou l'allocation de travail
- L'IA dans la notation de crédit, le risque d'assurance ou les services financiers
- L'IA dans la gestion d'infrastructures critiques (énergie, transport, eau)
- L'IA dans la santé, les dispositifs médicaux ou les services d'urgence
- L'IA dans l'évaluation éducative ou l'accès à la formation professionnelle
- L'IA utilisée par les forces de l'ordre ou la gestion des frontières
- Les systèmes IA qui influencent les droits fondamentaux
Si votre système prend ou soutient substantiellement des décisions dans l'un de ces domaines, vous construisez un système IA à risque élevé et le cadre de conformité complet s'applique.
Ce que "soutient substantiellement" signifie en pratique est délibérément large. Un système qui classe des demandes de prêt pour qu'un humain les examine est probablement à risque élevé. Un système qui signale la performance des employés pour qu'un manager prenne des mesures est probablement à risque élevé. En cas de doute, supposez risque élevé jusqu'à ce qu'un avis juridique dise le contraire.
Risque limité — obligations de transparence uniquement
Les chatbots et systèmes qui interagissent directement avec les utilisateurs doivent divulguer qu'ils sont de l'IA. Les deepfakes doivent être étiquetés. Si vous construisez une IA conversationnelle orientée client, vous avez besoin d'un mécanisme de divulgation. C'est l'obligation principale ici — et elle est facile à implémenter.
Risque minimal — aucune obligation spécifique
La plupart des systèmes IA utilisés en entreprise — moteurs de recommandation, filtres anti-spam, outils de synthèse de documents — tombent ici. Vous pouvez construire et déployer ces systèmes sans la surcharge de conformité du cadre à risque élevé, bien que de bonnes pratiques d'ingénierie et de gouvernance des données s'appliquent toujours.
Ce que la conformité à risque élevé exige réellement
Si votre système est à risque élevé, voici ce qu'exige le règlement. Ce n'est pas exhaustif — lisez le règlement ou consultez un juriste pour la totalité — mais cela couvre les obligations côté ingénierie.
Système de gestion des risques
Vous avez besoin d'un processus de gestion des risques documenté, maintenu tout au long du cycle de vie du système. Pas un document unique — un processus vivant qui identifie les risques, estime leur probabilité et leur gravité, évalue les résultats des tests, et documente les risques résiduels après atténuations.
En termes d'ingénierie : c'est une version formalisée de ce que les bonnes équipes font déjà informellement. Le règlement exige que vous l'écriviez, le mainteniez à jour, et le liiez à vos artefacts de test.
Gouvernance des données
Les données d'entraînement, de validation et de test doivent respecter des normes de qualité spécifiques : adaptées à l'objectif, représentatives de l'environnement opérationnel, examinées pour les biais, documentées avec leur provenance et leur historique de traitement.
C'est la partie que la plupart des équipes sous-estiment. Si vous avez entraîné sur des ensembles de données publics, vous devez les documenter, examiner leur représentativité, et — si votre système affecte des personnes dans des catégories protégées — examiner les biais. Cet examen doit être consigné par écrit.
Documentation technique
Avant de déployer un système à risque élevé, vous devez produire une documentation technique couvrant : la finalité prévue du système, les caractéristiques techniques du modèle IA, l'approche d'entraînement et les données utilisées, les métriques de performance et les résultats des tests, les mécanismes de surveillance humaine, et les mesures pour assurer la sécurité et la précision.
C'est substantiel. Si vous pensez "on documentera après avoir construit," ce n'est pas conforme. La documentation fait partie de l'artefact de déploiement.
Journalisation et transparence
Les systèmes IA à risque élevé doivent enregistrer suffisamment d'informations pour auditer leurs décisions a posteriori. Quelles entrées ont déclenché quelles sorties. Quelle version du modèle tournait. Quand et comment le système a été utilisé.
Les durées de conservation des journaux dépendent du cas d'utilisation. Pour certaines catégories à risque élevé, les journaux doivent être conservés pendant des années.
Surveillance humaine
Les systèmes à risque élevé doivent être conçus pour permettre une surveillance humaine — pas seulement en théorie, mais en pratique. Cela signifie :
- Le système doit pouvoir être interrompu, contredit ou désengagé
- Les sorties doivent présenter suffisamment d'informations pour qu'un humain puisse les comprendre et les évaluer
- Le système doit signaler sa propre incertitude le cas échéant
Un système conçu pour prendre des décisions entièrement autonomes sans mécanisme de révision humaine n'est pas conforme au cadre à risque élevé. Point.
Évaluation de conformité
Avant le déploiement sur le marché, les systèmes à risque élevé nécessitent une évaluation de conformité — une évaluation formelle visant à déterminer si le système répond aux exigences du règlement. Pour la plupart des catégories à risque élevé, il s'agit d'une auto-évaluation par le fournisseur (documentée). Pour certaines catégories (biométrie, infrastructures critiques, forces de l'ordre), une certification tierce est requise.
Ce qui change dans la façon dont vous construisez
Le règlement IA européen ne mandate pas de technologies ou d'architectures spécifiques. Mais il impose des contraintes qui affectent les décisions d'ingénierie.
L'explicabilité n'est pas optionnelle. Si votre système prend des décisions à risque élevé, il doit être possible d'expliquer pourquoi. Les modèles boîtes noires qui ne peuvent pas être interrogés ne sont pas conformes pour les cas d'utilisation à risque élevé. Cela pousse vers des architectures où le raisonnement est auditable — sorties structurées, scores de confiance, arbres de décision, RAG avec citations de sources — et s'éloigne du "le modèle l'a dit comme ça."
Le versionnage est obligatoire, pas une bonne pratique. Vous devez être en mesure d'identifier exactement quelle version du modèle tournait quand une décision a été prise. Le versionnage des modèles, les enregistrements de déploiement, et la capacité à reproduire les décisions historiques sont des exigences de conformité, pas des bonus.
Les tests de biais sont un livrable. Pour les systèmes à risque élevé, vous ne pouvez pas livrer sans tests de biais et résultats documentés. Si votre système affecte des personnes, vous devez tester s'il affecte différemment les groupes protégés et documenter ce que vous avez trouvé — et ce que vous en avez fait.
Les journaux d'audit sont une préoccupation d'ingénierie de premier plan. La journalisation pour la conformité est différente de la journalisation pour le débogage. Les journaux de conformité doivent être inviolables, conservés pour des périodes définies, et structurés pour être interrogés par les régulateurs. C'est du travail d'infrastructure, pas une pensée après coup.
L'AI Act et les entreprises belges
La Belgique est dans l'UE, donc le règlement s'applique. Ce que cela signifie pratiquement pour une KMO belge :
Si vous déployez un système IA que votre entreprise a construit — même un outil interne — et qu'il tombe dans une catégorie à risque élevé, vous êtes le fournisseur au sens du règlement et le cadre de conformité complet s'applique à vous.
Si vous utilisez un outil IA tiers (un produit SaaS, une API) dans un contexte à risque élevé, vous êtes le déployeur. Vos obligations sont plus légères — principalement s'assurer que l'outil est utilisé dans sa finalité prévue, informer vos travailleurs quand l'IA prend des décisions les affectant, et avoir une surveillance humaine là où elle est requise. Mais la classification des risques reste importante : si vous utilisez un outil tiers pour prendre des décisions à risque élevé, vous ne pouvez pas entièrement vous défausser des obligations.
Pour la plupart des KMO belges utilisant l'IA dans le traitement documentaire, la communication client, ou l'analytique opérationnelle, la réalité pratique est :
- Le système est probablement à risque minimal ou limité — des obligations de transparence et de bonne gouvernance des données, mais pas le cadre complet à risque élevé
- En cas de doute, vous avez besoin d'une décision de classification documentée, pas d'une supposition
C'est là que l'Audit de Préparation IA devient pertinent : une évaluation honnête de ce que vous faites tourner, où cela se situe dans le cadre de classification, et quelles lacunes existent.
La chronologie à retenir
- Février 2025 : Les pratiques IA interdites s'appliquent. Si vous faites tourner un système interdit, c'est déjà illégal.
- Août 2025 : Les obligations des modèles GPAI (IA à usage général) s'appliquent — pertinentes si vous construisez des modèles fondationnels ou déployez des modèles non conçus spécifiquement pour votre cas d'usage.
- Août 2026 : Les obligations des systèmes IA à risque élevé s'appliquent. C'est la grande échéance. Si vous construisez ou déployez un système à risque élevé, vous devez être conforme.
- Août 2027 : Des catégories supplémentaires à risque élevé (systèmes de l'Annexe I — intégrés dans des produits réglementés) s'appliquent.
Si vous lisez ceci à mi-2026, l'échéance d'août 2026 est imminente. Les systèmes à risque élevé doivent être conformes maintenant.
Que faire si vous ne savez pas où vous en êtes
-
Classifiez ce que vous faites tourner. Pour chaque système IA en utilisation ou en développement, déterminez sa catégorie de risque. Documentez cette détermination et le raisonnement.
-
Pour les systèmes à risque élevé, réalisez une évaluation des écarts. Comparez votre documentation actuelle, vos journaux, vos artefacts de test et vos mécanismes de surveillance humaine aux exigences du règlement. Identifiez les lacunes.
-
Priorisez les lacunes qui nécessitent des changements d'architecture. La journalisation et le versionnage sont rétrofitables. L'explicabilité ne l'est pas — si vous avez un modèle boîte noire dans un cas d'utilisation à risque élevé, c'est une décision architecturale à prendre maintenant.
-
Rédigez la documentation. Documentation technique, enregistrements de gouvernance des données, documentation de gestion des risques — cela prend du temps à produire correctement et doit exister avant le déploiement, pas après.
L'Audit de Préparation IA de WDC est conçu exactement pour cette situation : une revue honnête de ce que vous faites tourner, où cela se situe sous le règlement IA européen, et un plan de remédiation écrit. Prix fixe, deux semaines. Si vous démarrez un nouveau projet IA et voulez obtenir la bonne classification dès le départ, c'est ce que couvre l'Évaluation des Opportunités IA. Réservez un appel si vous voulez d'abord en discuter.