Il y a une phrase que j’entends de plus en plus souvent, lâchée presque en passant pendant qu’on raccroche un appel et qu’on revient aux choses « sérieuses » : nous, on veut le go-live. La compliance, c’est votre affaire.
Ce n’est pas toujours de l’arrogance. Le plus souvent, c’est l’inverse. C’est une phrase dite avec le naturel de quelqu’un qui pense que la compliance est un détail technique, comme choisir un framework ou décider si le bouton va à droite ou à gauche.
Sauf que ce « détail » est en train de changer de forme. Et il devient, beaucoup plus vite que le marché ne semble prêt à l’admettre, une question de responsabilité.
Ce que le client achète et ce que le prestataire vend
Pendant des années, dans le développement sur mesure, on s’est compris avec un pacte implicite assez simple. Le client décrit ce qu’il veut, le prestataire le construit, on s’accorde sur les délais et les coûts, à la livraison on fait la recette, on passe en production, on clôt.
Dans ce modèle, la responsabilité « lourde » finissait presque toujours dans le périmètre du projet. Si quelque chose tournait mal, on parlait de bugs, d’incidents, parfois d’une pénalité. Embêtant, certes, mais gérable.
Le point, c’est qu’en Europe, entre 2025 et 2027, arrive un changement de perspective qui rend ce pacte moins stable. Ce n’est pas un règlement isolé que tu peux ignorer jusqu’au mail du juriste. C’est un ensemble de règles qui, prises dans leur ensemble, poussent dans une direction précise : le logiciel est traité de plus en plus comme un produit.
Et quand quelque chose est un produit, celui qui le « produit » ne répond plus seulement en termes contractuels. Il répond aussi des défauts, un peu comme avec un appareil ménager qui cause des dommages parce qu’il a été mal conçu ou mal assemblé.
Le désalignement commercial qui crée la friction
C’est là que naît la friction réelle, celle qui explose ensuite dans les négociations et les devis.
Le donneur d’ordre raisonne de façon linéaire et, de son point de vue, correcte. Il veut une plateforme qui marche, un portail, une app. Il la veut pour une date donnée, avec un certain budget, avec les fonctionnalités utiles au business.
Le prestataire, lui, se retrouve avec une charge croissante d’exigences qui n’apparaissent presque jamais dans le brief. Tu ne les trouves pas dans les user stories, tu ne les vois pas dans les maquettes, le product owner ne te les demande pas. Et pourtant, sans elles, un projet « livré » devient un projet « risqué ».
Je parle de documentation technique faite d’une certaine manière, traçabilité des composants, gestion des vulnérabilités, transparence sur certains choix algorithmiques, accessibilité. Toutes des activités qui ont une caractéristique commune : elles coûtent du temps, des compétences, du processus.
Et là arrive le dilemme qui, à mon avis, devient de plus en plus toxique.
Si tu les mets dans le devis, tu risques d’être plus cher que le concurrent qui ne les met pas.
Si tu ne les mets pas, tu les absorbes dans la marge, tu travailles à perte et, en plus, tu prends un risque que tu n’as pas explicité.
Aucune des deux voies n’est tenable longtemps.
Pourquoi « on a toujours fait comme ça » ne tient plus
Dans le b2b italien, on a vécu pendant des années dans une culture du « on fait, on verra après ». Contrats légers, cahiers des charges flous, beaucoup de confiance interpersonnelle. Parfois ça a même bien fonctionné, je ne le nie pas. Peut-être parce que le contexte le permettait.
Mais trois choses changent en même temps, et c’est leur combinaison qui inquiète.
La première, c’est une responsabilité plus « objective ». Dans certains scénarios, il ne suffit plus de dire « nous n’avons pas été négligents ». C’est le défaut qui compte, et le dommage qui compte. Et dans certains cas, la charge de prouver qu’il n’y avait pas de défaut se déplace sur celui qui a produit ou mis sur le marché.
La deuxième, c’est l’élargissement du périmètre. Le logiciel n’est pas seulement ce que tu écris. C’est aussi ce que tu intègres : bibliothèques open source, services cloud, API tierces, modèles IA. Et quand tout ça entre dans le produit final, quelqu’un doit répondre de la façon dont c’a été choisi, intégré, surveillé.
La troisième, c’est le temps. Ce n’est pas un futur lointain. Ce sont des échéances entre 2026 et 2027. Le code que tu écris aujourd’hui sera, selon toute probabilité, encore là quand ces règles seront pleinement opérationnelles.
Alors je me demande si ce n’est pas naïf de continuer à traiter la compliance comme une note de bas de page.
La conversation que personne ne veut avoir
Le plus difficile n’est pas de comprendre la norme. C’est d’en parler sans faire sauter la table commerciale.
Essaie de dire à un client que le devis augmente de 20 % parce qu’il faut produire de la documentation technique conforme, mettre en place un processus de gestion des vulnérabilités et tenir un inventaire à jour des composants.
Dans le meilleur des cas, il te répond par un long silence.
Dans le pire, il te dit que quelqu’un d’autre lui fait ça sans.
Et c’est là que le marché se fracture. Parce que ce « sans » signifie rarement « plus efficient ». Cela signifie souvent « dette de compliance » : du travail et du risque déplacés dans le futur. Un futur où, avec les nouvelles règles, la facture peut arriver au prestataire, au donneur d’ordre, ou aux deux.
Et pourtant cette conversation, presque personne ne la mène, du moins pas explicitement. Elle est inconfortable. Elle oblige le client à accepter que la compliance a un coût réel. Et elle oblige le prestataire à expliquer ce coût sans se cacher derrière des mots qui ressemblent à de la bureaucratie.
Le coût de l’invisibilité
Il y a un paradoxe qui complique tout. Les activités de compliance, quand elles sont bien faites, sont invisibles.
Un système sérieux de gestion des vulnérabilités se remarque quand rien ne se passe.
La documentation technique devient précieuse quand quelque chose tourne mal.
Un inventaire des composants (genre liste à jour des dépendances) vaut vraiment le jour où sort une vulnérabilité critique et où tu dois savoir tout de suite si tu es exposé.
Le client voit la fonctionnalité, voit le go-live, voit l’interface. Tout ce qui tient ce résultat dans le temps reste sous le plancher.
Alors peut-être que le problème n’est pas que le client « ne veut pas payer ». C’est qu’il ne perçoit pas ce qu’il achète.
Si tu vas voir un dirigeant et que tu lui dis « il faut implémenter un Software Bill of Materials conforme », tu perds son attention en quelques mots.
Si en revanche tu lui dis « il faut être capable, sous 24 heures, de savoir si une vulnérabilité fraîchement publiée met ton produit, et donc ta responsabilité, en risque », tu parles la langue du risque. Une langue beaucoup plus universelle.
Ce qui change, en pratique, sans tout transformer en cauchemar
Pour les prestataires, la voie est étroite mais assez claire. Il faut cesser de traiter la compliance comme un coût caché et commencer à la traiter comme un service explicite, avec une valeur racontable.
Cela veut dire, par exemple, séparer le développement fonctionnel de la maintenance de sécurité et de conformité. Pas dans un « forfait annuel » indistinct, mais avec une ligne qui dit ce qu’elle couvre vraiment. D’autant plus que si demain quelque chose se discute, l’ambiguïté n’aide personne.
Cela veut dire mettre noir sur blanc, dans les contrats, qui fait quoi. Qui met à jour les dépendances ? Qui surveille les vulnérabilités ? Qui produit et conserve la documentation technique ? Qui décide si une bibliothèque est utilisable ? Qui répond si un composant se révèle compromis ?
Aujourd’hui, dans beaucoup de contrats italiens, ces questions n’existent tout simplement pas. Et quand une question n’existe pas, la réponse arrive toujours au pire moment.
Cela veut dire aussi apprendre à vendre ces activités pour ce qu’elles sont : de la réduction du risque. Parce que le client n’achète pas de la « compliance ». Il achète la possibilité de ne pas se retrouver avec un produit hors-la-loi, avec un incident de sécurité mal géré, ou avec un litige où il n’a ni preuves ni documents pour se défendre.
Pour les donneurs d’ordre, le changement de mentalité est symétrique. La compliance, c’est votre affaire n’est plus une position confortable, et ne l’a peut-être jamais été. Si tu mets sur le marché un produit numérique, même si tu l’as fait développer par un tiers, la responsabilité ne s’évapore pas.
Au mieux, tu peux te retourner contractuellement contre le prestataire. Mais entre-temps, le dommage, la réputation, la gestion de l’incident et les conséquences commerciales, c’est toi qui les affronte.
Une question de maturité du marché
À bien y réfléchir, ce qui est en train d’arriver ressemble à une croissance forcée. Le marché du logiciel, surtout celui sur mesure, passe d’un modèle artisanal — fondé sur la confiance et les accords implicites — à un modèle plus industriel, où les responsabilités sont définies, les processus documentés et où la qualité ne se résume pas à « ça marche sur mon téléphone ».
Ce n’est pas forcément une mauvaise nouvelle.
Pour les prestataires sérieux, ça peut devenir un moyen de se distinguer de ceux qui ne se battent qu’en taillant des coins.
Pour les donneurs d’ordre les plus avisés, ça peut être une garantie : savoir que le logiciel n’est pas construit seulement pour passer en ligne, mais pour tenir dans le temps, encaisser les incidents, et ne pas se transformer en problème juridique au premier choc.
Peut-être la phrase juste, aujourd’hui, n’est-elle pas « la compliance, c’est votre affaire ». C’est quelque chose de plus honnête et plus utile : la compliance fait partie du produit.
Alors oui, c’est un coût structurel du fait de produire du logiciel. Plus tôt tu le reconnais, plus tôt tu peux le gérer. Et peut-être, avec un peu de courage, le transformer aussi en avantage concurrentiel.
Ce qu'il faut retenir
La responsabilité d’un produit numérique mis sur le marché ne disparaît pas en la déléguant au prestataire : elle reste au donneur d’ordre.
Le client n’achète pas de la compliance, il achète de la réduction du risque — traduire cela est le travail commercial de 2026.
Le marché italien sort d’un modèle artisanal fait de contrats légers et de confiance implicite ; la facture du report arrive.
La compliance bien faite est invisible tant qu’elle fonctionne : c’est pour ça qu’on ne la voit pas, et c’est pour ça qu’il faut la vendre.
Questions & réponses
Que signifie que le logiciel devient un produit avec responsabilité légale ?
Cela signifie que la nouvelle directive européenne sur la responsabilité du fait des produits (PLD, en vigueur depuis le 9 décembre 2026) et le Cyber Resilience Act traitent le logiciel comme un bien industriel. Celui qui le met sur le marché répond des défauts — non plus seulement en termes contractuels, mais en termes objectifs, comme avec un appareil ménager ou un médicament. La charge de prouver que le produit était conforme se déplace sur le producteur.
Si un client dit « la compliance, c'est votre affaire », le prestataire IT peut-il l'ignorer ?
Non, et le client ne devrait pas non plus le dire. La responsabilité pour un produit numérique mis sur le marché ne disparaît pas si tu l’as fait développer par un tiers : tu peux au mieux te retourner contractuellement contre le prestataire, mais entre-temps, c’est toi qui gères le dommage, l’incident et la réputation. Pour le prestataire, l’ignorer revient à absorber travail et risque dans la marge sans les expliciter — intenable à terme.
Comment écrire un devis qui inclut la compliance sans perdre face à ceux qui ne l'incluent pas ?
En séparant le développement fonctionnel de la maintenance de sécurité et de conformité comme lignes de contrat distinctes, et en traduisant la compliance du langage bureaucratique vers celui du risque. Pas « nous implémentons un SBOM conforme » mais « nous savons sous 24 heures si une vulnérabilité fraîchement publiée met ton produit en risque ». Le client achète une réduction du risque, pas de la compliance abstraite.
Pourquoi le modèle contractuel italien traditionnel ne tient-il plus ?
Parce qu’il s’appuyait sur trois hypothèses qui s’effondrent ensemble : responsabilité limitée au contractuel, périmètre restreint au code écrit en interne, et temps pour réparer après. Les nouvelles règles européennes 2026–2027 déplacent la responsabilité vers l’objectif, élargissent le périmètre à toutes les dépendances (open source, cloud, API, modèles IA), et ont des échéances déjà opérationnelles. Des contrats légers et des cahiers des charges flous qui passaient il y a dix ans sont aujourd’hui une dette que quelqu’un paiera.
L'auteur
