Le CRA transforme l'IA en produit a maintenir

Le detail administratif arrive souvent avant la vraie bascule. Dans le cas du Cyber Resilience Act, ce detail a une date : le 11 septembre 2026, les obligations europeennes de signalement des vulnerabilites activement exploitees et des incidents graves commenceront a s’appliquer aux fabricants de produits avec elements numeriques. ENISA prepare la plateforme unique qui recevra ces notifications.

Dit comme cela, le sujet ressemble a une affaire de juristes, de responsables securite et de formulaires europeens. C’est trop court.

Le CRA deplace une frontiere plus profonde : il rappelle qu’un logiciel n’est pas une demonstration. C’est un produit qui vieillit, qui depend de composants, qui peut etre attaque, qui doit etre corrige, et dont quelqu’un doit rester responsable apres la mise en ligne. Pour l’IA en entreprise, cette phrase est plus violente qu’elle n’en a l’air. Une grande partie du marche continue a vendre des “solutions IA” comme des projets : cadrage, prototype, pilote, lancement. Le CRA parle une autre langue : maintenance, vulnerabilite, incident, notification, trace.

La question n’est donc plus seulement : l’IA fonctionne-t-elle le jour de la recette ? La question devient : qui la maintiendra quand elle deviendra un produit ordinaire, expose au monde ordinaire ?

Le mot important n’est pas IA

Le Cyber Resilience Act ne vise pas l’intelligence artificielle en tant que telle. Il fixe des exigences horizontales de cybersecurite pour les produits comportant des elements numeriques mis sur le marche de l’Union europeenne. Le texte couvre une famille large : logiciels, materiels connectes, composants, produits dont la securite depend aussi de traitements distants.

C’est justement ce qui le rend interessant pour l’IA.

Beaucoup de systemes IA d’entreprise ne resteront pas des assistants conversationnels isoles dans un navigateur. Ils seront integres dans des produits, des portails clients, des outils metier, des equipements, des modules de support, des fonctions de recherche, des interfaces de decision ou des couches d’automatisation. Ils auront des versions, des dependances, des secrets, des journaux, des droits d’acces, des flux de donnees et des utilisateurs.

A ce moment-la, le mot “IA” ne suffit plus a les decrire. Ce sont des produits logiciels avec une partie IA.

Cette distinction change la discipline attendue. Un prototype IA peut vivre de promesses : “on verra les cas limites plus tard”, “le prompt sera ameliore”, “le modele evoluera”, “l’utilisateur validera”. Un produit logiciel ne peut pas se contenter de cette brume. Il faut savoir ce qui est livre, ce qui est expose, ce qui a change, ce qui a ete corrige, et ce qui doit etre signale.

La plateforme ENISA rendra visible ce qui etait cache

La Commission europeenne indique que la plateforme unique de signalement sera operationnelle pour l’entree en application des obligations, avec une periode de test avant cette date. ENISA detaille le role de ce Single Reporting Platform : centraliser les notifications relatives aux vulnerabilites activement exploitees et aux incidents graves, puis les router vers les acteurs competents.

Ce n’est pas seulement un canal technique. C’est une contrainte de maturite.

Pour declarer une vulnerabilite exploitee, il faut d’abord savoir qu’elle existe dans son produit. Pour declarer un incident grave, il faut savoir le qualifier. Pour respecter une horloge courte, il faut avoir des roles, des traces, des chemins d’escalade, et une idee assez claire de l’architecture. Sinon, la plateforme ne resout rien. Elle devient seulement l’endroit ou l’entreprise decouvre qu’elle n’a jamais organise sa propre memoire technique.

L’IA aggrave ce probleme parce qu’elle multiplie les zones grises. Une sortie erronee est-elle un bug, un risque metier, une derive de modele, une mauvaise donnee, une attaque par prompt, une faille de controle d’acces, ou une combinaison de tout cela ? Un agent qui appelle un outil non prevu cree-t-il un incident produit, un incident de configuration ou un incident de gouvernance ? Une fuite par contexte conversationnel releve-t-elle du modele, du connecteur, du journal applicatif ou du processus humain ?

Ces questions ne se reparent pas au moment de remplir un formulaire. Elles se preparent dans la maniere de construire.

Le vieux cycle “pilote puis on verra” devient dangereux

Le reflexe classique des projets IA en PME est comprehensible : commencer petit, bricoler vite, garder ce qui marche, jeter le reste. Dans beaucoup de cas, c’est meme sain. Il vaut mieux un pilote court qu’un programme de transformation de dix-huit mois fonde sur des slides.

Mais ce reflexe devient dangereux quand le pilote se fossilise en produit.

Le risque n’est pas le prototype assume. Le risque est le prototype qui reste en place parce qu’il rend service. Un script qui lit des pieces jointes. Un assistant qui prepare des reponses clients. Un module qui classe des tickets. Une recherche semantique branchee sur une base documentaire. Un agent qui cree des taches dans un outil metier. Tant que tout cela reste interne, limite, reversible et surveille, le bricolage peut avoir du sens. Des qu’il devient un composant stable, utilise par plusieurs personnes, dependu par un client ou vendu dans une offre, il change de nature.

Il faut alors lui appliquer une question simple : que se passe-t-il quand il casse ?

Qui recoit l’alerte ? Qui sait quelle version tourne ? Qui peut couper la fonction sans casser le reste ? Qui sait si une dependance est vulnerable ? Qui distingue une hallucination d’un incident de securite ? Qui previent les clients si le produit a expose une donnee ? Qui conserve la preuve que le probleme a ete compris, corrige et suivi ?

Une grande partie de la dette IA actuelle tient dans cette absence de “qui”.

Le NIST parle le langage que les projets IA evitent

Le profil Cyber AI du NIST, encore au stade de projet preliminaire, n’est pas une regle europeenne. Il est utile comme contrepoids methodologique. Il ramene l’IA dans une grammaire de cybersecurite connue : gouverner, identifier, proteger, detecter, repondre, restaurer.

Ces verbes sont moins seduisants que “augmenter la productivite”. Ils sont pourtant plus proches de la vie reelle d’un produit.

Gouverner, c’est savoir qui decide du risque acceptable. Identifier, c’est connaitre les composants, les donnees, les dependances et les usages. Proteger, c’est reduire les acces inutiles et les surfaces d’attaque. Detecter, c’est voir les anomalies avant qu’elles ne deviennent des rumeurs. Repondre, c’est avoir un plan quand l’hypothese optimiste echoue. Restaurer, c’est revenir a un etat fiable sans improviser.

Un projet IA qui ne sait pas se placer dans ces verbes n’est pas forcement mauvais. Il est seulement encore immature. Il peut rester un essai, un outil personnel, une exploration. Il ne devrait pas etre vendu comme un produit robuste.

Le fournisseur serieux aura une reponse ennuyeuse

Pour une PME, le bon signal ne sera pas un fournisseur qui promet une IA “securisee par design” en une phrase. Ce sera un fournisseur capable de repondre calmement a des questions ordinaires.

Quelles versions de modele et de composants sont utilisees ? Comment les mises a jour sont-elles testees ? Quels journaux sont conserves ? Comment les droits d’acces sont-ils limites ? Quels incidents ont deja ete observes ? Quel est le processus de correction ? Qui est responsable de la notification si le produit est concerne par une obligation de signalement ? Comment l’entreprise cliente est-elle prevenue ? Quelle fonction peut etre desactivee en urgence ?

Ces questions semblent basses, presque administratives. Elles sont pourtant plus revelatrices qu’une demo. La demo montre ce que le systeme peut faire quand tout va bien. Les questions de maintenance montrent si quelqu’un a imagine le jour ou tout ira mal.

Dans les achats IA, cette difference devrait devenir centrale. Un outil brillant mais impossible a maintenir devient une dependance opaque. Un outil moins spectaculaire mais exploitable, documente et reversible peut etre un meilleur choix.

L’IA utile ressemblera moins a une campagne

Le CRA ne tuera pas les projets IA. Il ne transformera pas chaque PME en departement conformite. Il ne dira pas, a lui seul, quelles idees sont bonnes ou mauvaises. Mais il ajoute une pression salutaire : arreter de traiter le logiciel comme un evenement de lancement.

Un produit numerique continue apres sa mise en marche. Il recoit des corrections. Il change de dependances. Il rencontre des attaquants. Il se trompe dans des contextes non prevus. Il accumule des exceptions. Il doit parfois etre arrete. L’IA n’echappe pas a cette biographie. Elle la rend simplement plus difficile a lire.

Le marche de l’IA aime les commencements : diagnostic, ideation, prototype, proof of concept, pilote, quick win. La phase qui vient parlera davantage de fins provisoires : fin d’une version, fin d’une dependance, fin d’une tolerance au flou, fin d’un usage devenu trop risque.

C’est moins vendeur. C’est probablement plus sain.

La bonne question pour 2026 n’est donc pas : “Quel nouveau cas d’usage IA lancer ?” Elle est plus austere : “Quels cas d’usage sommes-nous capables de maintenir comme des produits ?”

Tout le reste peut encore rester en jachere.

Cyber Resilience Act, Commission europeenne, ENISA et NIST, verifies le 18 juin 2026.