L'UE veut certifier l'IA avant son lancement. Ce n'est pas là que l'IA échoue.

Tout ingénieur qui a fait tourner quelque chose à l'échelle a appris la même leçon d'humilité : on ne peut pas prouver qu'un système complexe est sûr avant qu'il ne tourne. On le relit, on le teste, on raisonne sur tous les chemins qu'on arrive à imaginer — et il vous surprend quand même en production, parce que la production, c'est l'endroit où finissent par débarquer les entrées qu'on n'avait jamais imaginées. Alors on a arrêté de faire semblant. On instrumente le système, on le surveille, et on se forge les réflexes pour réagir quand il fait quelque chose qu'on n'avait pas prévu. L'Union européenne régule l'IA comme si c'était l'inverse qui était vrai.

Le 11 juin, Bruegel a publié un policy brief de Mario Mariniello — The right balance: how to fix European Union artificial intelligence regulation — qui dit, dans le langage mesuré d'un think tank bruxellois, à peu près ce qu'un SRE vous dirait après une mauvaise nuit d'astreinte : l'AI Act parie trop sur la preuve de sûreté avant le déploiement, et trop peu sur la détection du dommage après. Et il met un prix sur ce pari. S'appuyant sur Haataja et Bryson, Mariniello estime la conformité d'un système d'IA moyen entre 14 623 € et 29 277 € — 9 à 17 % d'un budget de développement de 170 000 €. Lisez-le en argent : entre 9 et 17 centimes de chaque euro dépensé à construire un système d'IA servent à prouver qu'il est conforme, avant qu'il n'atteigne le moindre utilisateur.

Je livre en production des systèmes d'IA qui tombent sous ce régime, et avant ça j'ai passé des années en DevOps et en réponse aux incidents, où tout le métier vivait dans l'écart entre ce qu'on avait validé et ce qui se passait vraiment à 3 h du matin. Chez Conectia, nous avons construit notre présélection de recrutement aux règles haut risque de l'AI Act avant même que la loi ne nous rattrape donc je ne suis pas un outsider qui ronchonne contre la paperasse. J'ai payé cette facture sciemment. Mon problème n'est pas que l'Europe régule l'IA. C'est qu'elle concentre le plus de rigueur sur le seul jour où elle en sait le moins.

On ne certifie pas un système dont le comportement se découvre après le lancement

L'AI Act classe les systèmes selon leur finalité prévue au moment de leur mise sur le marché, et il démontre la sûreté surtout par des documents de conformité déposés avant le lancement. Mais l'IA ne reste pas immobile pour la photo. L'essentiel des vraies capacités d'un modèle — et de ses vrais modes de défaillance — se découvre après le déploiement (le brief s'appuie sur Bengio et al., 2024, pour ce point, et quiconque a livré une fonctionnalité à base de LLM le sait déjà dans ses tripes). Un système classé risque minimal le jour du lancement devient haut risque dès qu'un utilisateur fait quelque chose que le développeur n'avait jamais prévu et ne contrôle pas.

Les preuves s'accumulent précisément dans la catégorie que l'Act laisse passer comme à faible risque : les chatbots. Une étude de mai 2026 sur des requêtes électorales écossaises a trouvé que 34,1 % des réponses de chatbots IA contenaient des erreurs factuelles sur la manière de voter. Au Nevada, quatre chatbots sur cinq testés donnaient de fausses informations sur l'inscription des électeurs. Et en août 2025, Raine c. OpenAI a porté devant un tribunal de San Francisco le rôle d'un chatbot dans le suicide d'un adolescent. Aucun de ces dommages n'est quelque chose qu'une checklist d'avant-lancement aurait pu attraper — parce qu'aucun d'eux n'existait au lancement. La conformité ex ante certifie un instantané. Le système, lui, est un film.

On a déjà quitté la salle de ce film, ça s'appelle le cycle en V

Les ingénieurs ont mené exactement cette expérience, et on en est partis. Pendant des années, on a essayé de certifier qu'une version était correcte avant de la livrer : validations, comités d'approbation des changements, une porte qu'on franchissait une fois et après quoi on priait. On l'a abandonné — pas par imprudence, mais parce que la preuve ne pouvait jamais suivre le rythme du changement. Tout le mouvement DevOps et SRE, c'était la migration de la rigueur de l'avant la release vers l'autour du système qui tourne : observabilité, error budgets, rollback, postmortems sans blâme. On n'a pas cessé de se soucier de la sûreté. On l'a déplacée là où vit vraiment le risque.

Une infrastructure de détection calquée sur le système Sentinel de la FDA — on échantillonne le trafic réel, on guette les événements indésirables en quasi-temps réel. Un dispositif de signalement non punitif des quasi-accidents calqué sur celui de l'aviation, l'Aviation Safety Reporting System qui tourne depuis 1976 — soit un postmortem sans blâme à l'échelle d'une industrie. Une taxonomie standardisée des incidents et un registre public, bâtis sur le cadre 2025 de l'OCDE, pour que le marché tout entier apprenne d'une défaillance une seule fois, au lieu que chaque entreprise l'apprenne à ses dépens. Instrumenter, signaler, réagir. Je fais confiance à cette approche pour une raison toute bête : c'est déjà comme ça que je fais tourner tout ce dont je suis responsable.

La facture payée d'avance offre discrètement le marché aux acteurs en place

Il y a un second problème à charger le coût en amont, et il n'a rien à voir avec la sûreté — il porte sur qui reste debout à la fin. Cette facture de conformité ne se réduit pas à l'échelle. Quinze à trente mille euros et un système de management de la qualité, c'est une erreur d'arrondi pour une grande entreprise et un mur pour une startup de deux personnes. Le RGPD a contribué à la concentration du marché en pénalisant de façon disproportionnée les petites structures. Si bien qu'un régime vendu comme une protection des gens contre une IA puissante peut finir, en douce, par protéger les entreprises d'IA puissantes contre la concurrence.

Il existe un remède qui emprunte au Digital Services Act : on module la charge selon la portée du déploiement. Un palier à audit léger pour les PME — moins de 50 M€ de chiffre d'affaires, ou moins de 100 000 personnes concernées — et seulement pour les usages à dommage réversible ; un palier standard au milieu ; et un palier intense pour les géants, au-delà de 150 M€ ou plus d'un million de personnes concernées, où l'évaluation par un tiers devient obligatoire et où l'autocertification s'arrête. Ajustez le degré de contrôle au rayon de l'explosion, au lieu de pointer une seule porte sur tout le monde. Et il vaut la peine de regarder qui serait chargé de la détection aujourd'hui : plus de 2 000 autorités nationales de surveillance du marché, pour la plupart conçues pour inspecter des produits physiques, face à un Bureau de l'IA d'environ 125 personnes — le genre d'application fragmentée qui handicape déjà les règles tech de l'UE. L'appareil censé attraper un algorithme dangereux a surtout été conçu pour attraper un grille-pain dangereux.

« Lancer et surveiller », c'est aussi un excellent moyen de laisser le dommage arriver d'abord

Voici l'objection la plus forte, et je ne l'esquiverai pas : le monitoring ex post peut sonner comme « avancer vite et casser des choses », avec une bénédiction réglementaire en prime. Et le coût est réel et moche — l'ex post signifie que parfois le dommage survient avant que la réponse n'arrive. Un registre d'incidents ne fait rien pour l'adolescent de l'affaire Raine. Une élection empoisonnée par la désinformation d'un chatbot ne se rollback pas comme un mauvais déploiement. Quiconque vous vend le pur monitoring après-coup comme une montée en gamme sans contrepartie enterre ce chiffre, et il ne faut pas le laisser faire.

Mais ce n'est pas ça, la proposition, et l'axe qui tranche la question, c'est l'irréversibilité. On ne traverse pas un diagnostic médical ou une voiture autonome en mode observer-et-réagir — là, la porte reste en amont, et Mariniello maintient la responsabilité sans faute pour les systèmes interdits et à haut risque, précisément parce que le dommage peut être grave et définitif. Le palier allégé est explicitement clôturé au dommage réversible — emploi, scoring de crédit — pas au diagnostic ni aux véhicules autonomes. La vraie thèse n'est donc pas « ex ante mauvais, ex post bon ». C'est mettre une porte sur ce qui ne peut pas être défait ; instrumenter ce qui le peut.

Et un dernier aveu honnête, parce qu'il joue contre toute l'idée : l'ex post ne marche que si la détection est réelle. L'application après-coup du RGPD lui-même était fragmentée et sous-dimensionnée. Si l'Europe déplace la charge vers l'« après » puis sous-finance cet après — 125 personnes, 2 000 autorités mal assorties, et toujours aucun cadre de responsabilité spécifique à l'IA — elle n'a rien rééquilibré du tout. Elle a dérégulé en appelant ça du monitoring. Mariniello a un nom pour la version mondiale de ce glissement : la « dérégulation mutuellement assurée ». Le volet responsabilité est crucial : déplacer la charge de la preuve hors des épaules de la victime, avec une présomption réfragable de défaut pour les systèmes ordinaires, pour qu'un utilisateur lésé ne soit pas contraint de rétro-concevoir un modèle qu'il ne peut pas voir. La directive européenne sur la responsabilité du fait des produits ne devient applicable que le 9 décembre 2026. Tant qu'une détection financée et une vraie responsabilité ne sont pas toutes deux en place, l'« ex post » n'est qu'un mot plus joli pour « personne ne surveille ».

Ce que je bâtirais dans ma stack d'IA quel que soit le choix de Bruxelles

Ce que la boîte à outils ex post de Mariniello a de discrètement utile, c'est que l'essentiel n'est que de la bonne ingénierie qu'il faut s'approprier, quoi que dise la loi. Si je montais — ou auditais — un produit d'IA ce trimestre, voici le travail, et rien là-dedans n'attend une régulation :

1. Cartographiez la chaîne de responsabilité avant de livrer, pas après le procès. Pour chaque fonctionnalité d'IA, notez qui est sur la sellette quand elle lèse un utilisateur : vous, le fournisseur du modèle, la source de données. L'exemple du crédit immobilier refusé à tort de Mariniello — banque, développeur, fournisseur de LLM, fournisseur des données d'entraînement, tous se renvoyant la balle — c'est votre RACI d'incident. Si cette case est vide, le défendeur par défaut, c'est vous.
2. Tenez votre propre registre d'incidents dès maintenant. Adoptez la taxonomie d'incidents de l'OCDE et consignez-y chaque défaillance d'IA dès aujourd'hui. N'attendez pas un registre européen obligatoire pour commencer à apprendre de vos propres pannes.
3. Ouvrez un canal de quasi-accidents sans blâme. Le système de signalement de l'aviation fonctionne parce que signaler est sûr. Faites en sorte qu'il soit sûr, pour vos ingénieurs, de signaler le modèle qui fait quelque chose d'étrange avant que ça ne devienne un postmortem.
4. Échantillonnez votre propre trafic. Mettez de l'observabilité sur les entrées et sorties du modèle comme vous surveilleriez n'importe quel service en production — dérive, réponses anormales, les cas d'usage pour lesquels vous n'avez jamais conçu. C'est l'idée de Sentinel à l'échelle d'une entreprise, et c'est ainsi qu'on repère l'usage à haut risque avant qu'un régulateur ou un journaliste ne le fasse.
5. Modulez votre propre contrôle selon l'irréversibilité, pas selon l'organigramme. Concentrez la revue humaine là où une mauvaise réponse ne peut pas être reprise ; laissez le travail réversible avancer vite, derrière le monitoring. C'est la thèse entière du brief, appliquée un étage plus bas — et c'est tout simplement de la bonne priorisation.

Réguler l'IA comme un système qui tourne, pas un produit qu'on livre

Le juste équilibre n'a jamais été « plus de régulation » ni « moins ». C'est une régulation pointée vers le moment où vit vraiment le risque. L'AI Act dépense sa rigueur le jour du déploiement — le seul jour où l'on sait le moins comment le système va se comporter — et la facture à tout le monde à parts égales, ce qui frappe le plus fort les plus petits. La correction de Mariniello, c'est de déplacer cette rigueur là où les ingénieurs gardent déjà la leur : autour du système qui tourne, calibrée sur la portée, proportionnée à ce qui ne peut pas être défait, et payée surtout par celui qui est assez grand pour la porter. Ce n'est pas de la dérégulation. C'est la maturité opérationnelle à laquelle nous autres avons été forcés il y a des années — la nuit où l'on a appris qu'on ne peut pas prouver qu'un système est sûr, on peut seulement le surveiller de près et se tenir prêt à agir.

Le brief plaide pour que l'UE n'attende pas 2031 pour amender l'Act. J'irais un cran plus loin : n'attendez pas Bruxelles du tout. L'observabilité et la discipline d'incident qui feraient réellement fonctionner une régulation ex post sont la même discipline qui fait survivre votre produit au contact des vrais utilisateurs. Si vous en êtes encore à cartographier où l'AI Act atterrit sur votre propre stack, commencez par comment Bruxelles a reclassé un outil de recrutement ordinaire en haut risque — puis allez construire la surveillance, parce que le régulateur finira par vous demander si vous l'avez fait.