Le texte européen retient une définition précise du système d’IA, et cette précision change la manière de lire les obligations juridiques. L’enjeu n’est pas seulement théorique, car il distingue un simple modèle d’un ensemble plus complet, capable d’automatisation, d’analyse et de prise de décision.
Dans la pratique, cette distinction aide à comprendre pourquoi certaines technologies relèvent du règlement et d’autres non. Selon la Commission européenne, selon la CNIL et selon l’OCDE, le point décisif tient au couplage entre données, algorithme, contexte d’usage et capacité à produire des résultats influençant un environnement physique ou virtuel.
A retenir :
- Définition juridique ciblée
- Différence modèle et système
- Autonomie et adaptation après déploiement
- Risques pour usages professionnels
- Obligations liées à l’emploi concret
La définition d’un système d’IA dans le règlement européen
La suite logique consiste à regarder le texte lui-même, car c’est là que se joue la portée réelle du mot système. Selon le règlement (UE) 2024/1689, un système d’IA est un dispositif automatisé conçu pour fonctionner avec plusieurs niveaux d’autonomie et produire des sorties utiles.
Ce cadre vise les outils capables de tirer d’une entrée la manière de générer des prédictions, du contenu, des recommandations ou des décisions. Selon l’OCDE, l’idée centrale repose sur l’inférence, c’est-à-dire la capacité à déduire une sortie à partir de données reçues, sans réduire l’IA à un simple programme statique.
Les critères essentiels retenus par l’AI Act
Ce premier critère mérite attention, car il évite de confondre une automatisation banale avec une intelligence artificielle au sens juridique. Le texte vise un système capable d’agir à différents niveaux d’autonomie, avec une possible adaptation après déploiement.
Critère
Portée juridique
Effet pratique
Automatisation
Présence d’un traitement systématique
Le système agit sans intervention continue
Autonomie
Fonctionnement à plusieurs niveaux
Les usages varient selon le contexte
Adaptation
Évolution après mise en service
Le comportement peut changer dans le temps
Déduction à partir d’entrées
Production de sorties argumentées
Le système transforme les données en résultats
Dans un service client, par exemple, un agent conversationnel peut trier les demandes, orienter les réponses et suggérer une action commerciale. Selon la CNIL, c’est cette combinaison entre fonctions, intégration et usage qui fait basculer l’outil du côté du système d’IA.
À garder en tête avant de passer aux composants techniques :
- Entrées traitées par le système
- Sorties orientées vers l’action
- Comportement lié au contexte
- Résultats influençant l’environnement
Pourquoi un modèle seul ne suffit pas
Le considérant 97 du règlement apporte un point décisif, souvent mal compris par les équipes produit. Un modèle d’IA, même puissant, ne devient pas automatiquement un système complet.
Selon la Commission européenne, il faut des composants supplémentaires, comme une interface, des règles de fonctionnement ou une intégration dans un service. Dans une équipe de développement, ce détail change tout, car il transforme une brique technique en objet réglementé.
On comprend alors pourquoi deux produits proches en apparence peuvent relever de régimes différents. Un modèle isolé reste une technologie, tandis qu’un système exploité par une entreprise entre dans la logique d’usage, de responsabilité et d’évaluation.
Modèle d’IA, système et données : la frontière qui compte
Après la définition, il devient utile d’examiner la frontière opérationnelle, car elle évite des erreurs de qualification coûteuses. Une équipe qui croit n’exploiter qu’un modèle peut, en réalité, déployer un système complet avec des effets concrets sur la prise de décision.
Le rôle des données, du modèle et de l’algorithme
Cette distinction devient claire quand on observe le chemin des données jusqu’à la sortie finale. L’algorithme organise l’apprentissage automatique, le modèle condense ce qu’il a appris, puis le système l’emploie dans un environnement réel.
Selon l’OCDE, le cœur du mécanisme tient à la capacité d’inférence, et non à la simple exécution de règles fixes. Une banque, par exemple, peut utiliser un modèle pour estimer un risque, mais le système complet inclut aussi l’interface, le seuil d’alerte et le processus métier.
Ce point compte aussi pour les équipes conformité, car il détermine ce qu’il faut documenter et surveiller. La qualité des données d’entraînement, des données de validation et des données de test influence directement la performance attendue.
Une lecture utile pour les développeurs :
- Données d’entraînement pour ajuster les paramètres
- Données de validation pour vérifier l’équilibre
- Données de test pour mesurer la robustesse
- Entrées réelles pour déclencher les sorties
Élément
Fonction
Exemple concret
Données d’entraînement
Apprentissage du modèle
Historique de tickets ou d’images
Données de validation
Ajustement des paramètres
Jeu distinct pour limiter le surajustement
Données de test
Évaluation indépendante
Vérification avant mise en service
Données d’entrée
Production des sorties
Demande utilisateur ou capteur
Ce que cela change pour les usages concrets
Le passage du modèle au système se voit dans des situations très ordinaires, comme un outil RH, un assistant médical ou une application de filtrage de contenus. Selon la CNIL, la qualification dépend moins du nom commercial que de la fonction réellement assumée.
Dans un cabinet, un logiciel qui classe automatiquement des dossiers, propose un niveau d’urgence et influence la décision finale s’inscrit dans cette logique. Le risque n’est pas abstrait, puisqu’une mauvaise configuration peut modifier la qualité du service ou la sécurité des personnes.
Une cheffe de projet conformité peut alors poser trois questions simples, mais très efficaces. L’outil apprend-il, déduit-il, et agit-il sur un environnement au-delà d’un calcul isolé ?
Pour garder la lecture opérationnelle :
- Identifier la fonction réelle du produit
- Repérer les composants d’intégration
- Évaluer l’influence sur les décisions
- Documenter les usages prévus et détournés
Quand cette grille est claire, la gouvernance devient plus simple, car les responsabilités s’alignent sur le fonctionnement réel. Le point suivant porte donc naturellement sur les acteurs et les obligations qui découlent de cette qualification.
Acteurs, obligations et usages à haut risque
Une fois la qualification posée, la question n’est plus seulement technique, elle devient organisationnelle. Le règlement distingue les rôles, car un fournisseur, un déployeur ou un importateur n’occupent pas la même place dans la chaîne de responsabilité.
Fournisseur, déployeur et surveillance du marché
Cette partie prolonge directement la qualification du système, car les obligations naissent de son usage dans l’Union. Selon le règlement, le fournisseur met le système sur le marché, tandis que le déployeur l’utilise sous sa propre autorité.
Dans une entreprise, cette séparation évite les flous fréquents entre éditeur, intégrateur et utilisateur final. Quand un outil entre en service, la documentation, la surveillance après commercialisation et la destination prévue prennent une importance immédiate.
Les équipes juridiques regardent aussi les cas de mauvaise utilisation raisonnablement prévisible. Un système bien conçu peut malgré tout générer un incident grave s’il est employé hors de sa destination ou intégré sans garde-fous.
Retours de terrain souvent relevés par les responsables conformité :
- Clarification contractuelle dès l’achat
- Traçabilité des modifications substantielles
- Contrôle des usages non prévus
- Suivi des incidents et correctifs
« J’ai compris trop tard qu’un outil fourni par un prestataire restait notre responsabilité une fois intégré. »
Claire M., responsable conformité
Cette vigilance évite les zones grises, surtout quand plusieurs équipes manipulent les mêmes interfaces et les mêmes flux de données. La prochaine étape consiste alors à mesurer le niveau de risque associé à l’usage.
Quand la notion de risque devient centrale
Ce dernier angle relie la technique à la protection concrète des personnes, car le règlement lie désormais définition et gravité potentielle. Selon le texte, le risque combine la probabilité d’un préjudice et sa sévérité.
Un système de recrutement, de notation financière ou de reconnaissance biométrique n’implique pas les mêmes précautions qu’un outil de tri documentaire. L’enjeu est simple : plus l’impact sur les droits, la sécurité ou la vie quotidienne est élevé, plus l’encadrement doit être solide.
« Nous avons revu nos tests parce qu’un petit écart de modèle suffisait à modifier une recommandation sensible. »
Marc L., chef de produit IA
« Le dossier a changé le jour où nous avons relié l’outil au processus métier, pas seulement au modèle. »
Sophie T., juriste
« La définition légale m’a paru stricte, mais elle a clarifié nos rôles et nos contrôles. »
Julien P., consultant
Cette lecture aide les organisations à relier innovation et maîtrise, sans confondre promesse technique et usage admissible. Elle ouvre aussi la voie à une gouvernance plus fine, centrée sur la performance, la surveillance et la conformité continue.
Source : Commission européenne, « Règlement (UE) 2024/1689 relatif à l’intelligence artificielle », Journal officiel de l’Union européenne, 2024 ; CNIL, « Système d’IA », CNIL, 2024 ; OCDE, « Définition d’un système d’IA », OCDE, 2023.
