La Fonctionnalité Qui a Dû Mourir
En mars 2025, une fintech européenne que je connais a silencieusement désactivé une fonctionnalité qui était en production depuis onze mois. La fonctionnalité utilisait du machine learning pour signaler les demandes de crédit à l'attention d'un examinateur humain. Elle fonctionnait bien — leurs taux de défaut avaient baissé de 18 % par rapport au modèle précédent.
Ils l'ont quand même désactivée. Pas parce qu'elle échouait. Parce que leur équipe juridique avait finalement analysé les annexes du Règlement IA européen(lien externe, nouvel onglet) et conclu qu'il s'agissait d'un "système d'IA à haut risque"(lien externe, nouvel onglet) au sens de l'Article 10 — et qu'ils n'avaient aucune des documentations requises.
Le récit que la plupart des équipes produit se font est : "on s'occupera du Règlement IA quand le juridique nous le dira." Mais l'équipe juridique a déjà trois longueurs de retard, car les dispositions relatives aux systèmes à haut risque sont applicables depuis août 2024. La fonctionnalité ci-dessus était non conforme pendant la majeure partie de sa durée de vie.
Ce que le Règlement Est — et N'Est Pas
Le Règlement IA européen n'est pas un RGPD(lien externe, nouvel onglet) pour l'IA. Le RGPD portait sur les données. Le Règlement IA porte sur les systèmes de décision automatisée qui affectent des personnes dans des domaines à forts enjeux.
Il ne régule pas toute l'IA. Il la régule par niveau de risque :
Risque inacceptable — interdit. La notation sociale par les gouvernements, la surveillance biométrique en temps réel dans l'espace public, l'IA qui exploite des vulnérabilités pour manipuler les comportements.
Haut risque — fortement régulé. C'est la catégorie qui compte pour la plupart des équipes produit. Systèmes d'IA utilisés dans : les décisions d'embauche et d'emploi, l'évaluation du crédit et du risque financier, l'aide au diagnostic médical, l'accès à l'éducation et à la formation professionnelle, la gestion d'infrastructures critiques.
Risque limité — obligations de transparence uniquement. Les chatbots doivent se déclarer comme IA. Les deepfakes doivent être étiquetés.
Risque minimal — aucune obligation. Filtres anti-spam, jeux avec IA, algorithmes de recommandation (avec nuances).
Si vous construisez un produit SaaS B2B et que votre IA touche au recrutement, à l'évaluation des performances, au crédit ou à la santé — vous êtes en territoire à haut risque. Et si votre équipe utilise déjà l'IA générative au quotidien, cette ligne est plus proche qu'il n'y paraît.
Les Trois Exigences Qui Vont Prendre les Équipes par Surprise
Évaluation de conformité avant déploiement. Pour les systèmes à haut risque, vous devez effectuer une évaluation de conformité documentée avant de mettre le système en service. Pas avant le passage en GA. Avant que le premier utilisateur ne le voie. La conformité rétroactive n'est pas une conformité.
Documentation technique résistante à un audit. Le Règlement exige un dossier technique couvrant : la finalité du système, les sources de données d'entraînement, les métriques de précision par groupe démographique, les mécanismes de supervision humaine, et les limitations connues. Ce n'est pas un README. C'est un document formel qu'une autorité nationale de surveillance du marché peut demander à tout moment.
Supervision humaine effective. "Un humain examine les recommandations de l'IA" ne suffit pas. Le Règlement exige que l'humain puisse comprendre le raisonnement de l'IA, puisse le contester, et soit formé pour le faire. Une étape de révision qui existe sur le papier mais qu'on contourne en pratique est une responsabilité, pas une garantie.
Workday a fait face exactement à ce problème(lien externe, nouvel onglet) en 2024 quand des plaignants ont soutenu que leurs outils d'embauche IA discriminaient les candidats plus âgés. L'affaire a mis en lumière que des tableaux de bord "human in the loop" ne constituent pas une supervision si les humains valident systématiquement chaque recommandation.
Ce que les Bonnes Équipes Font en Ce Moment
Les équipes que j'ai vues gérer cela correctement n'ont pas attendu qu'un juriste leur signale un problème. Elles ont réalisé un audit interne de deux heures : lister chaque fonctionnalité IA, la classer par type de résultat (recommandation, décision, signalement), mapper le résultat vers un domaine de l'annexe à haut risque, et vérifier l'existence d'une évaluation de conformité.
Pour la plupart des équipes produit, cet audit produit une courte liste inconfortable de fonctionnalités soit à haut risque sans documentation, soit en zone grise nécessitant un avis juridique.
La deuxième étape : séparer la décision produit de la décision de conformité. Certaines fonctionnalités valent l'investissement de mise en conformité. D'autres ne le valent pas — elles sont réduites, cloisonnées ou abandonnées.
La fintech mentionnée a pris la bonne décision. Désactiver une fonctionnalité qui fonctionne est douloureux. Livrer une fonctionnalité auditée avec une supervision adéquate est plus lent. Mais recevoir une amende de 30 M€ et un ordre de retrait du marché de l'ACPR(lien externe, nouvel onglet) française est pire que les deux.
Le Takeaway
Ouvrez votre backlog produit. Pour chaque fonctionnalité IA — en production ou en développement — répondez à une question : est-ce que le résultat de cette fonctionnalité affecte l'accès d'une personne au crédit, à l'emploi, à l'éducation ou aux soins de santé ? Si oui, vous êtes en territoire à haut risque et avez besoin d'une évaluation de conformité. Ce n'est pas une tâche juridique. Ça commence par une décision produit sur ce que fait la fonctionnalité et qui elle affecte — la même appropriation orientée résultats que le rôle exige partout ailleurs. Prenez-en possession avant que votre équipe juridique ne l'hérite.
