Articles tech

AI Act for Developers : comprendre les 5 niveaux de risques

L’AI Act pour les développeurs, c’est la première loi vraiment impactante depuis le RGPD. Et elle vient patcher un trou béant dans la raquette.

Le RGPD t’a rendu tes données personnelles. Tu sais désormais quelles infos un service garde sur toi, et pourquoi.

Mais tous les jours, des algorithmes te notent. Ils t’étiquettent, te classent, te scorent.

Uber évalue ton comportement avant ta commande.
Ton flux Insta décide de ce que tu aimes.
LinkedIn met à jour ton “score de profil”.
Tinder juge ton visage.
L’ATS juge ton CV.

Et jamais ils n’expliquent leur fonctionnement.

L’AI Act interdit les boîtes noires.

Et c’est con, mais on en fait tous les jours. Un moteur de recherche, c’est un algo opaque. Pourquoi ce film remonte en premier sur Netflix ? C’est pas un sujet.
Pourquoi ton profil remonte en premier sur Malt ? C’est un sujet.

C’est pour ça que l’AI Act ne parle pas qu’aux juristes : il nous parle à nous, les développeurs. À ceux qui conçoivent les systèmes qui décident, filtrent, recommandent.

Nous allons d’abord voir l’essentiel à connaître. Puis nous passerons à la pratique, avec des exemples concrets.

Partie 1 : Ce qu’il faut savoir sur l’AI Act

L’AI Act c’est un cadre européen pour l’IA et les algorithmes, pas juste les données. (lien officiel)

Le AI Act classe les systèmes en cinq niveaux.

Les quatre premiers évaluent le risque. Le cinquième est un cas particulier qui dépend surtout de la taille du modèle.

Niveau 1 : Risque minimal.

C’est le niveau le plus bas, celui qui n’implique aucune obligation spécifique.

On y retrouve les IA d’assistance : correcteurs grammaticaux, autocomplétion, suggestion de texte.
Les recommandations non critiques, comme celles de Netflix ou Spotify, mais aussi le moteur de recherche qui t’aide à faire tes courses.
Et les outils créatifs qui n’ont pas d’impact décisionnel. En gros, générer un visuel avec Midjourney, c’est OK. Sauf si c’est utilisé pour influencer quelqu’un à prendre une mauvaise décision.

Tant que ton IA n’a pas d’impact majeur et ne remplace pas la décision d’un humain, c’est carte blanche.
Pas besoin de supervision ni de documentation particulière.

Niveau 2 : Risque limité.

C’est le niveau où la transparence devient obligatoire.

Ces systèmes doivent informer l’utilisateur qu’il parle à une IA, ou qu’il voit un contenu généré par une IA.

On y trouve notamment :

  • Chatbots et assistants virtuels, surtout quand ils se font passer pour des agents humains
  • IA génératives produisant du contenu (texte, image, audio, vidéo)
  • Filtres deepfake et avatars réalistes
  • Recommandations personnalisées qui influencent la perception (classement de profils, classement d’articles, etc.)

Précision importante : générer des images peut rester du risque minimal selon l’usage. La distinction dépend du contexte : si un contenu généré peut tromper un utilisateur qui ignore qu’il s’agit d’une IA, alors il faut clairement le signaler.

Niveau 3 : Haut risque.

Ici on parle des systèmes IA qui peuvent impacter directement la vie, les droits ou la sécurité d’une personne. Et le texte de loi a prévu tout un lot de contraintes et de sanctions.

Les domaines sont clairement nommés : recrutement, crédit, formation, diagnostic médical, un contrôle d’identité. Tous ces moments où tu peux être discriminé, où d’habitude un humain t’ouvre la porte, ou la ferme.

Aux états-unis, la justice a demandé à l’ATS Workday de fournir les données d’entraînement de son HiredScore. Faute de documentation. Pourtant la défense des citoyens montre que l’HiredScore a rejeté automatiquement les candidats de plus de 40 ans.

C’est probablement un biais de sur-apprentissage. L’algorithme a été entraîné sur un jeu de données qui était discriminant et l’a amplifié. Du coup si cet apprentissage n’est pas bien supervisé et bien documenté, on ne peut plus ouvrir la boîte noire.

L’AI Act c’est la réponse à cette situation : plus jamais.
On doit documenter au plus tôt, dès aujourd’hui.
Quand un utilisateur demande pourquoi on doit pouvoir répondre précisément.

On sera quand même d’accord : superviser l’entraînement d’un algorithme non-supervisé c’est pas facile. J’y reviendrai en partie 2.

Niveau 4 : Risque inacceptable.

Le niveau 4 du AI Act est simple : interdit sur le marché européen.

On ne parle pas ici d’algorithmes, mais d’usages jugés incompatibles avec les droits fondamentaux des citoyens européens.

Les cas typiques :

  • Notation sociale : scorer les citoyens comme en Chine.
  • Manipulation cognitive : pousser quelqu’un à agir contre ses intérêts.
  • Reconnaissance biométrique en temps réel dans les lieux publics (caméras connectées, surveillance de masse).
  • Exploitation de la vulnérabilité : cibler des enfants, des malades ou des populations fragiles.

Des algorithmes d’analyse vidéo sont autorisés en France depuis les Jeux olympiques de Paris 2024. Ils servent par exemple à détecter un bagage abandonné ou à mesurer la densité d’une foule, sans identifier les personnes.

Le AI Act permet de voir où passe la limite.  Analyser une scène sans reconnaître quelqu’un est acceptable. Identifier un individu, suivre un visage ou détecter un comportement ciblé ne l’est pas.

Et les amendes sont plus lourdes que pour le RGPD : jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial.

Et la règle s’applique même si le système est hébergé hors d’Europe : ce qui compte, c’est où il est utilisé, et surtout qui est concerné.

Niveau 5 : “General Purpose AI”. On veut encadrer la naissance de l’AGI.

Oui, parce que depuis tout à l’heure il y a un trou dans la raquette.

Le risque est défini par l’usage qu’on en fait. Du coup Mistral, OpenAI et Anthropic peuvent dire : “Nous on avait pas prévu que nos modèles de langages soient utilisés pour ça.”

Ce dernier niveau vise donc les modèles de fondation. Ceux qui sont utilisés pour faire d’autres systèmes.

Les législateurs européens ont donc décidé de leur donner un régime spécifique. Et pour les identifier, ils ont restreint à un critère : 10 puissance 25 flops de puissance de calcul. C’est la puissance de calcul lors de l’entraînement qui sert de barrière.

Alors comment ils ont placé le curseur ?

C’est la puissance de calcul qui a été nécessaire pour entraîner GPT4. Cela correspond à un bâtiment rempli avec une dizaine de milliers de processeurs haut de gamme pendant plusieurs semaines. Autant imaginer la consommation électrique d’une ville française de 30 000 foyers.

Et ils ont désormais plusieurs obligations :

  • publier une documentation technique complète (model cards, datasets, limites connues) ;
  • réaliser une évaluation de sécurité avant mise sur le marché européen ;
  • rendre publique une fiche d’usage responsable pour les entreprises qui les réutilisent ;
  • permettre une supervision humaine à chaque étape critique.

C’est bien pour les développeurs parce que ça re-place la responsabilité sur l’éditeur du modèle.

Après, la partie du système que tu édites doit quand même être documentée si elle rentre sur le niveau 3. Et si tu l’utilises pour du niveau 4, ben c’est quand même ton entreprise qui va prendre les amendes. Mais au moins tu ne dois pas documenter ce que ton LLM fait.

Partie 2 : Un cas pratique de la vraie vie des sides projects.

Cet été, je me suis amusé à faire un side project qui utilise transformers.js.
L’idée, c’était de tester comment exploiter l’accélération matérielle pour faire tourner des modèles directement dans le navigateur.

J’ai donc chargé Whisper et d’autres modèles speech-to-text disponibles sur Hugging Face, dans une simple page web.
Et je me suis mis à parler à mon ordinateur. Sur un bon MacBook, la transcription était presque en temps réel. Sur mon téléphone, par contre, c’était une autre histoire.

Cette fonctionnalité, c’est typiquement une IA d’assistance.
Son risque est considéré comme minimal : niveau 1.

By Tom Morris – Own work, CC BY-SA 3.0 – wikipedia

On ajoute le canard en plastique

Le Rubber Duck Programming existait bien avant les LLMs. Avant JavaScript même.
Un développeur avait remarqué qu’en expliquant son code à un collègue, il finissait souvent par trouver l’erreur lui-même.
Sauf qu’on n’a pas toujours un collègue sous la main.

Alors il expliquait son code à son canard en plastique :

“Et là, tu vois, la variable elle est passée par référence… ah ben c’est pour ça qu’il y a un bug.”

Je me suis dit que mon appli web pourrait faire pareil, un canard en plastique digital, mais qui répond.
J’ai chargé un modèle Mistral 7B pour lui donner la parole. Il ne va pas faire des mathématiques, mais il peut parler comme un perroquet : “Une référence ? Coin !”.

Sauf qu’à ce moment-là, on passe au niveau 2. Parce que les gens pourraient croire que c’est un vrai canard. C’est un chatbot.
Et le AI Act impose une règle simple : il faut indiquer clairement que le canard est une IA.
C’est l’obligation de transparence.

Et si le canard m’aidait à gérer mes émotions ?

Oui, c’est un peu flippant.
Mais dans les faits, ces exercices existent déjà sous une forme papier : les colonnes de Beck, les pensées automatiques, les émotions primaires…
L’idée, c’était juste d’avoir une version numérique qui t’aide à verbaliser ce que tu écris d’habitude.

J’ai donc ajouté un prompt et un appel à l’API Mistral Large pour qu’il reformate le texte dicté en colonnes de Beck.
L’idée, c’est d’aider à identifier les émotions, à distinguer les pensées automatiques, et à formuler des alternatives plus réalistes.

J’avais appelé cette application Auto-psy, mais le nom faisait un peu froid dans le dos. Je l’ai renommée Autotcc.

Et là, clairement, on a franchi un cap : niveau 3, haut risque.

Je dois documenter très précisément les algorithmes utilisés.
Dans mon cas, ça se résume à un super prompt pour Mistral. J’ai mis le code sur GitHub, pour la transparence.

Franchir le Rubicon de l’AI Act, le niveau 4 !

Je ne suis pas allé plus loin, et je pense que la clé Mistral ne fonctionne plus.
L’appli ne tourne probablement plus.

Mais on peut imaginer ce qui se passerait si je voulais pousser le concept. Si cette appli commençait à attribuer un score de santé mentale aux utilisateurs, ou à recommander des traitements. Là, on allumerait tous les voyants rouge fuchsia.

Ce serait un risque inacceptable. Interdit sur le marché européen.

Et à quoi correspondrait le Niveau 5 de l’AI Act ?

Admettons que je décide d’entraîner mon propre modèle de langage spécialisé en santé mentale.
Il me faudrait plusieurs millions d’euros, pour faire tourner des milliers de GPU pendant des semaines.

Et surtout, je devrais documenter les risques associés au modèle.

Le problème, c’est que les modèles commerciaux qu’on utilise aujourd’hui sont souvent fermés.
Leurs paramètres d’entraînement sont inaccessibles. C’est GPT-4 qui a fixé ce standard.
Les concurrents comme LLaMA ou Mistral prennent le contre-pied, en favorisant l’ouverture.

Mais les données d’entraînement restent propriétaires.
OpenAI a dépensé des milliards pour les labelliser à la main et ne compte pas les partager.

Or, ces données sont la source de tous les biais — et donc de tous les risques.

On comprend vite que forcer les éditeurs de modèles de fondation à être transparents, c’est pas gagné.
Et que ça crée une barrière à l’entrée : les développeurs devront s’appuyer sur les éditeurs conformes à la réglementation européenne.

Le niveau de risque ne dépend pas de la puissance du modèle, mais de ce que l’on en fait.

Ce qu’il faut retenir aujourd’hui ?
C’est que l’usage doit être clair et transparent, et qu’on doit documenter nos modèles et nos algorithmes avant que la justice, ou les utilisateurs, ne nous le demandent.

L’effort de transparence doit être proportionnel au niveau de risque.
Et les niveaux sont suffisamment clairs pour s’y retrouver.

Et quand on choisit un modèle ou un éditeur d’IA, autant préférer ceux qui sont conformes à la législation européenne.
Ça nous évite des surprises, et ça nous fait surtout beaucoup moins de travail.

Damien Cavaillès

Recent Posts

On accueille le nouveau CTO 🎉

Un nouveau capitaine technique débarque à la barre de WeLoveDevs ! Après le rachat par…

3 jours ago

Angular, mais en mode « easy » : interview avec Gaetan Redin.

"Venez, faites le module 1 et on en reparle." C’est le défi lancé par Gaetan…

2 semaines ago

OWASP Top 10 : 10 erreurs que les développeurs web font tous les jours (et comment les éviter)

L’OWASP Top 10, c’est un outil pour les développeurs web. Et pourtant, il est largement…

3 semaines ago

RGPD pour les développeurs : coder la confiance avant tout.

Dans cet article, on va parler du RGPD pour les développeurs. C’est un sujet que…

1 mois ago

Monolithe vs Microservices : comment choisir la bonne architecture pour votre application ?

En 2025, le débat monolithe vs microservices n’est toujours pas tranché. Faut-il garder une architecture…

1 mois ago

Déminer l’objection « tu sais pas coder sans IA » en entretien.

"Tu sais pas coder sans IA." C’est devenu la nouvelle phrase passive-agressive des entretiens tech.…

1 mois ago