Le règlement européen sur l'intelligence artificielle produit deux réactions symétriques et également coûteuses : la panique, qui gèle tous les projets, et l'indifférence, qui expose à des blocages tardifs. La réalité est plus banale. Pour la majorité des organisations, les obligations réelles sont limitées — mais elles supposent d'avoir fait un travail de classification que presque personne n'a fait.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Sur les usages sensibles, l'accompagnement par un conseil spécialisé reste nécessaire.
Le principe : une réglementation par le risque
Le texte ne réglemente pas « l'IA » en tant que technologie. Il réglemente des usages, classés selon le risque qu'ils font peser sur les droits fondamentaux, la santé et la sécurité des personnes. Le même modèle peut donc relever d'obligations légères dans un contexte et d'obligations lourdes dans un autre.
Conséquence pratique immédiate : la conformité ne se traite pas au niveau de l'outil que vous avez acheté, mais au niveau de chaque cas d'usage que vous en faites.
Fournisseur ou déployeur : la première question
Le règlement distingue plusieurs rôles, dont deux concernent la plupart des organisations :
- le fournisseur, qui développe un système d'IA et le met sur le marché ou en service sous son nom ;
- le déployeur, qui utilise un système d'IA sous sa propre autorité dans un cadre professionnel.
La plupart des PME et administrations sont des déployeurs, dont les obligations sont nettement plus légères. Attention toutefois : construire un outil interne à partir d'un modèle du marché, puis le mettre en service sous votre propre nom, peut vous faire basculer vers des obligations de fournisseur. C'est un point à trancher au cadrage, pas après le développement.
Les quatre niveaux de risque
| Niveau | Exemples | Conséquence |
|---|---|---|
| Inacceptable | Notation sociale, exploitation de vulnérabilités, certaines identifications biométriques | Interdit |
| Haut risque | Recrutement, évaluation des salariés, accès à des services essentiels, sécurité de produits, certains usages publics | Obligations lourdes |
| Risque limité | Agents conversationnels, génération de contenus | Transparence |
| Risque minimal | Aide à la rédaction interne, recherche documentaire, synthèse | Bonnes pratiques |
Dans nos missions, la très grande majorité des cas d'usage identifiés relèvent des deux derniers niveaux. Un assistant qui aide un chargé d'affaires à retrouver une fiche technique n'est pas un système à haut risque. Le dire clairement, documents à l'appui, débloque beaucoup de projets.
Les usages à haut risque, en pratique
Trois familles concernent fréquemment les organisations que nous accompagnons :
- Ressources humaines. Tri de candidatures, aide à la décision de promotion, évaluation de la performance. Dès qu'un système contribue à une décision affectant une personne dans son emploi, la vigilance doit être maximale.
- Accès à des services essentiels. Attribution de prestations, évaluation de solvabilité, priorisation de demandes d'usagers.
- Sécurité. Composants de sécurité de produits ou d'infrastructures.
Pour ces usages, attendez-vous à devoir formaliser : une gestion des risques documentée, une gouvernance des données d'entraînement, une documentation technique, une journalisation, une supervision humaine effective, et une information claire des personnes concernées. Ce n'est pas hors de portée d'une ETI, mais cela se prépare — pas en trois semaines.
Un principe simple à retenir : maintenir une décision humaine réelle, non pas formelle, réduit très substantiellement la complexité. « Réelle » signifie que la personne dispose du temps, de l'information et de l'autorité pour contredire le système.
L'obligation de formation, souvent ignorée
Une obligation transversale est passée largement inaperçue : les organisations qui déploient des systèmes d'IA doivent veiller à ce que leurs personnels concernés disposent d'un niveau suffisant de maîtrise de ces systèmes — compréhension des capacités, des limites et des risques.
C'est, paradoxalement, la meilleure nouvelle du texte : cette obligation converge exactement avec ce qui fait réussir un déploiement. Former sérieusement ses équipes n'est pas une charge réglementaire, c'est la condition de l'adoption. Autant traiter les deux d'un même mouvement.
Articulation avec le RGPD
Les deux textes se superposent sans se remplacer. Dès que des données personnelles sont traitées — et c'est presque toujours le cas — le RGPD continue de s'appliquer intégralement : base légale, minimisation, durée de conservation, information des personnes, analyse d'impact lorsque le traitement est susceptible d'engendrer un risque élevé.
En pratique, l'analyse d'impact relative à la protection des données reste le document pivot. Bien menée, elle couvre une grande partie de ce que la conformité au règlement IA exigera par ailleurs.
Ce qu'il faut faire, concrètement
- Inventorier. Lister tous les systèmes d'IA utilisés dans l'organisation, y compris ceux introduits par les services sans validation centrale. Cet inventaire est presque toujours plus long que prévu.
- Classer. Pour chaque usage, déterminer le rôle (fournisseur ou déployeur) et le niveau de risque. Une page par usage suffit.
- Écrire une charte d'usage. Ce qui est autorisé, avec quels outils, sur quelles données, avec quelle relecture humaine.
- Former. De façon différenciée : sensibilisation large, formation approfondie pour les équipes concernées par des usages sensibles.
- Documenter les usages sensibles. Gestion des risques, supervision humaine, journalisation, information des personnes.
- Réexaminer périodiquement. Les usages dérivent, les outils évoluent. Une revue annuelle est un minimum.
Pour une PME dont tous les usages relèvent du risque minimal, ce travail représente quelques jours. Pour une ETI avec des usages RH ou de sécurité, c'est un chantier de plusieurs mois. Dans les deux cas, l'engager tôt coûte infiniment moins cher que de découvrir le sujet au moment de la mise en production.