Enjeux des régulations numériques pour les entreprises : le guide

Un client m'appelle en février dernier, paniqué. Sa PME de logistique venait de recevoir un questionnaire de sécurité d'un grand donneur d'ordre : 47 questions, dont une bonne dizaine auxquelles il ne pouvait pas répondre. Sa réponse favorite : « on a un antivirus, ça devrait aller ». Ce jour-là, j'ai compris que le vrai enjeu des régulations numériques pour les entreprises n'était plus juridique. Il était opérationnel.

Parce qu'un texte de loi, dans les faits, se transforme toujours en formulaire, en clause contractuelle ou en ligne dans un appel d'offres. Et quand votre fichier client ne sait pas dire quel logiciel tourne dans quel service, vous perdez le marché. Pas parce que vous êtes hors la loi. Parce que vous êtes illisible.

Ce que les régulations numériques changent vraiment pour votre entreprise

Prenons le CRA, entré progressivement en application depuis fin 2024. Le principe est simple : tout produit comportant un élément numérique vendu dans l'Union doit être conçu pour résister à des attaques raisonnables, et le fabricant doit fournir des mises à jour de sécurité pendant une durée annoncée. Jusque-là, on parle du fabricant. Sauf que la chaîne ne s'arrête pas là.

Si vous intégrez une brique logicielle dans votre solution, vous devenez une partie de cette chaîne. Et « partie de la chaîne » signifie, en pratique, que votre client vous demandera des comptes. J'ai vu trois contrats de prestation se faire retoquer l'an dernier sur ce point précis. Pas sur le prix. Sur la clause de vulnérabilités.

Qui est concerné, concrètement ?

La réponse honnête : beaucoup plus de monde que prévu. Un éditeur de logiciel, évidemment. Mais aussi l'entreprise qui revend un produit connecté sous sa marque, celle qui l'héberge, et parfois celle qui se contente de le configurer chez le client final.

• les éditeurs de logiciels, y compris ceux qui vendent une brique à intégrer ;
• les fabricants de matériel avec du firmware — caméras, automates, capteurs ;
• les sociétés de services qui déploient ces outils, et qui deviennent le point de contact technique ;
• et vous, si votre nom apparaît sur la boîte ou sur la facture.

Le critère n'est pas votre taille. C'est le rôle que vous tenez dans la chaîne.

RGPD et CRA : deux logiques, pas un empilement

Beaucoup d'entreprises traitent ces textes comme une pile de dossiers à remplir. C'est une erreur de lecture, et elle coûte cher. Le RGPD demande de déclarer ce que vous faites des données personnelles. Le CRA demande de savoir ce qui tourne dans vos systèmes et comment vous le maintenez à jour.

Critère	RGPD	CRA
Objet	Les données personnelles	La sécurité des produits numériques
Question centrale	Que faites-vous de ces données ?	Que contient votre produit, et comment le corrigez-vous ?
Preuve attendue	Registre, consentements, contrats de sous-traitance	Inventaire des composants, politique de correctifs
Qui porte le risque	Le responsable de traitement	Le fabricant, puis l'intégrateur
Rythme	Continu, mais événementiel	Continu, avec des délais courts sur les vulnérabilités critiques

Ce qui m'a frappé en accompagnant des clients sur les deux sujets : les entreprises qui géraient bien le RGPD ont quasiment toutes un problème avec le CRA. Pourquoi ? Parce que le RGPD se traite avec des process et des juristes. Le CRA se traite avec des outils, des dépendances et de la veille technique. Ce sont deux métiers différents.

Bon, et il y a le troisième larron, l'AI Act. Lui ajoute une couche : documenter l'origine des données d'entraînement, le niveau de risque de votre système, et le contrôle humain prévu. Si vous avez bricolé un modèle de tri de CV l'an dernier en trois semaines, vous allez devoir rouvrir le dossier.

Le coût réel de la conformité (et pourquoi il est mal estimé)

Quand on me demande « ça va coûter combien ? », je réponds toujours la même chose : le mauvais calcul, c'est de compter le coût de la mise en conformité. Le bon, c'est de compter le coût de l'improvisation.

Sur un projet d'intégration logicielle que j'ai suivi, l'équipe a passé six semaines à reconstituer l'inventaire des composants d'une application déjà en production. Six semaines. Une seule application. Personne n'avait jamais noté quelles bibliothèques avaient été ajoutées au fil des années, ni pourquoi.

Où part vraiment l'argent

Ce n'est presque jamais dans la rédaction de documents. C'est dans la reconstitution de ce qui existe déjà. Trois postes absorbent l'essentiel :

• L'inventaire — découvrir ce qui tourne, qui l'a installé, et si c'est encore maintenu ;
• le processus de correctifs — qui décide qu'on patche, en combien de temps, et comment on teste avant ;
• la traçabilité — pouvoir prouver, dans deux ans, pourquoi telle version a été choisie.

Le premier poste est le plus douloureux. Et c'est précisément celui que personne ne budgète, parce qu'il ne ressemble pas à un projet de conformité. Il ressemble à du rangement. Sauf qu'il en produit tous les bénéfices.

Franchement, j'ai longtemps cru que ces inventaires étaient un pensum administratif. Puis j'ai vu une équipe réduire de moitié son temps de résolution d'incident après avoir simplement documenté ses dépendances. Le bénéfice n'était pas juridique. Il était opérationnel.

Pourquoi les PME tombent dans le piège

Un grand groupe a un RSSI, une DSI structurée, parfois un juriste dédié. Une PME de 40 personnes a un informaticien — ou un prestataire qui passe une fois par mois. C'est là que le bât blesse. Les obligations ne sont pas proportionnelles à la taille, mais les moyens le sont.

Ce que je conseille dans ce cas : ne pas viser l'exhaustivité. Viser la preuve. Un registre incomplet mais vivant vaut mieux qu'un dossier parfait figé il y a deux ans. J'ai vu des entreprises refuser de commencer parce qu'elles ne pouvaient pas tout faire d'un coup. Résultat : deux ans plus tard, elles n'avaient rien fait du tout.

Le règlement sur la cyberrésilience, côté français

Le texte européen pose le cadre. En France, l'ANSSI joue un rôle de point d'appui technique : recommandations, référentiels, et accompagnement des acteurs concernés. Concrètement, cela veut dire qu'une partie de la mise en œuvre se joue au niveau national, avec des attendus qui peuvent différer d'un secteur à l'autre.

Ce que ça change dans la pratique

Pour une entreprise, l'enjeu n'est pas de connaître les textes par cœur. C'est de savoir à quel référentiel se raccrocher quand un client vous demande une attestation. Et cette question arrive plus vite qu'on ne le pense.

Deux exemples vécus. Une ETI du secteur santé a dû fournir, en trois semaines, la liste des composants de son portail patient pour répondre à un appel d'offres hospitalier. Une autre, dans l'industrie, a découvert qu'un automate acheté cinq ans plus tôt ne recevait plus de correctifs — et que le fournisseur avait changé de gamme. Dans le premier cas, l'équipe s'en est sortie avec un tableur tenu à jour. Dans le second, il a fallu remplacer le matériel.

Le tableau est clair : celui qui sait ce qu'il a chez lui garde la main. Celui qui découvre l'information au moment de la demande subit.

Et si on ne fait rien ?

Je ne vais pas vous vendre la peur avec des montants que je ne peux pas vérifier. Ce que je peux dire, c'est ce que j'observe : dans la majorité des cas, la sanction arrive bien avant l'amende. Elle prend la forme d'un contrat perdu, d'une clause refusée, ou d'un donneur d'ordre qui classe votre dossier sans vous prévenir.

C'est moins spectaculaire qu'une mise en demeure. C'est beaucoup plus fréquent.

Transformer la contrainte en argument commercial

Voilà ce que personne ne dit assez fort : une partie de vos concurrents ne sont pas prêts. Si vous l'êtes, vous avez un avantage, et il est temporaire.

Un éditeur avec qui j'ai travaillé a fait ce choix en 2025 : publier une page détaillant sa politique de correctifs, ses délais d'intervention sur les vulnérabilités critiques, et la durée de support de chaque version. Rien de spectaculaire. Mais cette page lui a ouvert deux appels d'offres qu'il ratait systématiquement auparavant, sur des critères de sécurité qu'il ne pouvait pas documenter.

La conformité cesse d'être un centre de coût dès qu'elle devient une réponse à une question que le client se pose. Et les clients se posent de plus en plus cette question.

Par où commencer, sans tout casser

Une séquence qui fonctionne, testée sur plusieurs structures de tailles différentes :

1. Lister les dix applications les plus critiques — pas les plus chères, les plus critiques.
2. Pour chacune, noter qui l'édite, quelle version tourne, et depuis quand.
3. Identifier une personne responsable. Une seule. Pas un comité.
4. Écrire une phrase sur ce qu'on fait quand une faille critique sortira demain.
5. Reprendre le tout tous les six mois, même mal.

La cinquième étape est celle que tout le monde saute. C'est aussi celle qui fait la différence au bout de deux ans.

Est-ce que ça s'applique si je ne vends rien en Europe ?

Si votre produit est mis sur le marché européen, oui. La question n'est pas où vous êtes installé, mais où le produit est distribué. Un éditeur hors UE qui vend à des clients européens entre dans le champ.

Faut-il un juriste dédié ?

Pas nécessairement. Ce qui compte, c'est une personne qui comprend à la fois la technique et les engagements pris. Dans beaucoup de PME, c'est le responsable technique. Le juriste intervient sur la rédaction des clauses, pas sur l'inventaire.

Combien de temps avant d'être prêt ?

Pour une PME qui part de zéro, comptez plusieurs mois rien que pour l'inventaire, puis une organisation continue ensuite. Ce n'est pas un projet avec une fin. C'est un mode de fonctionnement.

La vraie question n'est pas de savoir combien de textes européens vous concernent. Elle est de savoir si, demain matin, vous pouvez répondre à la question « qu'est-ce qui tourne dans votre système, et comment le corrigez-vous ? » en moins d'une heure. Si la réponse est oui, les régulations numériques ne sont plus un sujet. Elles deviennent une ligne sur votre plaquette commerciale. Si la réponse est non, le calendrier ne vous attendra pas — et il ne préviendra personne.