Je viens de la philosophie. Des années où je lisais Garin et Cassirer le matin et Foucault et Bobbio l’après-midi, où anticléricalisme et humanisme coïncidaient si naturellement qu’il n’était même pas besoin de l’argumenter. Depuis, j’ai gardé deux convictions que je continue de considérer comme le présupposé de tout discours public sérieux. La première est que les religions historiques sont, dans la grande majorité des cas, des dispositifs anti-humanistes, parce que la défense de l’humain exige une liberté que les structures cléricales n’ont jamais pu concéder qu’à contrecœur, sous pression, et presque toujours en retard. La seconde est que l’humanisme, le vrai, celui qui part de Garin et arrive au droit continental du XXe siècle en passant par la Constitution italienne et la déclaration de 1948, est un terrain structurellement laïque, où les traditions religieuses entrent comme invitées, et quand elles veulent prendre toute la place, soit elles se brouillent, soit elles se trahissent elles-mêmes. Ce sont des jugements que j’ai continué à pratiquer sans grand trouble en lisant les annexes techniques de l’AI Act, les derniers projets d’application du Cyber Resilience Act, les indications de l’EDPB sur les modèles d’AIPD pour les systèmes à haut risque. Je travaille dans la compliance européenne, je parle chaque jour avec des clients de l’administration publique et de la santé, et la seule métaphysique dont j’ai besoin d’habitude est celle, déjà assez compliquée, du considérant 71 du RGPD. Puis Magnifica Humanitas est parue, et quelque chose a bougé.

Pas une exhortation, un traité sur l’humain

Il m’a fallu deux soirées pour la lire. Elle n’est pas brève, et elle ne fait pas semblant de l’être. C’est un texte long, deux cent quarante-cinq paragraphes répartis en cinq chapitres, avec un appareil de deux cent vingt-quatre notes, écrit dans cette prose curiale qui par moments ralentit et par moments accélère de manière presque surprenante. Je m’attendais à l’énième exhortation moralisatrice sur l’intelligence artificielle, ce genre de document qui cherche à faire jeu égal avec un colloque de secteur et finit par arriver deux ans en retard et avec une demi-thèse en moins. Je me suis retrouvé devant quelque chose de différent. Pas une exhortation, mais un traité. Pas sur l’IA, mais sur l’humain, avec l’IA utilisée comme pierre de touche pour redire qui nous sommes. C’est exactement ce que le débat technique séculier peine à produire, parce qu’il présuppose un niveau de fondation conceptuelle que nous avons l’habitude de déléguer aux lois, en espérant que les lois s’en sortent toutes seules.

La subsidiarité n’est pas née à Bruxelles

Le problème, c’est que les lois ne s’en sortent pas toutes seules. Je le vois très bien quand j’essaie d’expliquer à un client pourquoi la subsidiarité numérique, celle qui inspire une grande partie de l’architecture du Data Act et des chapitres opérationnels de l’AI Act, n’est pas une invention de Bruxelles mais un principe avec presque un siècle d’élaboration derrière lui. Pie XI la formulait en 1931 dans Quadragesimo Anno, et depuis elle a traversé la jurisprudence, l’ordolibéralisme allemand, les travaux d’Adenauer, jusqu’à se déposer dans l’article 5 du Traité sur l’Union européenne. Quand un régulateur européen écrit que certaines décisions doivent être prises au niveau le plus proche possible des personnes concernées, il utilise une grammaire née ailleurs, pas à Bruxelles. Et quand j’essaie de défendre ce choix devant un client, je m’aperçois qu’il me manque les bons mots pour l’expliquer. Magnifica Humanitas, sur ce point, m’a rendu un lexique.

La destination universelle des biens, appliquée aux algorithmes

Ce qui m’a frappé, ce n’est pas la nouveauté des idées. Les idées de l’encyclique sont en grande partie connues. Ce qui m’a frappé, c’est la manière dont elle les tient ensemble, parce que ce sont exactement les idées dont j’ai besoin chaque fois que je dois discuter de compliance sans la réduire à un exercice bureaucratique. La destination universelle des biens, par exemple, appliquée au paragraphe 67 aux brevets, aux algorithmes, aux plateformes, aux infrastructures et aux données. Ce n’est pas une position que l’on puisse classer comme prépolitique ou utopique. C’est exactement le même problème que le Data Governance Act tente de cadrer avec le concept d’altruisme des données, que le DMA poursuit avec les règles sur les gatekeepers, que l’interprétation future des bases de données de santé européennes devra affronter quand l’European Health Data Space entrera en régime. Le fait qu’une donnée soit techniquement collectable et juridiquement attribuable ne signifie pas que sa destination finale soit légitimement privée. C’est une affirmation opérationnelle, pas un sermon.

Au-dessus du citoyen il n’y a plus seulement l’État

Il en va de même pour la subsidiarité au paragraphe 71. L’encyclique fait quelque chose que peu de documents techniques ont le courage de faire explicitement : elle rappelle que, dans le contexte numérique, le niveau supérieur au citoyen n’est plus l’État, mais le grand acteur économique qui exerce un pouvoir de fait sur les conditions de la vie commune. Ce n’est pas une métaphore. Quand une plateforme décide ce qui est visible et ce qui est masqué, quand un système de scoring algorithmique établit qui accède au crédit et qui non, quand un modèle de langage devient l’interface dominante pour certains types de service, s’exerce un pouvoir que la théorie classique de la subsidiarité n’avait pas prévu en ces termes. Le reconnaître formellement, dans un document officiel de cette autorité, déplace le plan de la discussion. Cela cesse d’être une opinion de niche. Cela devient une position fondée que l’on peut citer dans un mémoire en défense, dans une analyse d’impact, dans un avis à un client qui demande pourquoi on se donne tout ce mal pour implémenter un système de journalisation transparent.

Du jugement au calcul, un demi-siècle après Weizenbaum

Il y a ensuite un passage que je n’attendais pas, et qui est probablement le morceau le plus fort du document entier. Il se trouve au paragraphe 198, dans le chapitre sur la culture de la puissance, là où l’encyclique aborde la guerre, mais il vaut pour tout. Le jugement moral n’est pas réductible à un calcul, car il implique conscience, responsabilité personnelle et reconnaissance de l’autre comme personne. C’est pourquoi il n’est pas permis de confier à des systèmes artificiels des décisions létales ou de toute façon irréversibles. Deux phrases qui contiennent au moins un demi-siècle de pensée critique sur le calcul automatique. Joseph Weizenbaum, l’ingénieur du MIT qui avait construit ELIZA en 1966 et qui, quelques années plus tard, s’était effrayé en voyant comment sa secrétaire s’y confiait, écrivait en 1976 un livre dont le sous-titre était From Judgment to Calculation. Du jugement au calcul. Tout le livre était une défense de cette préposition, au, qui marque une perte. Weizenbaum soutenait qu’il y a des tâches que les ordinateurs ne peuvent pas et ne doivent pas accomplir, même si techniquement ils le pourraient, parce qu’elles impliquent la reconnaissance de l’autre comme personne, et que cette reconnaissance n’est pas un problème de représentation interne. C’est un acte. Magnifica Humanitas, un demi-siècle plus tard, dit exactement la même chose avec un vocabulaire différent. Ce n’est pas une coïncidence. C’est que certaines vérités anthropologiques ressurgissent quand les conditions matérielles les y contraignent, et aujourd’hui les conditions matérielles sont celles de la prise de décision automatisée appliquée à des vies humaines réelles.

Les nouveaux esclavages et le colonialisme des données

L’encyclique va plus loin. Au paragraphe 173, elle nomme des choses que le débat dominant sur l’IA préfère laisser dans les marges des conférences de fournisseurs. Elle cite explicitement l’étiquetage des données, la modération des contenus, l’extraction des terres rares, le travail des enfants dans les mines. Elle les appelle nouveaux esclavages, et pas par rhétorique. Elle les appelle ainsi parce qu’elles alimentent effectivement, de façon invisible pour qui utilise une API à soixante centimes le million de tokens, toute l’économie des architectures transformer. Au paragraphe 178, elle introduit un concept que les chercheurs en technopolitique utilisent depuis au moins cinq ans mais qui fait une certaine impression vu dans un document pontifical : le colonialisme des données. La phrase clé, c’est que qui possède les données de santé de populations entières, aujourd’hui souvent collectées sous le signe de l’aide, de la recherche ou de l’innovation, possède en réalité un levier structurel sur l’avenir. C’est une description exacte du risque stratégique qui pèse sur de nombreux contextes africains, asiatiques, latino-américains, et qui devrait peser sur nos choix de commande quand nous décidons où héberger une donnée, à quel fournisseur acheter l’entraînement d’un modèle, à quel écosystème déléguer l’analyse épidémiologique d’une région. Ce n’est pas une sensibilité new age. C’est une analyse d’impact.

Un traité qui tient comme source pour une AIPD

À ce stade de la lecture, je me suis arrêté. J’annotais des passages en marge comme si je préparais un mémoire technique, et je me suis rendu compte que c’était exactement ce que je faisais. L’encyclique fonctionne très bien comme traité anthropologique, mais elle fonctionne aussi comme source secondaire pour un argument de compliance. C’est un texte que l’on peut citer dans une AIPD pour justifier une évaluation restrictive. C’est un texte que l’on peut annexer à un avis sur une intégration d’IA dans le domaine de la santé. Pas parce qu’il a une valeur juridique, évidemment, mais parce qu’il fournit ce cadre de principe qui manque souvent quand on discute de choix techniques, et qui, lorsqu’il manque, se traduit par des décisions prises sur la seule base du coût d’opportunité. Qui travaille dans la compliance européenne sait ce que je veux dire. Il y a une zone grise, entre le considérant et l’article, entre l’intention du législateur et la lettre de la norme, où le technicien a besoin de s’appuyer sur quelque chose de solide pour expliquer pourquoi une interprétation est préférable à une autre. Avoir un texte de cette portée, écrit depuis une position extérieure au système technique mais capable d’en parler de l’intérieur, est un atout qu’il est stupide de ne pas utiliser par préjugé.

Ce n’est pas une conversion, et ce n’est pas un texte parfait

Je me rends compte que ceux qui me connaissent pourraient trouver étrange de lire ces lignes. Je n’annonce pas une conversion, et je ne dis pas non plus que le document est parfait. Il y a des points où l’encyclique dérape, surtout quand elle entre sur le terrain bioéthique et de la famille, où ma distance personnelle reste intacte. Il y a des passages où le ton pastoral prend le dessus sur la précision conceptuelle, et où j’aurais voulu moins de charité rhétorique et plus d’outils d’analyse. Ce n’est pas un texte que l’on signe, c’est un texte que l’on discute. Mais c’est le type de discussion qui, à moi, athée travaillant sur la régulation européenne de la technique, sert aujourd’hui plus qu’hier. Et je crois qu’elle sert, de la même manière, à qui essaie de construire une industrie technologique européenne différente de celle qui nous arrive de San Francisco ou de Hangzhou, parce que différente signifie fondée sur quelque chose, et quelque chose, à ce stade historique, ne s’improvise pas.

Désarmer

Au paragraphe 110, il y a un mot qui m’a fait sourire. Désarmer. L’encyclique dit vouloir désarmer l’IA, et précise aussitôt que désarmer ne signifie pas renoncer. Cela signifie la soustraire aux monopoles et à la logique de la compétition, la rendre discutable et contestable, la restituer à la pluralité des cultures humaines. C’est un mot politique, pas religieux. C’est exactement le mot que Bruxelles n’arrive pas encore à prononcer, parce que Bruxelles est encore otage du réalisme qui présume la course aux armements comme une donnée naturelle. Une course qui a cessé d’être militaire pour devenir cognitive, comme l’encyclique le note avec une lucidité remarquable, mais qui garde la même logique de fond. Le fait que le premier à le prononcer, dans un document officiel de cette diffusion, ait été le Vatican et non un commissaire européen, dit quelque chose sur l’état de notre débat public. Ce n’est pas une bonne nouvelle, mais c’est une nouvelle dont partir.

Trois choses que j’emprunte

Je termine par une note qui n’a rien à voir avec la théologie. Quand on lit un texte produit dans une tradition qui ne nous appartient pas, il y a deux voies. L’une est celle de la méfiance préventive, qui consiste à demander au texte de trahir sa propre origine avant d’accepter même de l’entendre. L’autre est celle de l’emprunt, qui consiste à prendre ce qui sert, laisser ce qui ne sert pas, et retourner à son travail avec un outil de plus. En tant qu’athée, je sens que je peux emprunter à Magnifica Humanitas au moins trois choses. La reconnaissance explicite que le jugement moral n’est pas automatisable, et que qui tente de l’automatiser fait une opération politique, non technique. La nomination des filières invisibles qui alimentent l’économie numérique, qui est le présupposé de toute demande sérieuse de due diligence. Et ce mot, désarmer, que je voudrais voir appliqué, dans les prochaines années, aux textes normatifs qu’il m’arrivera de lire pour le travail.

Le reste, qui y tient le discutera dans les lieux appropriés. À moi, aujourd’hui, il suffit d’avoir un traité de plus sur la table de nuit, et quelques pages bien écrites à relire quand un client me demandera pourquoi, au fond, après tout, je me donne la peine de faire les choses bien.

La première réaction à la publication de la UNI 11621-8, la norme italienne qui définit les douze profils professionnels de l’intelligence artificielle, devrait être la méfiance. Standardiser les métiers d’un champ qui change tous les six mois est un exercice presque paradoxal, et le faire avant le reste de l’Europe revient à assumer le risque de se tromper en premier. La norme est parue le 30 avril 2026, signée par UNINFO avec la coordination du Dipartimento per la Trasformazione Digitale, le département italien pour la transformation numérique. L’ancrage normatif renvoie au Règlement UE 2024/1689, c’est-à-dire l’AI Act, et à la loi italienne 132/2025 sur l’IA. La loi italienne 4/2013 sur les professions non réglementées sert de rampe à la certification.

Un mot en quête de mesure depuis février

Pour qui fait de la compliance au quotidien, c’est la fermeture d’un cercle resté ouvert depuis le 2 février 2025. Ce jour-là, l’article 4 de l’AI Act a imposé aux fournisseurs et aux déployeurs de garantir un niveau d’alphabétisation suffisant du personnel, sans expliquer ce que voulait dire, exactement, l’adjectif « suffisant ». Ces derniers mois, en travaillant sur des projets de compliance pour des clients dans des secteurs très réglementés, ce mot revenait dans chaque conversation comme une question sans réponse. Aucun kit documentaire, aucun modèle d’AIPD ne parvenait à en fixer le sens sans recourir à des périphrases. Que veulent dire, exactement, « des compétences suffisantes » ? Quand la demande d’un client est-elle raisonnable, et quand devient-elle une exigence sans mesure ? La UNI 11621-8 offre cette mesure, et l’offre en italien, avec des noms que l’acheteur d’une société de santé ou d’un département régional peut lire sans les traduire.

Douze profils, du CAIO au chercheur

Les douze profils couvrent le spectre de la gouvernance à la recherche. On va du Chief AI Officer à l’AI Research Scientist. Pour chaque profil, la norme précise mission et tâches, ainsi qu’une carte des compétences requises avec le niveau attendu et les indicateurs de performance associés. La méthodologie est celle, consolidée, de la UNI 11621-1, et l’ancrage est à l’e-Competence Framework européen, la UNI EN 16234-1. Techniquement, le travail est solide, et il est important de le dire avant de passer aux problèmes.

Une matière qui se codifie alors qu’elle bouge encore

Les problèmes commencent par la matière que la norme essaie de figer. Une profession se codifie quand elle a atteint un degré suffisant de stabilité, et l’IA d’aujourd’hui ne l’a pas. Le Prompt Engineer, présent dans la liste comme profil séparé, est déjà un cas intéressant. Quand il a existé comme rôle distinct, il a eu une vie brève, et a été rapidement absorbé par les développeurs et les product managers qui travaillent directement avec les modèles génératifs. Le garder comme profil dédié revient à courir après une pratique déjà passée ailleurs. Il en va de même, à un autre degré, pour la séparation nette entre Data Scientist et Machine Learning Engineer, deux rôles qui dans la pratique réelle se chevauchent largement. Les contours des figures professionnelles codifiées sont bien plus nets que les contours des compétences que les gens exercent vraiment. Un bon Data Scientist touche au ML engineering, et un ML engineer compétent sait se déplacer dans la pipeline de données. Quand un AI Security Specialist ne comprend pas les modèles à la racine, il cesse d’être un professionnel de la sécurité et devient un relecteur de documents.

Qui écrit la norme, et pourquoi

Il y a ensuite une question plus subtile, et qui touche à l’origine des normes de profil professionnel en Italie. Elles sont produites par des commissions où siègent des organismes de certification et des prestataires de formation, en plus des associations professionnelles. Acteurs légitimes, tous, et tous avec un intérêt économique au résultat final. Cela ne rend pas la norme moins utile, cela change la manière dont elle devrait être lue. Sous la surface technique, il y a la construction d’un marché. Le marché de la certification professionnelle et de la formation accréditée. Les cursus ITS Academy, l’enseignement supérieur technique italien, s’alignent en ce moment, et les organismes de certification préparent leurs propres schémas. La loi italienne 4/2013 fournit l’accroche, celui qui peut certifier un profil professionnel gagne de cette certification. La question n’est pas de savoir si le système est légitime, il l’est. La question est ce que nous achetons réellement lorsque nous payons pour certifier un Chief AI Officer interne.

L’effet de substitution, comme avec le DPO

Une troisième précaution concerne l’effet de substitution, qui est probablement le risque le plus sérieux. Avoir des profils conformes UNI ne signifie pas avoir une gouvernance IA compétente. L’histoire récente du RGPD est pleine d’organisations qui avaient un DPO certifié et des processus désastreux, parce que le DPO était une case administrative, pas une fonction opérationnelle. La même chose peut arriver au Chief AI Officer et au Security Specialist. La compliance par checklist produit du confort organisationnel et peu de sécurité réelle. Si la UNI 11621-8 est lue comme une obligation documentaire, nous aurons des entreprises avec des tableaux propres et des systèmes IA fragiles. Si elle est lue comme une ossature autour de laquelle bâtir une pratique réelle, nous aurons quelque chose d’utile.

Une trajectoire déjà vue

Cela étant dit, la publication de la norme mérite d’être prise au sérieux. Pour une raison qui a peu à voir avec la technique, et beaucoup avec le timing du marché régulé. Le schéma, en Italie, nous l’avons déjà vu. La Stratégie Cloud Italia de 2021 a généré un cadre de classification des données et des services pour l’administration publique. Ce cadre est ensuite devenu règlement de l’Agenzia per la Cybersicurezza Nazionale entre 2022 et 2023. Le catalogue des services cloud qualifiés est enfin entré dans les procédures d’achat de la PA, jusqu’à Consip MEPA, la plateforme italienne de centrale d’achat. Les clauses sur la sécurité des services cloud, vagues au départ, sont devenues des exigences techniques vérifiables et des conditions de participation. Les arrivants tardifs ont concouru comme fournisseurs génériques contre des fournisseurs déjà qualifiés, et ont perdu des marchés significatifs. La UNI 11621-8, appliquée dans le cadre de l’AI Act, suit une trajectoire analogue. La norme part comme référence volontaire et finit dans les cahiers des charges. Le passage par les actes d’orientation du Dipartimento est presque un détail administratif. La fenêtre utile s’ouvre maintenant, et se referme quand le premier appel d’offres significatif citera la norme.

Dans un kit de compliance multi-framework

Pour qui, comme nous chez Oltrematica, fait de la compliance multi-framework, la norme est d’abord un outil de documentation défendable. La matrice RACI d’un projet IA à haut risque, construite sur les profils UNI, devient une preuve qui tient en audit. Le plan de formation interne d’entreprise, mappé sur les profils, cesse d’être un coût administratif et devient partie intégrante du programme de gestion du risque IA. La forme que nous donnons à nos kits documentaires internes absorbe la norme sans effort, parce qu’elle parle la même langue que les frameworks que nous utilisons déjà, du RGPD au Cyber Resilience Act.

Une carte imparfaite, mais une carte

Il y a une ligne de travail plus intéressante que la pure conformité, et probablement moins rentable à court terme. La norme est une occasion d’intelligibilité interne. Elle permet aux organisations qui adoptent l’IA d’en parler avec un vocabulaire partagé, avant même de parler aux régulateurs ou aux organismes de certification. C’est un vocabulaire imparfait, en partie daté et construit autour d’intérêts économiques reconnaissables. Mais c’est le premier vocabulaire disponible, et son imperfection est inférieure à son utilité. La vraie question, celle qui décidera si la UNI 11621-8 sera une bonne norme ou une mauvaise norme, n’est pas écrite dans le texte. Elle s’écrira dans les prochains mois, dans les interprétations que les organisations en donneront, et dans les cahiers des charges qui s’en serviront pour filtrer les fournisseurs.

En attendant, il vaut la peine de la lire pour ce qu’elle est. Une carte imparfaite du territoire que nous traversons déjà, qui propose au moins une toponymie partagée pour que nous ne nous perdions pas tous de la même manière.

Vingt heures du soir, à peu près. Le dîner vient de finir, les assiettes dans l’évier, la table encore à débarrasser. Mon fils a trois ans et il essaie de me convaincre de lui laisser la tablette encore un petit peu, ce qui dans sa grammaire du temps signifie une période comprise entre vingt minutes et l’infini. Je dis non. Sans colère, sans discours pédagogique. Je dis non avec la fatigue précise de quelqu’un qui répète la même scène chaque soir, en sachant que la prochaine sera identique.

Jusqu’ici, c’est une scène que n’importe quel parent reconnaît. Elle pourrait se passer dans n’importe quelle maison.

Je sais comment fonctionne cette tablette

La différence, c’est la raison pour laquelle je dis non. Ce n’est pas parce que j’ai lu un article alarmant sur les écrans, ni parce que je suis un pédiatre sur Instagram qui conseille la digital detox, ni parce que de mon temps on jouait dehors. La raison, c’est que je sais comment fonctionne cette tablette. Pas au sens générique, pas « la technologie fait du mal aux enfants ». Je le sais au sens technique. Je sais comment est fait le logiciel qui tourne dessus. Je sais quelles décisions de design ont prises les personnes qui l’ont construit, et je sais pourquoi elles les ont prises. Je sais ce qui se passe quand mon fils touche l’écran, quelle logique décide de ce qu’on lui montrera ensuite, et quel objectif cette logique cherche à atteindre. Cet objectif n’est pas son bien-être.

Cela, je le sais parce que c’est mon métier. Je construis du logiciel depuis presque vingt ans. Je ne travaille pas pour les grandes plateformes sociales, je n’ai jamais eu de bureau à Menlo Park ou à Mountain View. Je fais des choses beaucoup plus ennuyeuses : des ERP, des plateformes de formation, des applications qui aident les entreprises à organiser des données. Des trucs qui ne finiraient jamais dans une enquête journalistique parce que ce n’est pas assez intéressant.

On pourrait objecter qu’alors le problème ne me concerne pas, que les techniques de capture de l’attention sont l’affaire de TikTok, de Meta, de ByteDance, et qu’entre une plateforme sociale et un ERP, il y a la différence qu’il y a entre une piste de Formule 1 et une route de campagne. L’objection serait sensée si elle n’était pas fausse. Les techniques pour garder les gens collés à un écran ne sont pas un secret industriel. Ce sont une discipline partagée, documentée, enseignée dans les conférences que je fréquente, discutée dans les canaux Slack où je passe mes journées de travail. C’est un patrimoine commun à quiconque construit des produits numériques. Les leviers que TikTok actionne pour garder un adolescent collé à l’écran sont cousins proches des leviers que j’utiliserais pour aider un client à augmenter le temps moyen de session sur une plateforme de formation d’entreprise. Le contexte change, l’intensité change, le type d’utilisateur change. Les outils de base portent les mêmes noms, s’enseignent dans les mêmes conférences, se retrouvent dans les mêmes livres de design.

Le soir, à la maison, je lis le plan de la tablette de mon fils comme on lit le plan d’un bâtiment : ceci sert à cela, cela sert à autre chose, ici le design te pousse dans cette direction, là il t’empêche d’aller dans cette autre. Le matin, je travaille avec les mêmes outils que ceux qui ont dessiné ce plan. De cette fracture naît un livre que j’ai écrit et que j’ai décidé de rendre disponible gratuitement. Il s’appelle I tuoi figli non sono i tuoi utenti (Vos enfants ne sont pas vos utilisateurs), et il tente de faire une chose très précise : transférer un fragment de savoir professionnel à qui ne possède pas ce savoir, parce que la différence entre l’avoir et ne pas l’avoir, quand il s’agit de ses propres enfants, est énorme.

Skinner, le pigeon, le fil

Pour donner une idée du type de savoir dont je parle, je prends un seul exemple parmi beaucoup d’autres, celui qui me semble le plus important et le moins connu. Entre les années quarante et cinquante, le psychologue B. F. Skinner a mené une série d’expériences avec des pigeons en cage. Si le pigeon frappait un disque avec son bec, il obtenait de la nourriture. Skinner a découvert une chose intéressante : si la nourriture arrivait à chaque fois que le disque était frappé, le pigeon le frappait quand il avait faim, et c’était tout. Si en revanche la nourriture arrivait de manière imprévisible, une fois sur trois, sur cinq, sur deux, le pigeon se mettait à frapper le disque continuellement, de manière compulsive, même quand il n’avait pas faim. La récompense variable, ce mécanisme-là, est le moteur psychologique des machines à sous. C’est aussi le moteur psychologique du fil d’un réseau social, et pas par analogie poétique, mais par conception explicite.

Quand votre enfant scrolle Instagram pendant vingt minutes, la plupart des contenus qu’il voit sont banals, sans importance, oubliables. De temps en temps, pourtant, quelque chose de bon arrive, quelque chose qui le fait rire, une nouvelle qui l’intéresse, une photo qui le concerne. Il ne sait pas quand cela arrivera. Il sait seulement que s’il continue à scroller, tôt ou tard cela viendra. Son cerveau est en train de faire, dans une version élégante et numérique, exactement ce que faisait le pigeon de Skinner.

Random personnalisé

Il y a une différence importante qui aggrave les choses, et que ceux qui ne travaillent pas dans le secteur ne prennent généralement pas en compte. Les machines à sous des salles de jeux distribuent les gains au hasard, parce qu’elles ne savent rien du joueur. L’algorithme d’un réseau social sait ce que vous aimez, ce sur quoi vous vous arrêtez une seconde de plus, ce qui vous indigne, ce qui vous émeut. Il utilise ces informations pour calibrer la distribution des contenus de manière à maximiser l’effet du renforcement variable sur vous, spécifiquement. Ce n’est plus du random, c’est du random personnalisé, paradoxalement plus efficace que le pur hasard parce qu’il maintient l’imprévisibilité (vous ne savez pas quand le bon contenu arrivera) en ajoutant la pertinence (quand il arrive, il est calibré sur vos intérêts). Pour un cerveau adolescent, dont le cortex préfrontal est encore en construction, ce mécanisme est particulièrement puissant.

Les autres mécanismes

La récompense variable est l’un des mécanismes que le livre décrit. Il y en a d’autres : le scroll infini qui élimine les points de décision, l’autoplay qui rend le « continue à regarder » le défaut, les notifications calibrées pour produire une réponse physique involontaire, les dark patterns qui rendent simple l’inscription et difficile la sortie. Tous sont documentés, tous sont enseignés, tous sont appliqués sans distinction d’âge, y compris aux produits que votre enfant a sur son téléphone. Il n’y a rien de clandestin dans tout cela. C’est de la littérature ouverte, accessible à quiconque veut la lire. Le problème, c’est que ceux qui la lisent sont presque toujours ceux qui construisent ces produits, rarement ceux qui les subissent.

Ce que sait celui qui construit, et ce qu’il fait avec ses enfants

De là naît la question qui donne son titre au livre, et qui est la plus simple que je connaisse sur toute cette affaire. Les écoles privées de la Silicon Valley qui interdisent les écrans en classe ne sont pas une légende urbaine. Tim Cook, CEO d’Apple, a déclaré publiquement qu’il n’aurait pas permis à son neveu d’utiliser les réseaux sociaux. Sean Parker, premier président de Facebook, a décrit le design de la plateforme comme consciemment orienté à exploiter une vulnérabilité de la psychologie humaine, et a ajouté que seul Dieu sait ce qu’il fait au cerveau de nos enfants. Chamath Palihapitiya, ex-vice-président de la croissance utilisateurs de Facebook, a dit publiquement que ses enfants n’avaient pas le droit d’utiliser cette chose. Les témoignages d’insiders qui admettent protéger leurs propres enfants des produits qu’ils ont contribué à construire ne sont pas cachés, ne sont pas ambigus, ne sont pas rares. Il suffit de les chercher.

L’observation que je fais dans le livre, et que je fais aussi ici, est plus petite et plus ordinaire que ces déclarations célèbres. Parmi les collègues qui travaillent dans le logiciel avec qui je parle régulièrement, ceux qui ont des enfants sont presque unanimes sur une chose : des règles plus restrictives sur l’usage du téléphone par rapport à la moyenne des parents non-tech, accès retardé aux réseaux sociaux, contrôle attentif de quelles applications sont installées, conversations avec les enfants sur le fonctionnement des notifications et sur leur raison d’être. Ce n’est pas une donnée scientifique, c’est une observation anecdotique. Mais elle est cohérente, elle est récurrente, et son existence même démontre le point : ceux qui connaissent le mécanisme se comportent autrement.

Si les personnes qui construisent ces choses en tiennent leurs propres enfants à distance, qu’est-ce qu’elles savent et que nous ignorons ?

Asymétrie informationnelle, et le livre

Ce n’est pas une question rhétorique. Il n’y a pas de pièce secrète où les dirigeants de la tech planifient comment nuire aux enfants du monde. Il y a quelque chose de bien plus banal et de bien plus difficile à combattre, que les économistes appellent asymétrie informationnelle. D’un côté, ceux qui comprennent comment fonctionnent les produits numériques, comment ils sont conçus, quels leviers psychologiques ils utilisent et pourquoi. De l’autre, ceux qui les utilisent, et les font utiliser à leurs propres enfants, sans avoir ces informations. Cette asymétrie existe depuis qu’existent les industries. Les chimistes des entreprises agroalimentaires savent sur la nourriture des choses que les consommateurs ignorent. Les ingénieurs automobiles savent sur les voitures des choses que les conducteurs ignorent. La différence, c’est que dans ces secteurs, avec le temps, s’est construit un système d’étiquetages, de standards de sécurité, d’obligations de transparence. Pour les produits numériques, ce système est encore largement à construire, et entretemps nos enfants y passent des heures chaque jour.

Le livre tente de combler cet écart. Pas tout, ce serait une prétention excessive. Une partie. Il explique comment fonctionnent les principaux mécanismes dans un langage qui ne demande pas de compétences techniques, raconte ce que nous savons et ce que nous cherchons encore à comprendre sur les effets qu’ils ont sur nos enfants, et tente de tracer ce que chacun peut faire dans son rôle : comme parent, comme citoyen, comme utilisateur, et aussi, pour qui comme moi travaille dans le secteur, comme personne qui construit cette chose. Ce n’est pas un manuel de survie parentale, et ce n’est pas un livre contre la technologie. C’est une tentative de transférer une petite partie de savoir professionnel à qui ne le reçoit pas habituellement.

Le livre est gratuit, en epub et pdf, et se trouve sur ebook.margiovanni.it. Si vous le lisez et qu’il vous est utile, ce que je vous demande, c’est de le passer à un autre parent. Ce passage entre deux personnes qui se connaissent vaut plus que n’importe quel algorithme de recommandation, et c’est exactement le type de chose que les mécanismes dont parle le livre ne savent pas faire.

Un grand client d’un secteur régulé nous a demandé, il y a quelques mois, de mettre en sécurité la plateforme. La demande était formulée dans les termes habituels : sécurité informatique et audit de conformité. Ce qu’ils ont finalement rapporté chez eux, c’est une Annexe 2 du DPA articulée en dix-neuf sections, une gap analysis technique, une feuille de route de remediation, une formalisation de la chaîne de sub-processors écrite pour tenir face à un contrôle sérieux. Pas une ligne de code nouvelle dans ce que nous leur avons livré, et pas davantage une plateforme à licencier. Du papier structuré et du positionnement contractuel, produits de manière à être défendables devant quiconque viendrait demander des comptes. La chose intéressante, c’est que ce n’était pas une exception : c’était la règle qui s’est installée dans nos douze derniers mois de travail.

On pourrait soutenir que la carte de ce marché existe déjà et qu’il suffit de lire le Magic Quadrant de Gartner sur les outils GRC, ou de consulter les rapports Forrester sur les plateformes de privacy management. Ce serait un raccourci commode et partiellement trompeur. Ces documents photographient le marché global des plateformes, où l’on trouve ServiceNow, MetricStream, OneTrust, Drata et Optro, qui vient de renommer AuditBoard en mars dernier. Le marché italien de la compliance a en revanche une structure propre, façonnée par l’Agenzia per la Cybersicurezza Nazionale, par la transposition de NIS2 avec le decreto legislativo 138 du 2024 (transposition italienne de NIS2), par le poids dominant de l’administration publique sur le total des achats, par la vitesse irrégulière à laquelle les directives européennes deviennent opérationnelles chez les clients finaux. Pour le lire, il faut une carte faite de l’intérieur.

En haut : le conseil spécialisé

Il me semble utile de le regarder comme un sablier. En haut, s’est formée une couche épaisse de conseil spécialisé. Les Big4 — Deloitte, PwC, EY, KPMG — ont des pratiques GRC désormais indiscernables dans les propositions commerciales, et qui se font concurrence davantage sur le nom des senior partners que sur les méthodologies. À côté d’elles, et dans certains cas à un niveau qualitativement supérieur, opèrent les boutiques italiennes structurées. P4I, du groupe Digital360, déclare plus de cent soixante professionnels sur son site et vend une marque méthodologique appelée Advisory Engine, avec un produit catalogué sous le nom de Compliance360. ICTLC a consolidé l’angle legal-tech qui est aujourd’hui à la mode, mais qui ne l’était pas quand elle a commencé. Spike Reply opère à l’intérieur du groupe Reply tout en gardant une identité reconnaissable, et couvre tout le spectre de la cybersécurité et de la protection des données avec un poids significatif sur les dossiers financial et manufacturiers. Deda Tech a choisi la voie de l’équipe pluridisciplinaire, où juristes et économistes s’assoient à côté des ingénieurs, et déclare ouvertement dans des interviews publiques ne pas vendre des solutions techniques mais de la confiance. La phrase sonne comme du marketing, et correspond au positionnement réel.

Ce que ces acteurs vendent, c’est de l’interprétation. Pas un logiciel qui fait quelque chose, mais une personne identifiable, capable de traduire une norme dans les termes spécifiques de votre filière et de tenir la table de négociation d’un Data Processing Agreement avec un cloud provider américain sans céder ce qu’il ne faut pas céder. Les marges sont hautes et la scalabilité est basse. La dépendance au nom unique à la barbe grise, ou au curriculum académique, est structurelle au modèle. La croissance se fait par cooptation, par hiring de noms qui pèsent, par acquisitions de cabinets plus petits qui apportent en dot des portefeuilles clients consolidés. C’est un mécanisme qui ressemble plus au monde juridique qu’à celui du logiciel.

En bas : les plateformes

En bas, s’est formée la couche des plateformes. Les projections d’IntelMarket Research évaluent le marché global des plateformes GRC à 16,7 milliards de dollars en 2024, avec un horizon 2032 à 32,8 milliards et un taux composé de 9,9 %, et d’autres estimations donnent des chiffres sensiblement différents selon le périmètre retenu, mais la direction est celle-là. ServiceNow GRC est le défaut pour qui utilise déjà ServiceNow pour l’IT service management, ce qui représente une part significative de l’enterprise italien. MetricStream couvre le segment des multinationales avec des programmes GRC matures. OneTrust a transformé le RGPD en produit et se repositionne maintenant sur l’AI governance. Drata et Vanta automatisent SOC2 et ISO 27001 pour startups et scale-ups, avec une preuve collectée en continu et des prix SaaS qui entrent dans le budget d’un CTO sans devoir passer par le CFO. La part italienne de cette couche est mince. Le marché italien du logiciel dédié à la compliance n’a pas produit d’acteur d’échelle internationale, et les tentatives locales restent confinées à des verticales uniques ou à des clients uniques.

Le middle layer compressé

Entre ces deux couches, là où le sablier se resserre, se trouve le middle layer, et c’est là que se joue la dynamique intéressante. C’est la couche du logiciel custom pour la compliance, des progiciels RGPD faits sur mesure, des plateformes verticales pour ISO 27001 développées par des software houses italiennes de taille moyenne. Pendant des années, ce fut une couche confortable. Le client ne faisait pas confiance aux plateformes américaines pour des raisons de souveraineté de la donnée, les Big4 coûtaient trop cher pour le mid-market, et une software house locale qui livrait le portail RGPD brandé était la solution naturelle. Aujourd’hui, cette couche est compressée des deux côtés simultanément. Par le bas parce que Drata fait du SOC2 à une fraction du coût d’un progiciel custom, et que les startups n’ont aucune raison de se faire développer quoi que ce soit de propriétaire pour une fonction commodity. Par le haut parce que lorsque le problème devient sérieux — une DPIA défendable, ou une négociation contractuelle avec Microsoft qui ne laisse pas de trous —, le client comprend que le logiciel ne suffit pas et qu’il a besoin d’une personne qui parle sa langue et qui signe des documents qui tiennent.

ACN, et le marché dans le marché

Ce qui rend la carte italienne structurellement différente de la carte globale, c’est ACN. Le Regolamento unico per le infrastrutture digitali e i servizi cloud (le règlement italien unifié sur les infrastructures numériques et les services cloud), decreto direttoriale 21007 du 27 juin 2024, en régime ordinaire depuis le 1er août de la même année, a créé un marché dans le marché. L’administration publique ne peut acheter des services cloud que s’ils sont qualifiés QC1, QC2, QC3 ou QC4, fournis sur des infrastructures adéquates AI1 à AI4, selon une matrice qui lie la classification de la donnée au niveau de service admis. Aruba a qualifié aux niveaux les plus élevés, Polo Strategico Nazionale gère les données classées comme stratégiques, une poignée d’autres fournisseurs est en train de remplir les cases restantes du catalogue. Pour les intégrateurs de systèmes italiens qui travaillent avec la PA, le choix concret devient binaire. Soit on revend le cloud qualifié de quelqu’un d’autre, en acceptant des marges compressées et un rôle d’implémentateur, soit on construit un conseil qui oriente le client PA dans le choix architectural, en capitalisant la connaissance du catalogue qualifié comme actif distinctif. Quand j’ai préparé pour Pescara Multiservice la proposition d’hébergement cloud ACN-qualifié basée sur Aruba VPC au niveau QC3, contre le tarif réel ARB-11504-1 de 217,38 € par mois, la part de valeur que le client achetait, c’était mon travail de traduction entre ses besoins applicatifs et les exigences du catalogue. L’infrastructure était commodity. L’interprétation, non.

Ce que font les intégrateurs de systèmes

À ce stade, on comprend ce qui arrive aux intégrateurs de systèmes italiens, et pourquoi. Les grands — Reply, Engineering, Almaviva, NTT Data Italia, Accenture — ont déjà des pratiques GRC internes qui concurrencent directement les Big4, et dans certains cas les ont dépassées sur les marchés publics. Spike Reply est l’exemple canonique de ce mouvement, mais pas le seul. Les moyens — Deda Tech, Var Group, Lutech — construisent des équipes pluridisciplinaires et revendent leur identité de trusted advisor avec un nouveau langage. Le chiffre d’affaires d’implémentation reste significatif, mais la marge haute se trouve là où l’on vend des journées d’interprétation et non des sprints de développement. Les petits se trouvent face à un choix plus étroit. Ils peuvent devenir revendeurs de quelqu’un d’autre, en perdant leur identité. Ils peuvent rester implémentateurs spécialisés sur une verticale où la profondeur de domaine compense le manque d’échelle. Il y a ensuite une troisième voie, plus risquée que les autres, qui consiste à se transformer en conseil boutique et à vendre de la connaissance d’abord, l’implémentation ensuite, en renonçant à une partie de chiffre d’affaires certain en échange d’un positionnement encore incertain. La majorité ne choisit pas : elle subit passivement le mouvement du marché. Chez Oltrematica, le choix, nous l’avons fait verticalement — santé privée et administration publique locale —, avec un investissement sérieux dans la documentation de compliance comme produit. Ce DPA, la formalisation à cinq niveaux d’une chaîne de sub-processors qui traverse trois sociétés du même groupe industriel, l’analyse du nouveau template DPIA que l’EDPB a adopté le 10 mars et publié le 14 avril en consultation jusqu’au 9 juin, sont autant de morceaux de travail que, il y a cinq ans, nous aurions faits comme accessoire du projet principal. Aujourd’hui, c’est le projet principal, et le logiciel vient après — quand il vient.

Où migre la valeur, et ce que je ne sais pas du 2027-28

Il y a une conséquence de tout cela qui mérite d’être rendue explicite. La valeur, sur le marché italien de la compliance, migre vers les deux extrémités du sablier. Les plateformes internationales tirent vers le bas le coût de la preuve, et cette pression ne s’arrêtera pas, parce que leur modèle d’affaires dépend de l’automatisation progressive. Les boutiques de conseil et les pratiques GRC des grands intégrateurs poussent vers le haut le prix de l’interprétation, et il n’y a pas d’innovation technologique à l’horizon qui réduise le coût d’une opinion signée par un nom reconnaissable. Ce qui reste au milieu, le logiciel custom pour la compliance, a devant lui une bifurcation. Il peut devenir spécialiste à l’intérieur d’une verticale jusqu’au point de ne plus être substituable par les plateformes généralistes, ou il peut être absorbé à l’intérieur d’une offre de conseil comme capability et non plus comme produit autonome. La donnée du Politecnico di Milano, qui estime le segment cyber et data protection italien à 2,78 milliards d’euros en 2025 avec une croissance de douze pour cent, ne distingue pas ces couches dans ses relevés, et c’est probablement l’une des raisons pour lesquelles les entreprises du middle layer continuent de lire les chiffres comme des bonnes nouvelles, alors qu’ils disent quelque chose de plus subtil.

La phrase la plus honnête que je puisse écrire sur la configuration de ce marché en 2027 et en 2028, quand le Cyber Resilience Act sera opérationnel et l’AI Act en pleine enforcement, c’est que je n’en sais rien. Il me semble plausible qu’il se forme un middle layer reconfiguré, où des outils comme Claude Code, GitHub SpecKit et leurs dérivés permettront à des software houses comme la nôtre de produire des artefacts de compliance traités comme du code — versionnés, testés, générés à partir de spécifications formelles traçables. C’est une direction sur laquelle j’investis personnellement, et que je raconte ici depuis plusieurs mois. Mais il est aussi possible que le middle layer s’effondre entièrement et que le marché italien se polarise sur les deux extrémités, comme c’est arrivé sur d’autres marchés matures avant le nôtre. Dans douze mois, cette carte sera à refaire. Ce sera l’un des exercices que je ferai.

Un spectre hante l’Europe, et pour une fois ce n’est pas celui imaginé par Marx. C’est un spectre plus curieux, parce qu’il ne hante pas ceux d’entre nous qui l’habitent. Il hante ceux qui nous observent depuis l’extérieur, de l’autre côté de l’océan, et qui nous regardent comme on regarde un parent excentrique au déjeuner de Noël : quelqu’un avec qui l’on est obligé d’échanger, dont au fond on aimerait se débarrasser, mais qui s’obstine à exister et à parler de choses étranges comme la dignité du travail, l’accessibilité, la protection des mineurs, la responsabilité du fait des produits. Le spectre, c’est nous. Ou plutôt, c’est ce que nous sommes en train de faire ici en matière de régulation du numérique : une série d’acronymes qui, à Bruxelles, sont considérés comme un travail technique ordinaire, et qui, à San Francisco, sont perçus comme une menace de nature presque existentielle.

Vue de l’extérieur, et notamment vue depuis une partie bien précise du monde qui s’est fait beaucoup entendre ces dernières années, l’Europe est devenue un personnage. Elle n’est plus un sujet économique, ni une union politique, ni même, désormais, le continent des centaines de millions de personnes qui l’habitent. Elle est un meme. Un meme avec une fonction narrative précise : incarner ce que le futur ne doit pas être. La bureaucratie du XIXe siècle collée par-dessus le XXIe. Le vieux monde qui freine le nouveau. Le musée à ciel ouvert qui prétend dicter ses règles à l’usine de demain. C’est une caricature, bien sûr, mais c’est une caricature efficace, parce qu’elle fonctionne dans une histoire bien plus grande qu’elle, et cette histoire, c’est la guerre culturelle qu’une partie du capitalisme américain mène contre l’idée même que le logiciel puisse faire l’objet de normes.

Le RGPD et le bandeau qui le résume

Pour comprendre où nous en sommes aujourd’hui, il est utile de remonter un peu. Le moment où le rapport entre la Silicon Valley et la régulation européenne s’est fissuré de façon difficile à recoller, c’est le RGPD. Un règlement de 2016, applicable à partir de 2018, techniquement non révolutionnaire, inspiré en grande partie de principes qui existaient déjà dans la Convention 108 et dans la directive 95/46. Et pourtant, ce que le RGPD a fait dans la pratique, c’est déclarer que certains modèles d’affaires fondés sur la collecte indiscriminée de données personnelles devaient, à un moment donné, rendre des comptes. Ce n’est pas un hasard si le RGPD est devenu la cible symbolique par excellence de la narration anti-européenne, et ce n’est pas un hasard si la manière la plus répandue de l’attaquer passe par le bandeau cookies.

C’est ici que je dois faire ma première concession. Le bandeau cookies tel que nous le vivons est un échec. Il l’est du point de vue de l’utilisateur, qui clique pour s’en débarrasser sans lire. Il l’est du point de vue de la protection effective, parce que ce consentement est presque toujours fictif. Il l’est du point de vue du designer d’interface, contraint d’accepter que chaque site européen s’ouvre sur un poste de douane numérique que personne ne désire. C’est l’exemple classique d’une norme correcte sur le plan des principes qui s’est déchargée sur le plan applicatif d’une manière grotesque, parce que le législateur a supposé que le consentement était un acte de volonté souveraine d’un sujet rationnel, et que les designers de produits numériques savaient parfaitement qu’il suffisait de concevoir le bandeau d’une certaine façon pour qu’on le clique en une demi-seconde. Le dark pattern a dévoré la théorie du consentement libre, spécifique, éclairé et univoque. On le voit chaque jour. C’est un problème réel. Ceux qui le critiquent ont raison sur ce point précis.

Mais c’est ici que commence la divergence entre la critique utile et la critique instrumentalisée, parce que ceux qui ont raison sur le bandeau cookies ne sont pas, en réalité, en train de discuter du bandeau cookies. Ils utilisent le bandeau cookies comme métonymie pour attaquer l’idée même que la collecte de données personnelles soit un problème régulable. Ils disent, en substance, que si la règle produit une mise en œuvre laide, alors la règle est à abolir, et non que la mise en œuvre est à corriger. Il s’agit d’un mouvement rhétorique ancien, et il n’y a pas lieu ici de déranger qui que ce soit : il suffit d’observer que ceux qui défendent l’abolition du RGPD au nom du bandeau cookies ne défendent en général pas la modification des règles techniques de consentement, qui serait la position cohérente. Ils défendent le retour à un monde où les plateformes américaines feraient ce qu’elles veulent de nos données sans devoir s’en expliquer à personne. Le bandeau était un prétexte, pas un argument.

DSA, DMA, et le modèle d’affaires

Que ce soit un prétexte, on l’a compris définitivement avec le DSA et le DMA. Quand la Commission a commencé à demander aux gatekeepers d’ouvrir leurs plateformes, de rendre interopérables certains services, de ne pas favoriser leurs propres produits dans les stores, de permettre aux utilisateurs de désinstaller des applications préinstallées, l’argument « vous régulez trop » s’est transformé sans transition en l’argument « vous attaquez nos entreprises ». Le saut est intéressant. Pendant des années, on nous a expliqué que le problème était l’excès de normes, et non l’identité de ceux qui paient. Depuis que les normes sont devenues opérationnelles, on nous explique que le problème, c’est qu’elles ne touchent que les champions américains. Les deux thèses ne sont pas compatibles, mais elles cohabitent très bien dans la même argumentation, et cela devrait déjà faire soupçonner qu’il y a quelque chose qui cloche.

Il y a une chose importante à dire à propos du DMA. La thèse selon laquelle le DMA viserait spécifiquement les entreprises américaines est faiblement fondée sur les faits, parce que parmi les gatekeepers figure aussi ByteDance, et parce que les seuils sont des seuils. Une entreprise européenne qui atteindrait les soixante-quinze milliards de capitalisation et les quarante-cinq millions d’utilisateurs finaux mensuels serait gatekeeper elle aussi. Le problème, c’est que les entreprises européennes dans cette tranche sont rarissimes, et que le seul cas récent, Booking, opère depuis Amsterdam mais relève d’une holding américaine. Cette absence ne dépend pas du DMA. Elle dépend de choix industriels, fiscaux, financiers et de formation des quarante dernières années que le DMA n’a pas causés et que le DMA ne résoudra pas. Si nous voulons parler de ce problème, parlons-en, et parlons-en sérieusement, en citant le rapport Draghi s’il nous faut un appui récent, mais ne le confondons pas avec la régulation des plateformes, parce que ce sont deux plans qui ne se touchent qu’en apparence.

C’est le point que ceux qui nous observent depuis l’extérieur ne veulent pas voir, ou peut-être qu’ils voient parfaitement et font mine de ne pas voir. La régulation des plateformes n’est pas en concurrence avec l’innovation. Elle est en concurrence avec un modèle d’affaires précis : celui de l’extraction massive de données personnelles, de l’optimisation de l’attention jusqu’au seuil de l’addiction, de la capture de marchés adjacents par effet de levier d’une position dominante, du déversement systématique des externalités négatives sur le corps social. Il se trouve que ce modèle d’affaires a été le modèle dominant du capitalisme numérique américain ces vingt dernières années. Il se trouve que les entreprises qui l’ont pratiqué sont aujourd’hui les plus grandes du monde, et qu’elles ont un intérêt évident à continuer à le pratiquer. Si l’Union européenne dit que ce modèle précis a des limites, elle touche un nerf à vif, et pas par accident. Elle dit, plus ou moins articulé, qu’il existe une autre façon de faire de la technologie numérique. En 2026, c’est une hérésie.

De la norme à l’objet technique

Je laisse un instant l’analyse pour raconter un épisode concret, parce que je crois qu’il est utile de comprendre d’où je parle. Je travaille depuis plusieurs années dans une société ICT italienne de taille moyenne, en dehors des grandes zones métropolitaines, qui fait du logiciel pour l’administration publique et la santé. Ces deux dernières années, mon travail a été en grande partie une seule chose : traduire les réglementations européennes en objets techniques. Ce que veut dire avoir une plateforme sanitaire conforme à l’article 28 du RGPD quand le fournisseur d’un fournisseur est en Allemagne et que la donnée de santé concerne un citoyen italien. Ce que veut dire, pour un organisme de formation qui dispense des cours de sécurité au travail au titre de l’Accordo Stato-Regioni — l’accord italien entre l’État et les Régions —, voir arriver le Cyber Resilience Act et comprendre que son LMS entre dans le champ d’application. Ce que veut dire, pour une software house qui produit un applicatif de gestion, se préparer à ce que la Product Liability Directive révisée ait étendu le régime de responsabilité du fait des produits défectueux au logiciel, y compris à certaines formes de composantes IA intégrées, et que ce régime s’appliquera opérationnellement aux produits mis sur le marché après décembre 2026. Ce que veut dire concevoir une AIPD en suivant le template approuvé par l’EDPB en mars dernier, en se rendant compte qu’il s’agit non pas d’un formulaire mais d’un genre documentaire qui doit être tenu vivant en même temps que le système qu’il décrit. Ce sont des travaux de traduction, pas d’abstraction. Les normes que de l’autre côté de l’océan on dépeint comme des obstacles à l’innovation sont, pour moi, l’innovation elle-même, parce qu’elles définissent le périmètre à l’intérieur duquel on peut bien concevoir.

Je ne le dis pas par adhésion romantique au projet européen. Je le dis parce qu’après avoir implémenté des dizaines de fois ces exigences à l’intérieur de systèmes réels, on voit une chose qu’un article d’Andreessen ne montre pas. On voit que la conformité n’est pas un coût isolé : c’est une pression de conception. Comme toutes les pressions de conception, elle restreint l’espace des choix et, en échange, elle oblige à mieux faire les choses, au moins dans la dimension que la norme protège. La PLD, par exemple, déplace la responsabilité du producteur sur la qualité du logiciel d’une manière qui, hier encore, n’existait même pas comme catégorie. Pour qui vend des produits sérieux, c’est un désagrément administratif. Pour qui vendait de la camelote en promettant que c’était de la magie, c’est un séisme. Devinez de quel groupe vient la critique la plus virulente.

On pourrait dire, et l’on dit, que ce raisonnement vaut pour mon petit cabinet italien mais ne vaut pas pour la frontière de la technologie. Le cabinet italien n’est pas en train d’inventer les modèles de fondation, n’est pas en train de concevoir des datacenters d’un gigawatt, n’est pas en train de redéfinir le paradigme de la recherche scientifique. C’est vrai. Mais c’est précisément pour cela que mon point d’observation me semble utile, parce qu’il raconte de très près ce que les grandes narrations californiennes n’arrivent jamais à voir, à savoir que la grande majorité du logiciel qui tourne dans le monde n’est pas la frontière, c’est de l’infrastructure du quotidien. Ce sont les systèmes de santé qui gèrent nos données cliniques, ce sont les portails de l’administration qui gèrent nos rapports avec l’État, ce sont les ERP qui font tourner les petites entreprises, ce sont les systèmes de formation qui certifient des compétences obligatoires par la loi. C’est du tissu. La réglementation européenne est écrite avant tout pour ce tissu, et le tissu, par définition, a besoin de règles pour exister comme tissu et non comme accumulation aléatoire de fils.

AI Act, Vance, et la course

Avançons, parce qu’il y a un autre thème qui mérite d’être pris au sérieux, et c’est l’AI Act. Là encore la concession s’impose. L’AI Act est un règlement difficile, écrit à un moment historique où la technologie qu’il devait réguler changeait toutes les quatre semaines. Il a eu une gestation compliquée, a subi un virage en cours de route quand sont arrivés les modèles de fondation, a produit dans le texte final certaines asymétries entre obligations pour les fournisseurs et obligations pour les utilisateurs que les opérateurs du secteur cherchent encore à appliquer. Il y a des ambiguïtés dans les codes de conduite sur les systèmes general purpose. Il y a des doutes sur la manière dont se calculent les seuils computationnels. Il y a des difficultés opérationnelles dans l’évaluation de conformité pour les applications high risk dans le domaine de la santé, et ici je parle d’expérience directe parce que Trustie, la plateforme sur laquelle je travaille comme CTO-as-a-Service pour Umana Analytics, doit composer avec certains de ces doutes en même temps qu’avec le RGPD et d’autres morceaux de la discipline européenne qui se chevauchent d’une manière qui n’est pas toujours linéaire.

Tout vrai. Tout juste. Et c’est exactement pour cela que l’AI Act n’est pas la fin du monde. C’est une norme jeune, en phase de rodage, qui se confronte à un secteur jeune lui aussi et en phase de rodage. Les difficultés d’application sont réciproques, parce que la technologie est en phase de découverte de son propre espace et la norme est en phase de découverte de sa propre application. C’est normal. C’est arrivé avec n’importe quelle technologie transformative : c’est arrivé avec la chimie industrielle du début du XXe siècle, avec la sécurité nucléaire de la seconde moitié, avec les dispositifs médicaux dans les années quatre-vingt, avec la finance après Lehman. Les normes nouvelles vivent leurs premières années en état d’itération. La différence, aujourd’hui, c’est que les opérateurs américains considèrent comme normal que la loi coure derrière la technologie, alors qu’ils considèrent comme scandaleux qu’elle se mette debout avant.

Le scandale est raconté en termes presque religieux. Ce n’est pas de la régulation, c’est de l’hyper-régulation. Ce n’est pas de la prudence, c’est de la couardise. Ce n’est pas de l’intérêt public, c’est du socialisme déguisé en droit. Vance, à Paris, l’année dernière, a tenu un discours qui restera dans les manuels non pour son contenu mais pour son ton. Il nous a expliqué, à l’auditoire européen, que nous étions en train d’étrangler l’IA avec nos peurs, que nous étions prisonniers de notre propre culte des garanties, que le futur n’attendrait pas. C’était un discours pensé pour être partagé en clips de quarante secondes. Il fonctionnait très bien pour cet usage. Il fonctionnait beaucoup moins bien comme analyse d’une norme qui, rappelons-le, n’interdit pas le développement de l’IA, mais l’articule selon des niveaux de risque. Le cadre conceptuel de l’AI Act est le même cadre par lequel n’importe quelle civilisation industrielle régule les substances chimiques dangereuses, les médicaments, les automobiles, les aliments destinés aux enfants. Personne ne demande à Vance de cesser de penser que la régulation est toujours excessive : c’est une position politique légitime et elle a sa tradition. Simplement, qu’il la présente pour ce qu’elle est, et non comme l’observation neutre d’un observateur neutre.

Il y a un argument qu’on entend souvent et qui me semble mériter une réponse. C’est l’argument de la course. L’IA est une course, nous dit-on, et l’Europe est en train de la perdre. Pendant que nous écrivons des règlements, la Chine construit, les États-Unis construisent, et dans cinq ans nous serons hors-jeu. Bien. Je le concède aussi, en partie. Sur le plan des infrastructures computationnelles et de la disponibilité de capital-risque, l’Europe est effectivement à la traîne, et elle le sera longtemps, et c’est un problème sérieux qui exigerait une vraie politique industrielle, des investissements publics substantiels, l’intégration du marché des capitaux européen, des réformes du travail académique : rien dont nous ne discutions sérieusement depuis des décennies. Mais la course, de quelle course parlons-nous. Une course se définit par l’arrivée. Quelle est l’arrivée. Avoir notre version d’OpenAI. Et après. Avoir notre version de Meta. Et après. C’est-à-dire avoir des entreprises qui font quoi, à qui, pour obtenir quoi, en vendant quoi et à qui. La question n’est pas oiseuse, parce que les entreprises que les amis de Vance nous proposent comme modèle sont des entreprises dont la valeur repose en grande partie sur un présupposé précis : que l’on puisse collecter et utiliser des données personnelles avec des limites minimales et que l’on puisse passer à l’échelle des modèles d’affaires fondés sur l’attention sans contraintes substantielles sur la protection des mineurs. Si l’Europe veut être celle qui court derrière ce modèle et tente de le répliquer, alors oui, elle est en train de perdre. Si l’Europe veut être celle qui propose une alternative, la course est autre. Elle se joue sur un autre terrain. Elle se gagne avec d’autres règles. Et la régulation, dans ce cas, n’est pas un frein. C’est le produit.

Brussels Effect et le mur normatif à bannière étoilée

Je me rends compte que cette phrase sonne présomptueuse, et en partie elle l’est. Mais c’est le cœur de la question. Le Brussels Effect, dont parle Anu Bradford depuis au moins une décennie, n’est pas une invention rhétorique. C’est un mécanisme concret. Quand l’Union européenne fixe un standard, et quand le marché européen est assez grand pour ne pas pouvoir être ignoré, les entreprises globales finissent par adopter ce standard comme défaut, parce que tenir deux architectures parallèles coûte plus cher que d’en tenir une seule. Le RGPD est, depuis des années déjà, un défaut informel pour la conception des systèmes de gestion de données dans les entreprises qui opèrent globalement. Les spécifications d’accessibilité européennes finissent par être implémentées partout, parce que celui qui vend ne serait-ce qu’un tiers de ses produits en Europe ne conçoit qu’une seule interface. Le CRA produira un effet semblable sur le logiciel. La PLD produira un effet semblable sur la responsabilité du fait des produits. L’AI Act produira un effet semblable sur la classification du risque des systèmes automatisés. Ce n’est pas une imposition coloniale à l’envers, c’est le fonctionnement ordinaire du marché, et c’est exactement pour cela que cela met les techno-optimistes en rage, parce que leurs entreprises sont contraintes de s’adapter à des règles qu’elles n’ont pas écrites.

Puis il y a l’argument du mur normatif. L’Europe, nous dit-on, est en train de construire un mur normatif qui exclut les fournisseurs américains. Cet argument mérite d’être pris vraiment au sérieux, parce qu’il a une part de vrai et une part de faux, et ceux qui l’utilisent mélangent généralement les deux. La part de vrai, c’est que certains règlements, en particulier le Data Act, certaines dispositions sur la cybersécurité coordonnée, certaines normes sur les clouds souverains, ont effectivement une composante de politique industrielle, au sens où ils cherchent à favoriser l’émergence d’une offre technologique européenne dans des secteurs critiques. Ce n’est pas un mystère, c’est écrit dans les considérants, et c’est une activité légitime que pratiquent tous les États et toutes les zones économiques du monde. La Chine le fait ouvertement, les États-Unis le font avec le CHIPS Act et avec l’Inflation Reduction Act, avec le contrôle renouvelé sur les investissements étrangers, avec les interdictions d’exportation de GPU avancés. La nouveauté n’est pas que l’Europe le fasse. La nouveauté, c’est qu’elle le fasse avec une spécificité européenne, fondée sur des exigences de transparence et de redevabilité, sur une préoccupation explicite pour les droits fondamentaux. Cela, aux yeux d’un investisseur américain du cercle d’Andreessen Horowitz, est une anomalie. Cela l’est dans la mesure où l’investisseur américain considère l’activité régulatrice comme, en soi, une aberration politique.

La part de faux, en revanche, c’est la prétention selon laquelle le mur normatif européen serait différent de n’importe quel autre mur normatif dans le monde. Essayez d’exporter du logiciel médical aux États-Unis sans la FDA. Essayez de vendre un service financier à des consommateurs américains sans autorisation SEC ou FINRA. Essayez d’opérer un véhicule autonome au niveau fédéral sans vous confronter au NHTSA. Essayez de vendre des jouets pour enfants sans la CPSC. Le système américain est plein de murs normatifs, et ces murs sont là depuis des décennies, et ils fonctionnent très bien comme barrières à l’entrée pour les fournisseurs étrangers. Quand une entreprise européenne en déplore le poids, la réponse standard américaine est « les règles sont les règles, si tu veux vendre ici tu t’adaptes ». C’est exactement la même réponse que nous donnons aujourd’hui à ceux qui protestent contre le CRA, et elle a exactement la même légitimité. Sauf que nous la donnons depuis une asymétrie de pouvoir narratif qui nous place, dès le départ, du côté du tort.

L’asymétrie narrative

Cette asymétrie narrative est le vrai spectre qui hante l’Europe. Pas l’Europe qui fait peur aux autres. L’Europe qui a peur d’elle-même, parce que l’unique cadre culturel dominant du secteur tech est celui élaboré en Californie ces vingt-cinq dernières années, et que ce cadre considère tout acte régulateur comme un échec par définition. Depuis ce cadre, chacune de nos normes est un symptôme de décadence. Chacune de nos directives est un signe de stagnation. Chacune de nos tentatives d’articuler une vision différente du rapport entre technologie et citoyens est rabaissée au rang de rancune de qui a perdu la course. C’est un cadre très efficace, et il est très difficile de le contester depuis l’intérieur de la tech européenne, parce que cette même tech européenne s’est souvent modelée sur la tech américaine : elle en lit les blogs, en adopte les outils, en absorbe le vocabulaire, et finit par juger son propre continent avec les yeux d’un autre.

Je vais plus loin. Quand je dis que le cadre californien est hégémonique, je ne fais pas de la sociologie de comptoir. Je décris le fait que, dans n’importe quelle conférence européenne sur le numérique, en 2026, une grande partie du lexique technique, une grande partie des exemples vertueux, une grande partie du frame interprétatif viennent de la littérature américaine du secteur. C’est un fait. C’est de là que passe le problème, parce que quand le régulateur européen tente d’écrire une norme, il doit le faire dans un environnement intellectuel peuplé d’opérateurs qui ont intériorisé la grammaire adverse. Ils n’en sont pas toujours conscients. Souvent, ils pensent en bonne foi être « pragmatiques », être du côté des « faits », vouloir « éviter l’hyper-régulation ». Mais ils utilisent un vocabulaire fait ailleurs, à des fins qui sont celles d’autres, et finissent par produire, même depuis des positions européennes, une défense implicite du modèle qu’ils voudraient critiquer. Le résultat, c’est que dans les couloirs de Bruxelles on discute de règlements progressifs pendant que dans les feeds des fondateurs italiens circulent des clips de Sacks expliquant que ces règlements sont une agression contre le libre marché. Les deux choses cohabitent. Plus encore, elles s’alimentent mutuellement. Chaque norme écrite à Bruxelles produit un nouveau round de plaintes à San Francisco, chaque round de plaintes à San Francisco produit un nouveau fléchissement culturel d’une partie de la classe entrepreneuriale européenne, chaque fléchissement culturel produit, en cascade, un affaiblissement politique du processus législatif suivant.

Le projet, et pourquoi il faut le nommer

À ce stade, après deux vagues de concessions et une d’analyse, le lecteur a sans doute deviné où je veux en venir. Je voudrais que nous soyons très clairs sur une chose. La haine pour la réglementation européenne du numérique, la vraie, la viscérale, celle qu’on trouve dans les posts de David Sacks, dans les interviews de Joe Lonsdale, dans les paranoïas de Balaji Srinivasan, dans les sorties de JD Vance, n’est pas un désaccord technique. C’est une position politique, c’est une position politique précise, et elle doit être reconnue pour ce qu’elle est. Cette position soutient que les États nationaux devraient reculer face aux entreprises technologiques, que les entreprises technologiques devraient jouir d’une souveraineté fonctionnelle équivalente ou supérieure à celle des États dans les territoires où elles opèrent, que la démocratie représentative est trop lente pour le rythme de l’innovation et que, en cas de conflit, c’est la démocratie qui doit s’adapter. C’est une position cohérente, et c’est une position qui a derrière elle des penseurs, des livres, des manifestes, et même des élaborations théoriques raffinées, du libertarianisme d’Ayn Rand au néo-réactionnarisme de Curtis Yarvin, en passant par l’accélérationnisme de droite qui s’inspirait de Nick Land, jusqu’aux dernières synthèses de Thiel sur le concept de stagnation. Ce n’est pas caricatural, même si sa version populaire l’est. C’est un projet.

Cela vaut la peine de s’arrêter un instant sur ce projet, parce que pendant longtemps il a été sous-estimé en Europe, et qu’il l’est sans doute encore. Le filon qui part de Yarvin, en particulier, soutient ouvertement que la démocratie représentative serait un système dysfonctionnel et qu’il faudrait la remplacer par des formes de gouvernement gérées comme des entreprises, par des CEO aux pleins pouvoirs, déliés des contraintes constitutionnelles. C’est une position qui, il y a dix ans encore, était considérée comme folklorique même par la droite américaine mainstream. Ces cinq dernières années, elle s’est normalisée, elle est entrée dans les conversations de Sand Hill Road, elle a trouvé un financement implicite et explicite à l’intérieur du réseau de Thiel, elle a colonisé des morceaux du Parti républicain et elle s’est assise, finalement, à l’intérieur de la Maison-Blanche avec un vice-président qui cite publiquement Yarvin sans embarras. Autrement dit, une partie significative de la classe dirigeante américaine actuelle considère l’arrangement libéral-démocratique d’après-guerre comme une expérience ratée, et considère son propre modèle techno-entrepreneurial comme sa successeure historique naturelle. Dans ce cadre, l’Union européenne n’est pas seulement une nuisance commerciale. Elle est, littéralement, une incarnation de tout ce que l’on veut dépasser : un sujet supranational qui impose des standards de transparence aux entreprises, qui protège la concurrence, qui pose des limites à la liberté du producteur au nom de droits qu’on ne peut ni acheter ni échanger. Pour qui pense que le futur doit être gouverné par les meilleurs, et que les meilleurs sont les vainqueurs du marché, l’Europe est un ennemi historique.

Je comprends que présentée ainsi la question puisse sembler poussée à l’extrême, et que beaucoup de lecteurs français — ou italiens, ou européens — peut-être pas hostiles par préjugé à la culture tech américaine, me diront que je fais le caricaturiste à l’envers. Je ne charge rien. Je prends seulement au sérieux ce que les personnes en question écrivent publiquement sur leurs propres profils. Allez lire les interviews de Marc Andreessen du biennium 2023-2024. Allez voir le manifeste techno-optimiste. Allez lire le livre de Yarvin de 2024. Allez écouter les podcasts All-In, surtout les pages où l’on commente la régulation européenne. Allez regarder le discours de Vance au sommet IA de Paris de février 2025. Je ne lis pas quelque chose entre les lignes. Tout est sur les lignes, écrit avec une franchise qui, de notre point de vue, est presque désarmante. La seule chose qui reste entre les lignes, c’est la conclusion politique, et la conclusion politique se formule ainsi : l’autorité démocratique n’a pas qualité pour poser des limites à l’activité des entreprises technologiques, parce que les entreprises technologiques sont en train de construire le futur et que l’autorité démocratique appartient au passé.

Face à ce projet, l’Union européenne, avec toute sa lenteur, avec toutes ses imperfections, avec tout son bandeau cookies, est effectivement le principal obstacle géopolitique contemporain. Elle l’est non parce qu’elle aurait un plan contre la tech américaine, mais parce que son modèle incorpore un présupposé que le projet californien veut démolir : le présupposé selon lequel l’autorité démocratique peut légitimement poser des limites à l’activité économique des entreprises. C’est tout. C’est un présupposé ancien, on le trouve dans la tradition constitutionnelle de tous les pays européens et même des États-Unis pré-Reagan, mais dans le contexte culturel de 2026 il est devenu hérétique. Notre hérésie consiste à reprendre ce présupposé et à l’appliquer au numérique. Rien de plus, rien de moins. C’est pour cela que nous sommes un spectre : parce que nous rappelons, par notre existence institutionnelle, qu’il est possible de penser autrement.

Europe cohérente, Chine mal placée

Je m’arrête un instant pour répondre à une objection que j’imagine. Mais l’Europe est-elle vraiment si cohérente. Il n’y a pas de divisions internes, pas de lobbies, pas de manœuvres nationales, pas de pataquès normatifs. Bien sûr qu’il y en a. L’Europe est un système politique complexe, avec des intérêts divergents entre États membres, avec l’Allemagne qui défend souvent les intérêts de sa propre industrie automobile même quand cela entre en conflit avec la cohérence environnementale, avec la France qui cherche souvent à promouvoir des champions nationaux sous couverture de politique industrielle européenne, avec l’Italie qui a une représentation technique souvent faible dans les tables qui comptent, avec des gouvernements nationaux qui utilisent l’hostilité à la régulation européenne comme outil de consensus interne. Tout cela existe. Rien de tout cela, pourtant, ne change le fait que l’output normatif du processus européen, à la fin, est cohérent avec un certain modèle de rapport entre technologie et citoyens, et que ce modèle est radicalement différent de l’américain, et que la différence est l’objet véritable du conflit.

Une autre objection. Et la Chine. La Chine, dans le discours anti-européen, est toujours convoquée en reductio ad absurdum : vous régulez, pendant que la Chine construit, et la Chine gagnera. C’est un mouvement rhétorique tellement bancal qu’il ne vaut souvent même pas la peine d’y répondre, mais il vaut la peine d’observer un détail. Le modèle chinois de gouvernement du numérique est un modèle dans lequel l’État, identifié au Parti, exerce un contrôle profondissime sur le comportement des plateformes, sur les contenus, sur les données, sur les flux internationaux. Pékin a, sur l’algorithme du TikTok chinois, un niveau d’intervention normative qui ferait passer le DSA pour le mode d’emploi d’un robot de cuisine. Et pourtant, quand les techno-optimistes citent la Chine comme modèle de non-régulation, ils ne le disent pas. Ils se contentent de citer la vitesse de construction des infrastructures, la vitesse de diffusion des applications IA, la vitesse de fermeture de sites comme Temu et Shein. Ils sautent, avec une élégance remarquable, l’existence de l’État. C’est parce que, au fond, leur problème n’est pas l’État en tant que tel : c’est un État démocratique qui imposerait des limites à leurs amis. Face à un État autoritaire qui imposerait des limites génériques à tous, et qui en même temps se garantirait à lui-même une position dominante incontestable, ils ont beaucoup moins à objecter. Le point, c’est la démocratie, pas la régulation. La régulation n’est que la forme par laquelle la démocratie, dans un monde numérique, prend forme juridique.

La technique au service de la politique

Je voudrais conclure en recomposant un peu de tissu, parce que j’ai commencé en citant Marx et il est juste que la boucle se ferme. Le spectre du Manifeste était une promesse de transformation. C’était quelque chose qui, aux yeux des classes dominantes du XIXe siècle, représentait la possibilité que le futur ne soit pas simplement la continuation du présent. Le spectre qui aujourd’hui trouble les rêves des venture capitalists californiens ne promet aucune révolution. Il promet seulement que le futur numérique puisse être conçu aussi par des sujets différents de leurs investissements, selon des principes différents des leurs, dans un cadre institutionnel qui précède leur modèle et qui survivra à son éventuelle crise. C’est un spectre modeste, et c’est précisément pour cela qu’il est insupportable, parce qu’il démonte la prétention d’exclusivité que le modèle californien s’est arrogée pendant un quart de siècle. Il démonte l’idée qu’il existerait une seule manière légitime de faire de la technologie numérique, selon les règles écrites par une communauté précise d’investisseurs dans une zone géographique précise de la planète. Il restitue à la technologie son statut d’artefact culturel pluriel, soumis à des institutions plurielles, contestable et contesté. Pour qui croyait avoir gagné l’histoire, c’est un affront.

Pour qui exerce ce métier, sur ce continent, en ces années, le spectre n’est pas une nuisance. C’est une boussole. C’est ce qui nous dit, chaque matin, quand nous ouvrons une pull request ou quand nous rédigeons un cahier des charges, que les choix techniques ont des conséquences politiques et que les conséquences politiques méritent d’être protégées par le droit. Nous ne le faisons pas parce que nous sommes décadents. Nous le faisons parce que nous avons une mémoire historique longue, et nous savons que les technologies sans contraintes, dans les quatre cents ans précédents, ont produit l’exact contraire de la liberté qu’elles promettaient. Nous le faisons parce que nous avons lu Polanyi, nous avons lu Hannah Arendt, nous avons lu les Pères constituants de notre continent, nous avons lu la jurisprudence européenne sur les droits fondamentaux, et de tout ce matériau nous avons tiré une conclusion simple. Le marché n’est pas une donnée de la nature. C’est une institution. Et comme toutes les institutions humaines, elle se construit et se corrige dans le temps. Le numérique est un marché. Ses règles ne descendent pas du ciel de la Silicon Valley. Nous les écrivons, nous aussi, ici, au milieu d’un continent qui se rend compte, lentement, d’être devenu le lieu le plus étrange du monde : le lieu où quelqu’un essaie encore de dire que la technique doit servir la politique, et non l’inverse.

Il y a une dernière chose que je voudrais dire, et je la dirai sur un ton plus personnel, parce que c’est le ton juste pour la clôture. Quand il m’arrive de parler de ces choses avec des collègues américains, en général, en moins de trois minutes, arrive le moment où l’on me demande, avec une nuance d’apitoiement sincère, si je ne me sens pas étouffé, en Europe, par toute cette bureaucratie. La question est posée en bonne foi. Ils pensent vraiment que nous vivons dans une espèce de cage régulatoire qui nous empêche de construire. La réponse la plus honnête que j’arrive à donner, c’est que non, je ne me sens pas étouffé. Je me sens à la bonne place. Parce qu’ici, au moins ici, la question « ce logiciel, qu’est-ce qu’il fait aux gens ? » est une question légitime, c’est une question qu’on peut poser à un conseil d’administration, c’est une question qui a des conséquences juridiques si la réponse est mauvaise. Ailleurs, la même question est considérée, dans le meilleur des cas, comme naïve. Dans le pire, comme subversive. Voilà. Je préfère l’état de choses dans lequel je peux la poser, même si pour la poser je dois accepter un peu de papier en plus, quelques audits, quelques templates EDPB, quelques évaluations de conformité. C’est un prix. Il se paie. Ce n’est pas un cataclysme. C’est, tout au plus, le prix de la civilisation.

Le spectre qui hante l’Europe, c’est nous. Et nous continuerons à l’être tant que quelqu’un, quelque part, considérera encore que la technique est une question politique et non une question d’ingénierie pure. Ce n’est pas peu. Ce n’est pas peu du tout.

Le contrat avait été signé fin 2023 et, du point de vue du fournisseur principal, c’était un contrat propre, bien structuré, avec toutes les clauses de sauvegarde que le service juridique avait exigées au fil des années. Il spécifiait clairement l’objet de la fourniture, fixait les niveaux de service, prévoyait les pénalités en cas de manquement, définissait le périmètre de responsabilité du fournisseur avec des plafonds standard à la valeur annuelle du contrat, excluait les dommages indirects, encadrait la sous-traitance par une clause exigeant que le client approuve les principaux sous-traitants et plaçant sur le client la charge d’en vérifier l’adéquation. Il avait été négocié pendant quatre mois, était passé par trois cycles de revue juridique des deux côtés, avait été signé par des dirigeants munis des procurations nécessaires. Le fournisseur principal, une software house de cinquante personnes, le considérait comme un bon contrat. Le client, une société de services de santé privée comptant un million d’assurés, le considérait comme un contrat équilibré. Pendant deux ans la relation s’est bien passée.

Fin 2025, un assuré a subi un dommage du fait de ce que le système clinique aurait dû faire et n’a pas fait. La cause technique a été imputée à une bibliothèque d’évaluation du risque que le système utilisait pour classer les priorités d’intervention. La bibliothèque avait été fournie par un sous-traitant approuvé par le client quatre ans plus tôt, avait été silencieusement mise à jour par le sous-traitant lui-même quatre-vingts jours avant l’incident avec un changement d’algorithme que personne n’avait communiqué au fournisseur principal, et personne n’avait demandé une mise à jour de la documentation parce que le sous-traitant considérait sa mise à jour comme une maintenance ordinaire. Le sous-traitant avait son siège dans un pays tiers, n’avait pas de représentant légal dans l’Union, et dans les mois suivant l’action en justice s’est révélé pratiquement injoignable pour les notifications judiciaires.

Le fournisseur principal a réagi à la demande de dommages de l’avocat de l’assuré en montrant le contrat. Il a soutenu que le sous-traitant avait été approuvé par le client, que la modification avait été introduite unilatéralement par le sous-traitant sans aucune communication, que le contrat excluait les dommages indirects et plafonnait la responsabilité à la valeur annuelle, et qu’en tout état de cause la responsabilité matérielle pesait sur le client en tant qu’entité gérant directement la relation avec l’assuré. L’avocat de l’assuré n’a contesté aucun de ces points contractuels. Il a simplement noté que le contrat entre fournisseur et client ne le concernait pas, parce qu’il ne l’avait pas signé, et que son action s’appuyait sur le nouveau régime européen de responsabilité du produit, sous lequel le fournisseur principal était qualifiable de producteur du produit défectueux et répondait à titre objectif envers le lésé final, indépendamment des clauses contractuelles convenues avec son client. Ces clauses, a-t-il ajouté, régissaient le recours entre les parties signataires, pas l’exposition envers les tiers. Le contrat, autrement dit, était un bon contrat entre les mauvaises personnes.

L’objection traditionnelle

L’objection que je voudrais affronter tout de suite, parce qu’elle est la plus enracinée et la plus sincère, c’est celle qui vient des juristes traditionnels avec qui j’ai travaillé ces dernières années. Elle dit ceci : tout cela est un problème de rédaction du contrat. Si les clauses sont bien écrites, si les manleves sont complètes, si les procédures de sous-traitance sont rigoureuses, le fournisseur principal est protégé. C’est une objection formellement cohérente avec la manière dont le droit des contrats a fonctionné pendant quarante ans dans le logiciel. Jusqu’à il y a quelques années, c’était aussi substantiellement vrai, parce que le régime de responsabilité du producteur de logiciel était faible, les actions des tiers lésés passaient presque toujours par le client direct, et le fournisseur principal pouvait raisonnablement attendre que son exposition s’épuise dans les limites contractuelles convenues.

Cette époque est terminée. Le régime juridique qui se consolide en Europe entre 2024 et 2027, et dont j’ai déjà écrit dans cette série à propos du logiciel évalué comme promesse écrite et de la spécification comme actif juridiquement pertinent, introduit un niveau de responsabilité qui opère hors du contrat et que le contrat ne peut que partiellement encadrer. La révision de la Product Liability Directive, applicable à partir du 9 décembre 2026, qualifie explicitement le logiciel de produit et applique au producteur de logiciel un régime de responsabilité objective envers les lésés finaux. Le Cyber Resilience Act, pleinement applicable à partir du 11 décembre 2027, introduit des obligations de sécurité du produit numérique qui pèsent sur le producteur tout au long du cycle de vie et s’étendent aux composants intégrés. L’AI Act répartit les obligations le long de la chaîne des fournisseurs de systèmes d’IA, de sorte que le fournisseur du système final doit garantir que les composants qu’il intègre sont conformes. Le Digital Operational Resilience Act, applicable à partir du 17 janvier 2025, impose aux entités financières et à leurs fournisseurs critiques d’ICT des obligations de gestion du risque de la chaîne d’approvisionnement qui traversent les frontières contractuelles. NIS2, applicable à partir du 18 octobre 2024, fait le même mouvement pour les secteurs critiques élargis. Pris individuellement, chacun de ces actes serait gérable avec quelques ajustements contractuels. Pris ensemble, et dans leurs intersections, ils définissent une structure de responsabilité que le contrat de fourniture n’est plus capable de contenir.

Les quatre présupposés tombés

Le modèle contractuel traditionnel du logiciel a grandi dans une époque où certains présupposés implicites tenaient, et il est devenu inadéquat parce que tous ces présupposés sont tombés dans la même décennie. Il y avait d’abord l’idée que la responsabilité du fournisseur envers le client épuisait l’exposition du fournisseur, parce que le client intermédiaire absorbait et gérait toute responsabilité envers les tiers lésés. Il y avait ensuite la conviction que le logiciel était un objet délimité au moment de la livraison, évaluable sur la base d’un cahier des charges statique au moment du release. On tenait pour acquis, en troisième lieu, que la chaîne d’approvisionnement était essentiellement bilatérale du point de vue juridique, c’est-à-dire que chaque maillon pouvait être encadré par un contrat entre deux parties sans avoir à se soucier des dynamiques globales de la chaîne. Et l’on présupposait enfin que le régime de responsabilité resterait stable dans le temps, suffisamment pour rendre raisonnable la signature de contrats pluriannuels sur la base du cadre juridique en vigueur au moment de la signature. C’étaient des présupposés qui ressemblaient à des lois de la nature de la contractualisation logicielle jusqu’aux environs de 2020, et qui, rétrospectivement, se révèlent n’être que les caractéristiques d’une époque juridique spécifique.

Le premier présupposé a été érodé par l’élargissement de la légitimité active des tiers lésés dans la nouvelle PLD. Sous l’ancien régime de responsabilité du produit, le lésé final pouvait agir contre le producteur, mais en pratique les actions passaient surtout par le revendeur ou l’intégrateur commercial, et le producteur de logiciel jouissait jusqu’en 2024 d’une incertitude interprétative sur le fait même de rentrer dans la définition de producteur. La nouvelle Directive, en incluant explicitement le logiciel dans la définition de produit et en introduisant des présomptions de défectuosité qui allègent la charge de la preuve du lésé, rend la position du producteur de logiciel beaucoup plus exposée. Elle ajoute en outre un mécanisme de disclosure documentaire permettant au juge d’ordonner au fournisseur d’exhiber la documentation technique du produit, et de présumer le défaut en cas de non-exhibition. À partir de ce moment, l’avocat du lésé n’a plus besoin de passer par le client intermédiaire et peut agir directement contre le fournisseur principal du logiciel qui a causé le dommage, ignorant entièrement les clauses contractuelles entre fournisseur et client, parce que ces clauses régissent une relation à laquelle le lésé est tiers. La chose est écrite explicitement à l’Article 15 de la Directive, intitulé « Exclusion ou limitation de la responsabilité », qui impose aux États membres de garantir que la responsabilité de l’opérateur économique envers le lésé ne puisse être limitée ni exclue par des clauses contractuelles ou par des dispositions de droit national. C’est un article court et technique, mais c’est la clé de voûte de tout l’édifice, parce qu’il transforme ce qui ressemblait à une marge de manœuvre contractuelle en zone d’indisponibilité juridique.

Le deuxième présupposé a été érodé par le Cyber Resilience Act et par l’AI Act, qui tous deux introduisent des obligations de sécurité et de gestion du risque pesant sur le producteur tout au long du cycle de vie du produit, et non plus seulement au moment de la livraison. Le logiciel a cessé d’être un objet délimité dans le temps de la livraison et se présente comme un objet continuellement exposé au régime réglementaire ; chaque mise à jour, chaque modification, chaque intégration de nouveaux composants peut être requalifiée comme modification substantielle qui fait rentrer le produit dans le régime applicable, même si le produit avait été mis sur le marché à une époque antérieure. Le fournisseur principal qui a livré le système en 2023 ne s’est pas déchargé de la responsabilité en 2026 quand une bibliothèque tierce intégrée à ce système a cessé d’être maintenue et a développé des vulnérabilités de sécurité. La responsabilité s’est simplement déplacée sur le plan de la maintenance, et le fournisseur qui n’a pas mis à jour est un fournisseur qui a manqué à une obligation continue, pas à une obligation limitée au moment de la livraison originelle.

Le troisième présupposé, celui de la bilatéralité de la chaîne d’approvisionnement, a lui aussi été érodé par l’introduction de chaînes de responsabilité qui traversent la contractualisation bilatérale. Sous le régime DORA, l’entité financière doit cartographier et gérer ses ICT third-party risk tout au long de la chaîne, et quand un fournisseur est qualifié de critique, les obligations s’étendent de sorte que les clauses contractuelles entre l’entité financière et le fournisseur critique doivent contenir des éléments spécifiques imposés par le Règlement, indépendamment de la volonté des parties. Le CRA, pour sa part, impose au producteur d’un produit numérique de garantir la sécurité du produit intégré, et cette garantie ne s’épuise pas dans les rapports contractuels avec ses sous-traitants, parce que le régulateur évalue le produit comme un tout unitaire indépendamment de la composition interne de la chaîne. La PLD révisée ajoute une complication supplémentaire en prévoyant que le modificateur substantiel d’un produit peut devenir lui-même responsable comme producteur, et cela ouvre une dynamique de responsabilité circulaire dans laquelle le fournisseur principal, l’intégrateur intermédiaire, le sous-traitant et l’utilisateur final peuvent être appelés en cause à des titres différents pour le même dommage. NIS2 et l’AI Act complètent le tableau en étendant des obligations analogues respectivement aux secteurs critiques élargis et aux systèmes d’intelligence artificielle à haut risque, avec pour résultat que chaque segment de la chaîne est aujourd’hui traversé par au moins deux ou trois régimes superposés que les clauses contractuelles bilatérales ne parviennent pas à composer.

Le quatrième présupposé, celui de la stabilité du régime juridique dans le temps, est celui dont l’érosion produit les effets les plus subtils, parce que les contrats pluriannuels signés aujourd’hui sous le cadre en vigueur seront appliqués demain sous un cadre qui aura évolué. Le fournisseur qui signe un contrat de six ou sept ans en 2026 se trouvera à l’exécuter en 2032 ou 2033 sous des régimes qui pourraient avoir alors changé de manière significative, parce que la PLD prévoit une clause de révision, parce que le CRA fera l’objet de lignes directrices qui modifieront l’interprétation de sections entières, parce que l’AI Act a déjà été défini comme un chantier ouvert par la Commission elle-même. Le contrat pluriannuel sous le modèle traditionnel présupposait une inertie réglementaire qui n’existe plus.

Quatre phénomènes que le contrat n’adresse pas

Chacun de ces quatre phénomènes a des conséquences pratiques que le contrat traditionnel ne sait pas adresser. La responsabilité solidaire des fournisseurs de composants critiques, introduite de manières différentes par la PLD et par le CRA, fait que le fournisseur principal répond des défauts des composants intégrés même quand les sous-traitants sont inexécutants ou injoignables. Les clauses contractuelles qui régissent le recours contre les sous-traitants restent valables entre les parties signataires, mais ne déplacent pas la responsabilité envers le lésé final, qui peut toujours agir contre le fournisseur principal comme maillon accessible et patrimonialement le plus solide de la chaîne. Le fournisseur principal qui voulait transférer le risque sur le sous-traitant par des clauses contractuelles se retrouve donc à devoir l’absorber et à pouvoir seulement essayer ensuite de récupérer par la voie du recours, à supposer que le sous-traitant soit encore existant, solvable et joignable.

Les obligations de disclosure documentaire introduites par la nouvelle PLD sont le deuxième phénomène, et elles sont particulièrement insidieuses parce qu’elles transforment le fournisseur en un sujet qui doit exhiber au juge sa propre documentation technique, même quand cette documentation inclut des choix de conception, des configurations de sécurité, des datasets d’entraînement, des décisions architecturales que l’entreprise considérerait comme secret industriel. Le juge doit équilibrer le droit à la disclosure avec la protection des secrets d’affaires, mais en pratique le fournisseur se trouve exposé à des demandes documentaires que le contrat avec le client ne peut limiter, parce que le contrat ne lie ni le juge ni le lésé. Le fournisseur peut avoir convenu avec le client de l’inaccessibilité de la documentation, mais si le lésé demande l’exhibition, le fournisseur doit produire, et le refus éventuel d’exhiber génère une présomption de défectuosité au sens de l’Article 10 de la Directive.

Les présomptions de défectuosité que le fournisseur seul ne peut renverser sont le troisième phénomène, et le plus subtil des quatre. La nouvelle PLD prévoit que le juge puisse présumer la défectuosité du produit quand le produit est techniquement ou scientifiquement complexe et que la preuve du défaut serait excessivement difficile pour le lésé. Pour les systèmes logiciels complexes, et en particulier pour ceux qui intègrent des composants IA, cette présomption s’active presque automatiquement, et la charge de la renverser pèse sur le fournisseur. Renverser la présomption exige de démontrer que le produit ne présentait pas le défaut au moment de la livraison, ou que le défaut a été introduit ultérieurement par des modifications hors du contrôle du fournisseur. Les deux démonstrations exigent une documentation historique détaillée du système, et le fournisseur qui n’a pas maintenu cette documentation se trouve dans l’incapacité de prouver quoi que ce soit, et donc à succomber à la présomption.

L’accountability du modificateur substantiel est le quatrième phénomène, et c’est celui qui rompt le plus radicalement la structure du contrat bilatéral. Quand un client ou un intégrateur intermédiaire modifie substantiellement un produit logiciel fourni par un tiers, il peut devenir lui-même responsable comme producteur du produit modifié, et cela ouvre une dynamique dans laquelle le fournisseur d’origine pourrait ne plus être responsable du produit tel que modifié, mais le modificateur pourrait ne pas avoir les compétences, la documentation et la structure pour assumer la responsabilité qu’il a matériellement assumée. Le résultat est une zone grise de responsabilité dans laquelle le lésé choisit qui assigner sur la base de critères d’accessibilité patrimoniale et procédurale, et dans laquelle les parties impliquées se renvoient la responsabilité avec des résultats souvent paradoxaux.

Le tassement qui n’arrive pas tout de suite

On pourrait objecter, et quelqu’un le fera, que tout cela est exagéré et que la pratique judiciaire trouvera un moyen de remettre de l’ordre dans le système. C’est une objection qui mérite respect, parce que la pratique judiciaire a toujours cette fonction de tassement, et parce que les règlements européens, une fois traduits en jurisprudence nationale, perdent souvent la rigidité qu’ils ont sur le papier. La réponse que je me sens de donner, après avoir observé comment la pratique évolue dans les juridictions européennes où les premiers cas émergent, c’est que le tassement viendra, mais qu’il viendra dans cinq ou sept ans, et qu’entre-temps la fenêtre d’exposition pour les fournisseurs qui opèrent sous des contrats traditionnels est très large. Les premières décisions importantes en matière de responsabilité du producteur de logiciel sous la nouvelle PLD n’arriveront pas avant 2028, parce que le régime s’applique aux produits mis sur le marché après le 9 décembre 2026 et que les actions en justice ont des délais minimaux d’un an et demi. À partir de là, il faudra encore trois ou quatre ans pour qu’une jurisprudence consolidée se forme. Pendant ce temps, chaque fournisseur opérant avec des contrats du vieux modèle accumule une exposition rétroactive, parce que beaucoup des systèmes qu’il livre aujourd’hui seront encore en production quand la jurisprudence se sera tassée, et seront évalués selon les critères qui se seront consolidés à ce moment-là.

Les secteurs qui nous précèdent

Il serait malhonnête de ne pas reconnaître qu’il existe des secteurs où ces dynamiques existent depuis des décennies, et où les contrats de fourniture ont une structure qui reconnaît l’inadéquation du modèle bilatéral traditionnel. Ce sont des secteurs qui vivent sous des régimes serrés de responsabilité du produit bien avant le logiciel généraliste, et qui ont développé des pratiques contractuelles qui méritent d’être étudiées. L’aviation civile en est un, et les contrats de fourniture de composants aéronautiques incorporent depuis toujours des obligations de traçabilité documentaire, de certification de tiers, de gestion coordonnée des non-conformités, de responsabilité solidaire envers les autorités réglementaires. Le dispositif médical en est un autre, et les contrats de fourniture de composants pour dispositifs médicaux prévoient des accords-cadres de qualité qui vont au-delà du simple contrat commercial, et qui régissent la relation entre les parties comme une relation réglementaire en plus que commerciale. L’automobile est le troisième, surtout après l’introduction des normes ISO 26262 sur la sécurité fonctionnelle des systèmes électroniques des véhicules, et les contrats de fourniture de logiciel pour l’automobile incorporent depuis une dizaine d’années des clauses de responsabilité le long de la chaîne qui reconnaissent l’impossibilité de confiner l’exposition dans des rapports bilatéraux.

Ce qui se passe dans le logiciel généraliste, c’est la convergence — accélérée par le paquet réglementaire européen — vers le modèle que ces secteurs pratiquent déjà. La différence est que aviation, dispositifs médicaux et automobile ont eu trente ans pour bâtir les pratiques contractuelles, les compétences internes, les standards de secteur et les relations de fourniture structurées. Le logiciel généraliste a cinq ou sept ans pour faire la même chose, et il doit le faire alors qu’il continue d’opérer sur des marchés où la majorité des concurrents raisonne encore avec le vieux modèle. C’est une transition asymétrique, dans laquelle qui bouge en premier paie un coût de positionnement que qui bouge ensuite ne paie pas, mais qui bouge en premier construit aussi des capacités d’absorber les évolutions réglementaires successives que qui bouge ensuite devra acheter à marché consolidé.

Cinq dimensions opérationnelles

Sur un plan opérationnel, la transformation du contrat de fourniture de logiciel a cinq dimensions à gérer simultanément. La première est le passage du contrat-document aux documents contractuels comme écosystème. Un contrat de fourniture de logiciel sous le nouveau régime ne s’épuise pas dans un document unique valable jusqu’au renouvellement, mais constitue un système de documents corrélés qui comprend le contrat principal, les annexes de niveaux de service, les annexes de sécurité, les accords qualité similaires à ceux du dispositif médical, les accords de traitement des données personnelles au sens de l’Article 28 RGPD, les accords de gestion coordonnée des vulnérabilités, les accords de disclosure réciproque de la chaîne d’approvisionnement. Chacun de ces documents vit avec son propre cycle de mise à jour, et le contrat principal devient le cadre qui les tient ensemble, pas le contenant de toutes les clauses.

La deuxième dimension est la transformation de la clause de limitation de responsabilité. Les clauses traditionnelles qui plafonnent la responsabilité du fournisseur à la valeur annuelle du contrat, ou qui excluent les dommages indirects, restent valables entre les parties signataires mais ne produisent pas d’effets envers les tiers lésés. Pour le fournisseur, cela signifie que l’exposition effective est celle envers le lésé final, pas celle convenue avec le client, et que les polices d’assurance doivent être dimensionnées sur cette exposition effective, pas sur les plafonds contractuels. La pratique assurantielle du secteur est en ce moment confuse, parce que les compagnies redéfinissent les produits pour la responsabilité civile des producteurs de logiciel en fonction du nouveau régime, et les primes augmentent de manière non linéaire. Pour les software houses italiennes de taille moyenne, le coût assurantiel de la responsabilité de produit devient un poste de bilan significatif, là où il y a quelques années il était négligeable.

La troisième dimension est la réécriture des clauses sur la sous-traitance, qui doivent passer d’un modèle dans lequel le client approuve les principaux sous-traitants au moment de la signature à un modèle dans lequel il existe une procédure continue d’évaluation, de monitoring et de disclosure des sous-traitants tout au long de la durée du contrat. Le fournisseur principal doit pouvoir démontrer à tout moment la composition de sa chaîne d’approvisionnement, doit pouvoir produire la SBOM au sens du CRA, doit pouvoir répondre à des demandes d’audit du client ou du régulateur, doit gérer les situations dans lesquelles un sous-traitant sort du marché ou cesse la maintenance d’un composant. Tout cela exige des outils de gestion de la chaîne d’approvisionnement que le modèle contractuel traditionnel tenait pour acquis et qui aujourd’hui deviennent objet d’activité opérationnelle continue.

La quatrième dimension est l’introduction de clauses de gestion coordonnée des vulnérabilités et des incidents de sécurité. Sous le CRA, sous NIS2 et sous DORA pour le financier, le fournisseur et le client ont tous deux des obligations de reporting dans des fenêtres temporelles serrées, et le respect de ces fenêtres exige une coordination que le contrat doit régir de manière opérationnelle, pas seulement formelle. Une clause qui dit « les parties collaborent dans la gestion des incidents » est inutile si elle ne précise pas qui notifie, dans quel délai, par quels canaux, avec quels seuils de gravité. La clause doit être presque un mini-runbook contractuel, et sa qualité se mesure dans la capacité de fonctionner au moment où un incident réel est en cours, pas dans son élégance juridique.

La cinquième dimension est la plus subtile, et concerne la gestion du cycle de vie du produit. Sous le CRA, le producteur doit déclarer la période de support du produit et la maintenir pendant cette période, et doit gérer la sortie du produit du marché de sorte que les utilisateurs soient informés et aient des chemins de transition. Le contrat de fourniture de logiciel doit régir cet aspect, parce que le fournisseur principal est exposé envers le lésé final même après la fin de la relation contractuelle avec le client, et parce que la gestion de l’end of support devient un moment critique où des responsabilités résiduelles peuvent se matérialiser. Les clauses traditionnelles de perpetual licence ou de no warranty after termination ne produisent pas d’effets envers les tiers lésés, ce qui signifie que le fournisseur doit gérer le cycle de vie du produit comme une fonction qui excède la durée du contrat.

Disclosure : dix-huit mois de réécriture

Je dois être transparent sur un point, parce que sur ce sujet je décris des transformations que je vis en première personne. La révision de nos contrats de fourniture, dans l’entreprise où je travaille, est une activité en cours depuis dix-huit mois et n’est pas encore arrivée à une forme stable. Nous travaillons avec notre cabinet d’avocats de référence pour réécrire le contrat de base de fourniture de services logiciels, et ce qui en sort est très loin du contrat propre et élégant que nous espérions produire, et a la forme d’un système de documents plus articulé que le précédent, avec des annexes qui existent pour des raisons différentes et qui ne se réduisent pas à un seul template. Certains clients acceptent la nouvelle structure, d’autres la trouvent inutilement complexe et demandent à revenir au vieux modèle. La pression du marché vers la simplicité contractuelle est encore forte, et dans certains cas nous-mêmes acceptons de signer des contrats du vieux modèle quand le client l’impose, sachant que nous accumulons une exposition rétroactive. C’est un choix que nous faisons pour des raisons commerciales immédiates, et que j’ai appelé exposition composée dans nos conversations internes, parce qu’elle s’accumule de manière non linéaire à mesure que le portefeuille clients grandit.

Une opportunité, pas seulement un fardeau

Je veux aussi dire, parce que sinon le texte ressemblerait à une prévision pessimiste sur l’industrie italienne du logiciel, que la transformation que je décris est une opportunité avant d’être un fardeau. Les software houses italiennes de taille moyenne qui décideront de bâtir des compétences contractuelles cohérentes avec le nouveau régime, d’accompagner le travail de delivery d’un travail continu de maintenance documentaire et de gestion de la chaîne d’approvisionnement, de former à l’interne les figures hybrides que j’ai décrites dans le texte précédent de cette série, auront dans cinq ans une position concurrentielle difficile à éroder. Les software houses qui continueront à signer des contrats traditionnels en espérant que le cadre réglementaire ne s’applique pas vraiment, ou que la jurisprudence nationale l’adoucira, se trouveront exposées et devront combler le retard à des coûts bien supérieurs à ceux soutenables aujourd’hui. C’est une de ces situations où la décision de ne pas décider est la plus coûteuse de toutes, parce que le temps travaille contre qui ne bouge pas, et parce que chaque contrat signé aujourd’hui sous le vieux modèle est un passif qui se révélera dans quelques années, quand les cas que la PLD a dessinés comme scénario standard commenceront à apparaître dans les rubriques des journaux spécialisés.

La centralité qui meurt

En mettant ensemble les quatre textes de cette série, l’argument général que je cherche à construire est le suivant. Le logiciel, comme objet industriel et comme objet juridique, change de nature sous nos yeux, et la culture d’ingénierie et commerciale du secteur ne s’adapte pas à la vitesse que le moment exige. Le premier texte, Cruft, pas patine, soutenait que le logiciel ne sait pas vieillir comme les objets matériels. Le suivant, La dette de spécification, déplaçait l’attention sur le fait que la spécification écrite est devenue l’actif juridiquement pertinent du produit et que notre industrie n’a pas les outils pour la maintenir en vie. Puis est arrivé L’ascension du compliance engineer, consacré à la figure professionnelle hybride qui émerge pour superviser le vide entre l’ingénierie et la régulation. Dans ce quatrième texte, l’argument se déplace du plan du produit et du travail au plan de la relation entre organisations, et la thèse est que le contrat de fourniture, l’instrument juridique classique de cette relation, est en train de devenir un instrument parmi d’autres d’une relation plus large et plus structurée que le droit contractuel traditionnel ne peut que partiellement encadrer.

Le contrat de fourniture de logiciel n’est pas mort, et rien de ce que j’ai écrit ne doit être lu comme une prévision de sa disparition. Ce qui est mort, c’est sa centralité, l’idée que la relation entre fournisseur et client puisse être décrite exhaustivement par un document bilatéral négocié au début du rapport et mis à jour aux renouvellements. La relation contemporaine est une relation multilatérale, chargée réglementairement, dynamiquement exposée à des sujets tiers que le contrat ne lie pas, et traversée par des obligations documentaires continues que le contrat ne peut que résumer. Penser qu’il suffirait d’écrire mieux les clauses est une nostalgie compréhensible et humaine, et c’est aussi le moyen le plus rapide d’accumuler de l’exposition en se croyant protégé. Les clauses servent encore, et même plus qu’avant, mais elles servent comme éléments d’un dispositif plus large qui les contient et les dépasse.

Le contrat, tel que nous l’avons connu, est devenu l’illusion gentille qui permet aux fournisseurs de logiciel de croire qu’ils savent à quoi ils s’exposent. Les contrats traditionnels continueront d’être signés pendant quelques années encore, parce que le marché bouge plus lentement que le droit, et parce que le vieux modèle est familier et que les nouveaux modèles sont encore en formation. Mais qui continue à signer des contrats traditionnels dans les cinq prochaines années signe, en plus du contrat, un pari silencieux sur le fait que les choses ne changeront pas vraiment. C’est un pari que ma génération de ceux qui font du logiciel en Europe perdra probablement, parce que les choses sont déjà en train de changer, et que ce qui aujourd’hui ressemble à un excès de prudence des quelques-uns qui bougent se révélera dans quelques années être le minimum prudentiel qui était requis dès le départ.

L’annonce d’emploi était parue en février sur l’un de ces tableaux où les entreprises italiennes de taille moyenne cherchent des profils techniques sans être trop sûres de ce qu’elles cherchent. L’intitulé du poste était “Senior Software Engineer with Regulatory Background”, et déjà là il y avait quelque chose d’étrange, parce qu’en italien une formule de ce genre ne signifie rien de précis. Le corps de l’annonce clarifiait peu. On demandait au moins cinq ans d’expérience en développement backend, de préférence Java ou Python, la connaissance de Kubernetes, l’expérience des pipelines CI/CD. Jusque-là, un profil de senior developer normal. Puis le texte changeait de registre et commençait à demander une connaissance approfondie du RGPD, la maîtrise de l’AI Act pour les systèmes à haut risque, la capacité à rédiger des AIPD et des évaluations de risque, l’expérience des frameworks de conformité comme ISO 27001 et SOC 2, la capacité à interfacer avec des auditeurs externes. La rémunération indiquée était celle d’un senior developer au prix du marché, avec un petit extra non quantifié pour les compétences réglementaires.

J’ai lu cette annonce une dizaine de fois en cherchant à comprendre qui ils cherchaient vraiment. Une personne pareille, avec cette combinaison de compétences, en Italie aujourd’hui, n’existe pas en nombres significatifs, et quand elle existe, elle coûte le double de ce que l’entreprise offrait. Que l’entreprise le sache ou non, c’est difficile à dire. Ce qui est certain, c’est qu’elle avait un besoin réel, parce qu’elle s’apprêtait à livrer un système à un client régulé, et qu’elle n’avait pas la bonne personne en interne. Elle avait des développeurs senior qui ne savaient pas lire un Règlement européen, un juriste interne qui ne savait pas lire le code, et un consultant compliance externe qui arrivait à parler avec l’un des deux mais pas avec l’autre. La personne qu’elle cherchait existait dans sa tête comme traducteur entre des mondes qui ne se parlaient pas, mais cette personne n’avait pas encore de nom de métier stable.

L’annonce a été republiée en mars sous un titre différent, “Compliance Engineer”, sans autre modification du corps. Puis elle a disparu. Je ne sais pas si l’entreprise a trouvé quelqu’un ou si elle a renoncé. Ce que je sais, c’est que des annonces comme celle-là, avec des variantes minimes, j’en vois passer une ou deux par semaine sur les tableaux italiens, et beaucoup plus sur ceux européens. Je vois un métier en train de chercher son nom, et qui le trouvera dans les deux ou trois prochaines années parce qu’il n’a pas d’alternative.

L’objection technologique

L’objection que je voudrais affronter tout de suite, parce qu’elle est la plus sérieuse de toutes et qu’elle est toujours posée par les C-level qui s’occupent des coûts, c’est l’objection technologique. Elle dit ceci : tout le travail que tu décris, l’IA le fera dans trois ans. Un agent lira le système, lira le règlement, produira la cartographie, mettra à jour la documentation, signalera les incohérences. Pas besoin de construire une nouvelle figure professionnelle, il suffit d’attendre que la technologie mûrisse. C’est une objection qui a une certaine plausibilité apparente, et elle est suffisamment répandue pour mériter une réponse. La réponse, c’est que l’IA fera vraiment quatre-vingt-dix pour cent du travail mécanique, et je ne fais pas ici des prévisions prudentes par excès, je décris ce qu’elle fait déjà aujourd’hui là où elle est appliquée sérieusement. Ce qui reste, les dix pour cent, ne correspondent pas aux dix pour cent résiduels qu’on suppose disparaître à mesure que les modèles s’améliorent. Ce sont les dix pour cent interprétatifs et politiques, et c’est exactement la part qui exige un être humain qui comprenne simultanément l’architecture du système et la structure du règlement, et qui sache choisir comment aligner les deux quand la lettre de la norme et la réalité du logiciel entrent en tension, ce qui arrive bien plus souvent que les régulateurs voudraient l’admettre.

En renversant la perspective, c’est en fait précisément l’IA qui rend la figure du compliance engineer économiquement viable. Sans assistance générative, le volume de documentation exigé par le nouveau régime européen serait ingérable pour quiconque n’est pas une multinationale avec une équipe dédiée de trente personnes. Une software house de dix ou quinze personnes ne peut pas se permettre deux personnes à plein temps sur cette fonction, et de fait aujourd’hui elle ne les a pas. Mais avec une assistance IA bien configurée, une seule personne, bien formée, peut superviser la compliance de tous les projets de l’entreprise avec une qualité qui aurait demandé une petite équipe il y a cinq ans. La question à se poser, donc, n’est pas si l’IA remplacera le compliance engineer, c’est exactement l’inverse. Sans IA, le compliance engineer n’existerait pas comme rôle accessible aux PME, il n’existerait que comme département des grandes entreprises. Avec l’IA, il devient la figure de synthèse qui permet aussi aux organisations de taille moyenne d’opérer sur des marchés régulés sans externaliser leur intelligence normative.

Une distance institutionnelle

La reconstruction des conditions qui ont fait émerger cette figure mérite quelques détails, parce que sa genèse est typiquement italienne et européenne, et comprendre la genèse aide à comprendre pourquoi le métier a la forme qu’il a. Le point de départ, c’est une distance institutionnelle entre deux traditions académiques et professionnelles qui en Italie, plus qu’ailleurs, ne se sont jamais sérieusement rencontrées. D’un côté, l’ingénierie informatique, formée dans les facultés d’ingénierie, avec une attention historique au fonctionnement du logiciel comme objet technique. De l’autre, le droit, formé dans les facultés de droit, avec une attention historique aux normes entendues comme textes à interpréter. Les deux traditions ne se parlent pas, non parce qu’il n’y aurait pas de personnes de bonne volonté qui essaient de bâtir des ponts, mais parce que les programmes de formation ne prévoient pas le pont comme objet d’étude structuré. L’ingénieur sort de l’université en sachant écrire du code et concevoir des systèmes, mais avec une exposition au droit qui se limite, dans les meilleurs cas, à un cours semestriel de droit de l’informatique souvent dispensé par un enseignant qui a étudié le logiciel comme phénomène et non comme pratique. Le juriste sort de l’université en sachant interpréter des normes, mais avec une exposition au logiciel qui se limite, dans les meilleurs cas, à quelques colloques et à quelques manuels de vulgarisation.

Cette distance n’était pas un problème sérieux tant que le logiciel était évalué sur la base de critères fonctionnels, de performance et commerciaux. Quand le logiciel a commencé à être évalué aussi sur des critères normatifs, le problème a explosé, parce que les organisations se sont retrouvées à devoir certifier au régulateur que leur système respectait des obligations que ni leurs développeurs ni leurs juristes ne savaient traduire complètement. Le RGPD, applicable depuis mai 2018, a été le premier test sérieux. Pendant des années, la réponse des entreprises italiennes a été d’externaliser la compliance à des consultants spécialisés, qui produisaient des documents adéquats mais entraient rarement dans le code, ou de nommer un Data Protection Officer interne ou fractionné qui parlait au juridique mais peu à l’ingénierie. Ça fonctionnait mal, mais ça fonctionnait suffisamment, parce que le RGPD seul n’était pas une pression suffisante pour faire émerger une nouvelle figure professionnelle.

La pression nécessaire est arrivée ces trois dernières années avec l’accumulation des actes du paquet réglementaire européen sur le numérique. AI Act, Cyber Resilience Act, révision de la Product Liability Directive, NIS2, Digital Operational Resilience Act pour le secteur financier, Data Act, European Accessibility Act. Chacun de ces règlements, pris individuellement, aurait été gérable avec les méthodes traditionnelles. Pris ensemble, et dans les délais comprimés où ils sont entrés ou sont en train d’entrer en vigueur entre 2024 et 2027, ils ont rendu la situation structurellement différente. Les organisations qui produisent du logiciel pour le marché européen se sont retrouvées avec des obligations documentaires, d’évaluation des risques, de sécurité, de traçabilité, d’accountability, qui se multiplient et s’entrecroisent de manière à exiger une vision intégrée. Le consultant externe qui produit un document à la fois ne suffit pas. Le juriste interne qui ne lit pas le code ne suffit pas. Le développeur senior qui explique le système aux auditeurs deux fois par an ne suffit pas, et la combinaison des trois figures mises à se coordonner par réunions périodiques ne suffit pas non plus, parce que la coordination par réunions périodiques est précisément le dispositif qui génère la dette de spécification. Il faut quelqu’un qui ne fasse que cela, et le fasse tous les jours, à l’intérieur de l’organisation.

Trois tranches dans une seule personne

Sur le plan de la taxonomie des figures professionnelles, ce qui se passe, c’est que le compliance engineer absorbe des tranches de travail aujourd’hui distribuées entre trois rôles distincts. Première tranche, le dev senior qui explique aujourd’hui le système aux auditeurs. C’est une figure qui existe dans presque toutes les organisations d’une certaine taille, et c’est presque toujours un senior qui connaît le système depuis des années et qu’on tire des projets de développement pour faire des présentations à des tiers. Il fait le travail à contrecœur parce que ce n’est pas pour cela qu’il a été embauché, il le fait avec une qualité médiocre parce qu’il n’a pas les outils documentaires pour bien le faire, et il occupe son temps avec des activités qui soustraient de la valeur au rôle principal. Deuxième tranche, l’architecte qui traduit aujourd’hui les exigences réglementaires en choix de design. Cette figure aussi est présente presque partout, et c’est généralement un architecte qui s’est auto-formé sur les règlements parce que quelqu’un devait le faire, et qui le fait dans le temps libre des décisions techniques, avec pour résultat que ses choix de design sont prudents par excès quand les règlements sont ambigus, et qu’il sur-régule souvent le système en générant des frictions opérationnelles inutiles. Troisième tranche, le juriste interne ou le consultant compliance qui essaie aujourd’hui de lire le code sans savoir le lire. C’est la figure la plus frustrée de toutes, parce qu’elle a la responsabilité formelle mais n’a pas les outils techniques pour l’exercer, et finit par demander aux dev des choses que les dev ne savent pas traduire en pratique, générant une boucle communicative qui produit des documents formellement corrects mais substantiellement inertes.

Une journée type

Le compliance engineer prend les trois tranches et les réunit dans une seule personne, avec un temps dédié et des outils dédiés. Une journée type, dans une entreprise moyenne qui produit du logiciel pour des clients régulés, commence par la revue des tickets de la semaine pour identifier les modifications de code qui impactent la compliance. Elle continue avec une session de travail sur une pull request spécifique pour discuter avec le reviewer architectural des effets d’une modification sur les flux de données personnelles. Elle se poursuit avec un appel au juriste interne pour clarifier une clause contractuelle que le client a proposée et qui pourrait entrer en tension avec notre annexe technique de sécurité. Après-midi de travail sur la mise à jour de l’AIPD du projet X, parce que le fournisseur tiers a changé de data center d’hébergement et que cela modifie la cartographie des flux transfrontières. Clôture par une réunion de sprint planning où le compliance engineer présente les exigences de documentation des trois prochaines tâches, pour que l’équipe sache ce qu’elle doit produire en plus du code. Rien de tout cela n’est juridique au sens strict, rien n’est technique au sens strict. Tout est techno-juridique, et c’est la nature hybride du travail qui justifie la figure.

Les deux dégénérescences

Le risque de la figure, et il faut le nommer explicitement parce que c’est le risque principal, c’est qu’elle puisse dégénérer dans deux directions pathologiques toutes deux déjà observables. La première dégénérescence, c’est le compliance engineer comme gate-keeper bureaucratique qui bloque les releases. C’est la version la plus visible et la plus dommageable, parce qu’elle oppose la veille compliance au delivery, et quand cette opposition se stabilise, l’organisation perd à la fois en vitesse et en qualité de compliance. Le gate-keeper produit des checklists toujours plus longues, exige des approbations toujours plus articulées, retarde les releases avec des motifs qui semblent à des développeurs des formalismes, et finit par être perçu comme un coût à minimiser plutôt que comme un investissement à préserver. La seconde dégénérescence, opposée dans les symptômes mais identique à la racine, c’est le compliance engineer comme décorateur de policy qui signe des documents sans lire le code. On voit cela davantage dans les entreprises où la figure est introduite parce qu’un client régulé ou un audit imminent l’exige, et où la fonction est confiée à une personne choisie pour sa disponibilité à supporter des charges documentaires plutôt que pour sa capacité réelle à lire le système. Le décorateur produit des documents parfaits du point de vue formel, remplit tous les champs requis, fait signer le management, et pendant ce temps le système réel évolue dans des directions que le document ne décrit plus. C’est exactement la condition que j’ai appelée dette de spécification dans le texte précédent de cette série, et que le compliance engineer devrait combattre mais qu’il contribue à générer s’il est mal interprété.

Les deux dégénérescences ont une cause commune, c’est l’absence de formation structurée de la figure. Quand le métier n’a pas de parcours académique de référence, chacun se le construit à partir de sa propre provenance. Le développeur qui devient compliance engineer apporte avec lui le préjugé que la compliance est une fonction de service du code, et tend à sous-estimer les conséquences juridiques des choix techniques. Le juriste qui devient compliance engineer apporte avec lui le préjugé inverse, que le code est une fonction de service de la norme, et tend à sur-réguler avec des conséquences techniques et organisationnelles lourdes. Une troisième trajectoire, de plus en plus fréquente, c’est celle du sysadmin qui devient compliance engineer par affinité naturelle avec les pratiques documentaires, et qui tend à construire des pipelines de certification qui vivent parallèles et jamais conjointes au cycle de développement applicatif. Il existe aussi une quatrième trajectoire, plus rare mais plus prometteuse, celle de ceux qui arrivent à la figure par des parcours mixtes, par exemple celles et ceux qui ont travaillé pendant des années en product management sur des produits régulés et ont développé une sensibilité aux deux côtés de la fracture. Aucune des trois premières trajectoires ne produit, à elle seule, un compliance engineer à la hauteur de la tâche. Elles produisent des demi-figures qui fonctionnent dans certaines entreprises et certains contextes, et qui échouent ailleurs.

Une vraie compétence bicéphale

Ce qu’il faudrait, et qui n’existe pas aujourd’hui, c’est un parcours formatif structuré qui parte de l’hypothèse que la discipline est génuinement bicéphale, ingénierique et juridique à la fois, et que les deux moitiés exigent solidité et non superficialité. L’ingénierie logicielle du compliance engineer se distingue de la version simplifiée et généraliste qu’on trouve dans les cours de vulgarisation, et exige de la vraie ingénierie logicielle, avec maîtrise des architectures distribuées, sécurité applicative, cycle de vie du code, pratiques DevOps, modélisation des données. La compliance du compliance engineer, de la même manière, va au-delà de la version opérationnelle et checklist-driven qu’on trouve dans les cours des business schools, et exige de la vraie jurisprudence européenne, avec maîtrise des Règlements, capacité de lecture des considérants, connaissance de la jurisprudence de la Cour de Justice, capacité d’anticiper l’évolution interprétative des Autorités nationales. Une personne qui possède tout cela ne se forme pas dans un master de six mois, elle se forme en quelques années de travail guidé par des mentors sérieux, et les mentors sérieux sont encore peu nombreux.

L’université italienne, de ce point de vue, est structurellement en retard. Les filières d’ingénierie informatique, même les meilleures, consacrent à la compliance réglementaire un nombre d’heures dérisoire par rapport au poids que cette discipline a pris sur le marché. Les filières de droit, même les meilleures, consacrent au logiciel en tant qu’objet régulé un nombre d’heures dérisoire par rapport à la centralité que le logiciel a dans l’économie. Il existe des masters post-universitaires qui essaient de combler le gap, et certains sont bien faits, mais ce sont des masters, c’est-à-dire des formations complémentaires de six ou douze mois qui ne construisent pas la double compétence à partir des fondations, mais la superposent à une compétence préexistante. Le résultat, c’est que les entreprises qui cherchent des compliance engineers ne les trouvent pas formés par le système universitaire et doivent les auto-former en interne, avec les délais et les coûts que cela implique. C’est une distorsion de marché classique, où la demande existe et l’offre ne s’est pas encore consolidée, et qui produit des postes vacants pendant des mois et des rémunérations volatiles.

Les grandes consultancy et le vide

Le segment de marché qui s’est en revanche déjà aperçu du phénomène, et qui se déplace pour l’occuper avant les autres, ce sont les grandes sociétés de conseil. C’est le phénomène le plus visible et le plus ambivalent, et il faut l’évaluer sans moralisme mais avec réalisme. Les grandes consultancy ont la force commerciale, la présence chez les clients corporate, des processus industriels pour le déploiement de figures professionnelles, et des budgets pour produire de la formation interne à des vitesses que les universités ne peuvent pas soutenir. Elles construisent des offres de “compliance as a service” qui empaquettent le travail du compliance engineer en lots vendables au poids. Le problème, et je le dis sans nommer aucun acteur spécifique parce que le problème est catégoriel et non individuel, c’est que la version de la figure que les grandes consultancy construisent est presque toujours la version décorateur de policy. C’est la plus scalable commercialement, la plus facile à vendre, la plus facile à industrialiser. Le compliance engineer comme vrai traducteur techno-juridique, celui qui entre dans le code et modifie les choix architecturaux, ne scale pas bien dans le modèle consulting, parce qu’il exige une continuité chez le client que le modèle par projets typique des grandes consultancy ne fournit pas facilement.

Le vide que les grandes consultancy ne réussiront pas à couvrir, et que les software houses italiennes pourraient en revanche couvrir, c’est celui du compliance engineer interne aux organisations qui produisent du logiciel pour des clients régulés. Les software houses de taille moyenne, entre dix et cinquante personnes, sont structurellement en meilleure position pour construire cette figure, à la fois face aux grandes consultancy et face aux entreprises régulées elles-mêmes. Elles ont la proximité technique au code que les consultancy n’ont pas, elles ont la pluralité de clients que les entreprises régulées n’ont pas, elles ont la taille qui permet de soutenir une personne dédiée sans devoir l’externaliser. Ce que beaucoup de software houses italiennes n’ont pas, et c’est la raison pour laquelle elles ne se déplacent pas assez vite, c’est la conscience que la transformation est déjà en cours et que celle qui la couvre la première obtiendra un avantage de position difficile à éroder dans les cinq années suivantes.

Sur le plan opérationnel, construire un compliance engineer interne signifie investir entre vingt-quatre et trente-six mois sur une personne qui a déjà la moitié des compétences nécessaires. Le candidat type est un développeur senior curieux de la dimension réglementaire, ou bien un architecte sensible aux thèmes de sécurité et de vie privée, ou encore une personne de product management ayant un certain goût pour la formalisation. La trajectoire de croissance prévoit du compagnonnage sur des cas réels, de la lecture systématique des règlements européens dans les versions linguistiques comparées, de la participation à des audits chez les clients, de la rédaction d’AIPD et d’évaluations de risque sous supervision, la construction de repositories documentaires, l’exposition progressive aux juristes internes et aux consultants externes pour absorber le vocabulaire et les pratiques juridiques par osmose. C’est un investissement significatif pour une petite software house, et c’est exactement le type d’investissement qui produit un actif compétitif difficilement reproductible.

Disclosure : une trajectoire que j’habite

Je dois être transparent, parce que sur ce sujet je décris un phénomène dont je fais partie, et l’analyse serait malhonnête si je ne le déclarais pas. La trajectoire que je décris, c’est celle que je vis personnellement dans mon entreprise, et une part non secondaire de mon travail des deux dernières années a consisté à construire le compliance engineer d’Oltrematica, en occupant directement cette position tout en cherchant à la formaliser pour qui viendra ensuite. Je n’écris pas ce texte comme observateur neutre d’une tendance qui serait celle des autres, je l’écris comme quelqu’un qui l’habite de l’intérieur et qui, après quelques années de pratique, a l’impression d’avoir compris la forme que la figure prend, et d’avoir quelque chose à dire sur ce qui fonctionne et ce qui ne fonctionne pas. Je ne suis particulièrement ni heureux ni fier de cette trajectoire. C’est simplement ce que le moment exige de qui veut continuer à faire du logiciel pour des clients régulés sans externaliser sa propre intelligence normative, et je l’ai accepté comme on accepte les tâches de transition, sachant que dans dix ans la figure sera évidente et qu’aujourd’hui c’est à nous de la construire à tâtons.

Connexion, et une prévision

Il y a un lien direct, et il vaut la peine de le rendre explicite, entre la figure que je décris et les deux essais précédents de cette série. Dans le texte que j’ai intitulé Cruft, pas patine, je soutenais que le logiciel ne sait pas vieillir, parce que la dérive entre le code et l’environnement dans lequel il tourne l’érode plus vite que la culture d’ingénierie n’arrive à le métaboliser. Dans le texte suivant, La dette de spécification, je soutenais que la spécification du logiciel vieillit encore plus mal que le code, parce que la pratique continue qui la maintiendrait en vie fait défaut, et que le cadre normatif européen charge ce vieillissement de conséquences juridiques jusque-là inexistantes. Le compliance engineer est la figure dont le métier consiste précisément à combattre la dette de spécification au quotidien, à maintenir la spécification alignée sur le système pendant que le système change, et à le faire avec la double compétence qui permet de ne tomber ni dans le formalisme du document ni dans l’inertie du code. C’est la personne qui, dans une organisation qui produit du logiciel, supervise l’alignement entre la promesse écrite et le comportement observé, sachant que sous le nouveau régime la cohérence entre les deux plans est ce que le juge évaluera si jamais arrive le jour de l’évaluation.

Le texte se ferme sur une prévision qui est aussi un appel à l’action pour qui me lit depuis l’intérieur d’une organisation qui fait du logiciel en Europe. Dans cinq ans, autour de 2031, la figure du compliance engineer sera évidente. Il y aura des filières universitaires, il y aura des certifications sérieuses, il y aura des ordres professionnels sous une forme ou une autre, il y aura des rubriques fixes dans la presse spécialisée. Ce qui reste à comprendre ne concerne pas si cela arrivera, mais seulement à quelle vitesse. Les organisations qui la construisent maintenant, de manière artisanale et par nécessité, auront un avantage structurel sur celles qui attendront la maturation du marché. L’avantage se joue au-delà du plan commercial, il est surtout cognitif, parce que celui qui habite le rôle aujourd’hui définit aussi les pratiques qui deviendront standard, et qui définit les pratiques les définit à la mesure de sa propre manière de travailler.

La figure du compliance engineer n’est pas une niche, c’est le rôle qui redessine la manière dont le logiciel européen est produit sous le nouveau régime réglementaire. Cela arrive lentement, en silence, dans des annonces confuses qui cherchent des personnes qui n’existent pas encore avec des titres qui changent d’un mois à l’autre. Quand les annonces trouveront leur nom stable, et cela arrivera bientôt, l’industrie se divisera entre celles qui auront investi sur cette figure à temps et celles qui se retrouveront à l’importer à marché consolidé en la payant trois fois plus cher. Qui me lit depuis l’intérieur d’une software house italienne de taille moyenne a probablement en entreprise, en ce moment, la bonne personne à former. C’est un dev senior avec la tête tournée vers les règlements, ou un architecte qui a commencé seul à lire le RGPD par curiosité, ou encore un sysadmin qui a pris à cœur la documentation parce que personne d’autre ne s’en occupait, et dans certains cas une figure plus hybride arrivée par des parcours mixtes qui n’entrent dans aucune des trois trajectoires classiques. La reconnaître et lui donner un mandat explicite, en y investissant du temps et une formation structurée, c’est la décision managériale qui produira le plus de valeur composée dans les cinq prochaines années. Pas parce que la figure est à la mode. Parce que sans elle, dans quelques années, faire du logiciel pour des clients régulés en Europe deviendra un métier que les software houses italiennes ne pourront plus se permettre.

Il y a des documents qu’on n’ouvre qu’aux mauvais moments. L’AIPD du système de triage clinique a été signée en avril 2024 et archivée dans le dossier compliance, d’où elle n’est jamais ressortie, comme aucune AIPD ne ressort jamais du dossier compliance. Dix-huit mois plus tard, quelqu’un l’ouvre. Pas un juriste, un consultant venu pour un audit de sécurité, qui l’ouvre par routine, parce qu’il veut vérifier que les mesures déclarées correspondent à celles qui ont été implémentées.

Le document décrit un système qui utilise un modèle de scoring déterministe, entraîné sur un dataset fermé, avec des règles explicites pour la classification du niveau d’urgence. Les finalités du traitement sont au nombre de quatre. Les bases juridiques sont rattachées au considérant correct du Règlement. Les droits des personnes concernées sont énumérés un par un avec les procédures opérationnelles pour les exercer. Les flux transfrontières n’existent pas, parce que tout reste dans le data center européen du fournisseur. Le consultant lit, prend quelques notes, puis lève les yeux et demande au CIO s’il peut voir le système en exécution.

Le système en exécution est un autre. Trois mois après la signature de l’AIPD, le fournisseur a remplacé le modèle déterministe par un classificateur neuronal entraîné en continu sur les six derniers mois de données cliniques. Le dataset n’est plus fermé. Les règles de classification ne sont plus explicites. Les finalités officielles sont toujours quatre, mais une cinquième fonction a été ajoutée à la demande du service des urgences, et c’est une fonction que l’AIPD ne prévoit pas. Les flux transfrontières continuent de ne pas exister jusqu’au jour où ils existent, parce que le fournisseur a changé d’hyperscaler et qu’une partie du trafic passe désormais par un data center irlandais opéré par une filiale américaine. Rien de tout cela n’est documenté ailleurs. Le système fonctionne. Les utilisateurs sont contents. Les audits internes passent parce qu’ils se contentent de vérifier que le système existe et qu’il produit des sorties cohérentes.

Le consultant se tourne vers le CIO et demande qui a autorisé la cinquième fonction. Le CIO répond que c’était une demande urgente du chef des urgences, traitée en une semaine, avec le fournisseur qui a déployé en production le jeudi suivant après un test en staging. Il y a un ticket Jira qui trace la modification, une pull request approuvée par deux reviewers, un changelog interne. Tout est en ordre sur le plan opérationnel. Le consultant demande si l’AIPD a été mise à jour. Le CIO le regarde avec l’expression de quelqu’un qui n’a jamais pensé que c’était nécessaire, parce que l’AIPD appartient à un autre circuit, géré par une autre personne, dans un autre dossier, avec des temps qui n’ont rien à voir avec ceux de la release. Le consultant ferme l’AIPD et ne l’appelle plus AIPD. Il l’appelle spécification fantôme, parce qu’elle décrit un système qui n’existe que sur du papier signé.

Une condition ordinaire

La spécification fantôme, contrairement à ce que l’on croit, est une condition ordinaire. Quiconque a travaillé dans une organisation qui produit du logiciel pour un client régulé, ou pour elle-même sous régime régulé, sait qu’entre le document qui décrit le système et le système réellement en exploitation s’ouvre, après quelques mois, une distance qui croît chaque semaine et que personne n’a mandat de refermer. Pas parce que quelqu’un mente. Parce que le code a un métabolisme que la spécification n’a pas, et parce que le cycle de vie de la spécification, dans le logiciel que nous faisons vraiment, n’est géré par aucun outil comparable à ceux que nous avons pour le code.

L’objection que l’on entend généralement contre ce point est raisonnable, et il faut l’affronter avant d’aller plus loin. L’objection dit : le code est la vraie spécification. La documentation est une projection simplifiée du comportement du système, et elle est en retard par définition, donc la seule stratégie sensée est de tenir le code en ordre et d’accepter que le reste soit de la littérature. C’est le principe du code as documentation dans une version un peu plus sophistiquée, et il a gouverné la culture d’ingénierie du logiciel pendant au moins vingt ans. Cela fonctionnait parce que cela reposait sur un présupposé implicite qui n’est plus vrai aujourd’hui : que le logiciel était jugé sur la base de ce qu’il fait quand il tourne.

Le nouveau statut évaluatif

Le logiciel, sous le régime juridique qui se consolide en Europe entre 2024 et 2027, n’est plus jugé seulement sur la base de ce qu’il fait. Il est jugé sur la base de ce qu’il a promis de faire, et la promesse vit dans la spécification écrite, pas dans le code exécuté. La révision de la Product Liability Directive, adoptée fin 2024 avec transposition due pour le 9 décembre 2026, a inclus explicitement le logiciel dans la notion de produit. Cela signifie que le producteur de logiciel répond des dommages causés par les défauts du produit selon un régime de responsabilité objective. Sur ce point, j’ai déjà écrit il y a quelque temps un billet intitulé La dernière bouteille de Mrs Donoghue, qui revenait au cas fondateur de la responsabilité du producteur dans le droit anglais de 1932 et le projetait sur le logiciel contemporain. Ce que je n’avais qu’esquissé là-bas, et que je veux mettre au point ici, c’est la conséquence épistémologique du nouveau régime. La notion de défaut, sous la responsabilité objective, ne coïncide pas avec le bug. Elle coïncide avec l’écart entre ce que l’on pouvait légitimement attendre du produit et ce que le produit a réellement fait. Les attentes légitimes, faute d’autres paramètres, se reconstruisent à partir de la documentation technique du produit, des déclarations du producteur, des matériaux commerciaux, des exigences de conformité cartographiées dans les évaluations de risque. Elles se reconstruisent, autrement dit, à partir de la spécification.

Le Cyber Resilience Act, pleinement applicable à partir du 11 décembre 2027, fait le même mouvement du côté de la sécurité. La conformité se démontre par la documentation technique du produit numérique, et cette documentation inclut l’évaluation des risques, les mesures de sécurité implémentées, la SBOM à jour, les procédures de gestion des vulnérabilités, le plan de support et les mises à jour pour le cycle de vie du produit. L’AI Act, sur les systèmes à haut risque, exige une documentation technique encore plus étendue, définie par l’Annexe IV, qui inclut la description architecturale du système, les datasets utilisés pour l’entraînement et les procédures de gouvernance des données, les métriques de performance et de précision, le système de gestion des risques prévu par l’Article 9, les procédures de surveillance post-marché. Ce sont des règlements distincts, avec des champs d’application différents, mais avec une structure épistémique identique. Le produit logiciel a changé de statut évaluatif. Il est jugé comme la correspondance entre une promesse écrite et un comportement observé, et quand les deux divergent, le juge ou l’autorité de surveillance regarde la promesse écrite. Pas parce qu’elle croit que la spécification est le système réel. Parce que la spécification écrite est le seul point fixe sur lequel un jugement peut se fonder.

Une petite précision de cadrage est nécessaire ici, pour éviter un malentendu facile. Je ne dis pas que le régime européen transforme la spécification en un objet magique qui vaut indépendamment du système. Le juge ou l’autorité ne se contente pas de lire le document et de déclarer la conformité. Ils confrontent le document au système, évaluent la cohérence, accueillent des expertises techniques. Ce qui change par rapport au régime précédent, c’est que le document cesse d’être une annexe du produit pour devenir une partie constitutive de l’évaluation, sur le même plan que le comportement du système. Quand les deux divergent, le document n’est plus automatiquement écarté comme obsolète. Le producteur doit expliquer pourquoi il a livré un système différent de celui décrit, et cette explication, dans un contentieux, est beaucoup plus coûteuse qu’elle ne l’est aujourd’hui.

Tout pour le code, presque rien pour la spécification

Face à ce déplacement, l’industrie dispose d’un arsenal d’outils pour gérer le cycle de vie du code et de presque rien pour gérer le cycle de vie de la spécification. Le code a le versionnage atomique, et quand une ligne change il y a un commit avec auteur, date et message. Il a le blame, qui permet de remonter à l’origine de chaque décision visible dans le source. Il a les tests, qui échouent automatiquement quand le comportement dévie d’une attente codifiée. Il a les deprecation warnings, qui signalent une promesse en cours de retrait. Il a le refactor sûr, soutenu par des type systems et des suites de régression. Il a la code review, ritualisée dans des pull requests qui laissent une trace. Il a l’intégration continue, qui empêche un changement incompatible d’entrer dans la branche principale sans être vu. Il a les branch protection rules, qui empêchent physiquement de contourner le processus. Il a le rollback en une commande, qui réduit le coût de l’erreur. Chacun de ces outils est le produit d’une pression d’ingénierie accumulée ces trente dernières années, et c’est aujourd’hui de l’infrastructure de la pratique quotidienne, à ce point métabolisée que celui qui entre dans le métier la tient pour acquise et a du mal à imaginer un monde sans.

La spécification a sa version, et c’est tout. Une AIPD est signée, datée, archivée en PDF, et au moment où le système change, aucun mécanisme automatique ne dit au signataire ou au délégué que sa signature couvre désormais un système différent. Les architectures décisionnelles enregistrées dans les ADR s’accumulent dans Confluence, dans Notion, dans des dossiers SharePoint, et personne ne les relit à moins qu’un audit spécifique ne les exige. Les exigences de sécurité jointes aux contrats sont signées, déposées dans le CRM, et à partir de là elles existent comme pièces jointes de back-office jusqu’au renouvellement. Les évaluations de risque produites pour la conformité à l’AI Act sur les systèmes à haut risque demanderont des mises à jour périodiques, mais le mécanisme qui lie la mise à jour aux modifications concrètes du système sera, dans la grande majorité des cas, un calendrier ou un déclencheur contractuel, pas un événement de code. La spécification, contrairement au code, n’a aucune pression interne à rester à jour. Elle survit dans une zone de temps lent où la signature compte plus que la fraîcheur, et où le vieillissement ne se manifeste pas comme dégradation fonctionnelle mais comme éloignement progressif de la réalité que le document est censé décrire.

Les raisons de cette asymétrie sont d’ordre culturel. Techniquement, les outils pour traiter les spécifications avec le même sérieux que le code existent depuis des décennies. Les spécifications exécutables en style BDD, les test specifications écrites en Gherkin, les contrats formels dans des langages comme TLA+ ou Alloy, les spécifications d’interface en OpenAPI ou gRPC, les proof assistants comme Lean ou Coq. Chacun de ces systèmes présuppose que la spécification est un artefact de première classe, exécutable ou vérifiable, vivant dans le repository à côté du code. Dans la pratique industrielle, rien de tout cela n’est la norme. La norme, c’est que la spécification vive dans un document Word, soit relue par quelqu’un du juridique ou de la compliance, soit signée, soit archivée, et qu’à partir de là son destin se sépare de celui du code.

L’origine agile

L’origine de cette séparation est historique et mérite d’être reconstruite avec quelques détails. La culture du logiciel a grandi en opposition à la culture de la documentation, parce que la documentation était perçue comme une imposition du management d’ingénierie de style waterfall, et l’agile a gagné, entre autres raisons, parce qu’il a promis de réduire le poids du document au profit du logiciel qui fonctionne. Le Manifeste Agile, signé à Snowbird en février 2001, dit explicitement « working software over comprehensive documentation ». La formulation était prudente, parce qu’à la fin du document les auteurs écrivaient « while there is value in the items on the right, we value the items on the left more », donc la documentation était redimensionnée, pas abolie. Mais la lecture industrielle des deux décennies suivantes a été plus drastique que la formulation originale. La documentation compréhensive est devenue synonyme de documentation superflue, et les projets qui osaient produire plus qu’un README, quelques commentaires et une poignée de diagrammes étaient soupçonnés de pratiques waterfall résiduelles. La promesse avait du sens dans son contexte, parce que le logiciel qui s’écrivait au début des années deux mille était jugé sur des critères fonctionnels et commerciaux, et le document était effectivement un coût qui produisait peu de valeur informative passé les premières semaines de vie du projet. C’était aussi un coût politique, parce qu’il servait souvent à imposer des processus de gate-keeping qui ralentissaient le travail sans ajouter de qualité.

Ce qui a changé, et que la culture d’ingénierie n’a pas encore métabolisé, c’est le contexte d’évaluation. Le logiciel que nous écrivons aujourd’hui est vendu sur des marchés régulés, intégré dans des chaînes d’approvisionnement qui le traitent comme composant certifié, soumis à des obligations de conformité qui exigent une documentation vivante. Le document a cessé d’être l’outil interne d’une bureaucratie qui veut contrôler les développeurs. Il est devenu l’outil par lequel le produit se présente au régulateur, au client régulé, au juge éventuel. La culture d’ingénierie continue de traiter la spécification comme un sous-produit du processus, alors que le cadre normatif la promeut comme artefact primaire. L’écart entre ces deux perceptions est le terrain où la dette de spécification croît tranquillement.

Spec-driven, BDD, et leurs limites

Il serait malhonnête de prétendre qu’il n’y a pas de tentatives pour combler ce gap, et certaines de ces tentatives sont sérieuses. Le spec-driven development dans la forme qu’il a prise ces deux dernières années, avec des outils comme SpecKit de GitHub et avec la pratique de tenir un CLAUDE.md par projet comme briefing de contexte pour les agents IA, essaie de déplacer le centre de gravité du travail en amont du code. La spécification devient l’input de génération assistée pour un agent qui produit code, tests et documentation d’accompagnement en un seul passage cohérent. La promesse est que la spécification soit exécutable, au sens où elle produit un système, et donc maintenue par la pression de générer du code qui fonctionne. C’est une direction intéressante, et sur les projets où je l’ai appliquée, elle a changé l’économie du travail de manière non triviale. Le temps que je passais à traduire les exigences en code s’est réduit, mais le temps passé à écrire des exigences précises a augmenté, et c’est un trade-off favorable, parce que la précision a une valeur résiduelle même quand le code est réécrit.

La limite que je vois, après quelques mois de pratique, c’est que le spec-driven development résout la synchronisation entre spécification et code au moment de la première génération, et c’est un gain réel, mais ne résout pas la dérive ultérieure. Quand le système entre en production et est modifié en réponse à des demandes des clients, à des incidents, à des changements de l’environnement opérationnel, la spécification formalisée peut être mise à jour ou pas, et les incitations pratiques jouent contre sa mise à jour. Mettre à jour la spécification coûte du temps et de la rigueur, et force une négociation entre celui qui a écrit la modification au vol et celui qui est gardien du document. Sous pression de delivery, le document perd. Le code en production gagne toujours, parce que c’est ce que les utilisateurs utilisent. La spécification redevient un fantôme, même quand elle a été écrite dans un langage formel.

Les spécifications exécutables type BDD ont le même problème, en version atténuée. Une suite Gherkin qui décrit le comportement du système reste synchronisée tant que quelqu’un la fait échouer et la réaligne, mais quand la pression de delivery monte, les scénarios sont sautés, marqués pending, supprimés. J’ai vu des suites de centaines de scénarios se réduire à quelques dizaines en un an et demi, non parce que les comportements décrits avaient disparu du système, mais parce que la suite était devenue une friction que l’équipe n’avait plus le temps de gérer. La spécification exécutable reste plus résistante qu’une AIPD, parce qu’elle est du code et donc soumise aux incitations du code, mais elle n’est pas immune à la dérive. Elle est seulement plus lente à dériver. Et il y a un second problème plus subtil. Les spécifications exécutables couvrent bien le comportement fonctionnel, c’est-à-dire la partie du système qu’on peut vérifier automatiquement. Elles couvrent beaucoup moins la partie du système que la nouvelle compliance européenne demande de documenter, c’est-à-dire l’évaluation des risques, les choix architecturaux, les finalités du traitement, les mesures d’atténuation. Cette partie échappe à l’automatisation, parce qu’elle n’est pas comportementale, et elle reste constitutive du produit comme objet juridique. Aucun framework de test ne vous dit si elle est encore cohérente avec le système.

Sous-catégorie, pas synonyme

On pourrait objecter, à ce stade, que la dette de spécification est déjà incluse dans le concept général de dette technique, et qu’en parler séparément est une manière élégante de redécouvrir la lune. L’objection est formellement correcte. Les taxonomies de la dette technique qui se sont développées dans les deux décennies suivant la formulation originale de Ward Cunningham, en particulier les travaux de Martin Fowler et de ceux qui ont raffiné le quadrant des causes, incluent la documentation obsolète comme une des formes de dette. La distinction que je propose est de nature économique plutôt que conceptuelle. La dette technique classique a des incitations naturelles au remboursement, parce qu’elle vous ralentit, vous irrite chaque jour, vous coûte de l’onboarding et du temps de développement. La dette de spécification a des incitations presque absentes jusqu’à l’arrivée d’un événement déclencheur, et les incitations qu’elle a sont bureaucratiques et calendaires, pas opérationnelles. Cette différence justifie de la traiter comme une sous-catégorie avec ses dynamiques propres, surtout maintenant que le cadre normatif la charge de valeur de manière asymétrique par rapport aux autres formes de dette.

Ce que j’appelle dette de spécification est la version invisible de la dette technique. La dette technique est le prix que vous payez sous forme de lenteur de développement, de bugs récurrents, de difficulté d’onboarding. C’est un prix que vous payez en continu, en petites mensualités, qui vous motive à investir dans le refactoring parce que vous sentez la douleur. La dette de spécification, vous ne la sentez pas. Elle ne ralentit pas le développement, parce que celui qui développe ne lit pas la spécification, et quand il la lit il la trouve souvent utile comme référence historique mais pas contraignante. Elle ne génère pas de bugs, parce que le code est déjà la vraie spécification du point de vue de l’exécution. Elle n’entrave pas l’onboarding, parce que celui qui rejoint l’équipe apprend du code et des collègues, pas des documents archivés. La dette de spécification produit un seul type de dommage, et elle le produit quand un événement vous force à confronter la spécification comme objet contraignant. Un audit de tiers. Un incident de sécurité qui devient affaire judiciaire. Une demande d’accès aux données personnelles à laquelle vous ne savez pas répondre parce que la cartographie des traitements avait été faite sur un système différent. Une contestation d’un client qui a lu le contrat et déclare, avec quelque raison, avoir acheté quelque chose qui ne lui a pas été livré.

Quand cet événement arrive, la dette de spécification devient visible d’un seul coup, et le prix est asymétrique par rapport à la dette technique. La dette technique se paie en mensualités, la dette de spécification se paie en une seule traite, en général plus chère que la somme des mensualités que vous auriez payées en la gérant dans le temps. Il y a aussi une différence de nature dans le coût. La dette technique se paie en temps de développement, et ce temps, vous le contrôlez. La dette de spécification se paie en heures d’avocats, de consultants externes, d’audits extraordinaires, de remèdes imposés, et de réputation, qui est la monnaie la plus chère de toutes parce qu’elle ne se refinance pas. Il y a enfin une différence temporelle que personne ne remarque jusqu’à ce qu’elle vous tombe dessus. La dette technique se paie graduellement, pendant que vous travaillez. La dette de spécification se paie d’un seul coup, pendant que vous faites autre chose, et en général à un moment où vous n’avez pas de marge. Les crises qui la révèlent arrivent toujours au pire moment possible, parce que c’est le moment où quelqu’un d’autre a décidé de regarder ce que vous n’avez pas regardé.

Archéologie et actif

Ces derniers mois, il m’est arrivé de travailler à une évaluation de compliance pour un système de gestion de flux cliniques développé pour un grand hôpital de recherche, et le client du client, c’est-à-dire la fondation clinique finale, avait demandé une annexe de sécurité avec dix domaines de contrôle à cartographier sur l’Article 28 du RGPD et sur une liste d’exigences spécifiques au secteur. La spécification d’origine du système avait été rédigée trois ans plus tôt, à un moment où le système était une plateforme de collecte de données relativement simple. Entre-temps, le système avait grandi, avait acquis des modules de traitement, avait été connecté à des systèmes tiers, avait changé de fournisseur d’hébergement. La distance entre le document de départ et le système actuel était énorme. Le travail que j’ai dû faire pendant six semaines consistait essentiellement à reconstruire la spécification à partir du système, c’est-à-dire à faire du reverse engineering du comportement pour écrire un nouveau document qui soit cohérent avec la réalité.

Le détail opérationnel de ce travail est instructif, parce qu’il raconte ce que veut dire vraiment gérer la dette de spécification quand elle est appelée à comparaître. J’ai dû parler à six personnes différentes, chacune dépositaire d’un fragment de connaissance non documentée. J’ai dû lire le code de trois microservices qui avaient été ajoutés après la signature de l’AIPD. J’ai dû retrouver un fournisseur externe pour lui demander quel algorithme d’anonymisation il appliquait aux données qui passaient par lui, parce que personne dans l’équipe interne ne le savait avec précision. J’ai dû reconstruire le flux des données personnelles entre cinq systèmes différents en regardant les configurations réseau et les logs applicatifs, parce que le diagramme original était devenu inutilisable. Tout ce travail était étranger au développement. C’était de la pure reconstruction d’une vérité documentaire qui aurait dû être maintenue dans le temps et qui devait, au contraire, être réécrite depuis le début. C’était exactement l’opération que le régime normatif présuppose ne jamais devoir être nécessaire, parce que la spécification aurait dû être maintenue tout au long du parcours, et c’était exactement l’opération qui est presque toujours nécessaire, parce que le parcours n’est jamais géré comme cela.

Sur un autre projet, une plateforme d’évaluation du risque juridique pour un cabinet spécialisé, nous avons décidé à un moment donné de migrer tout le stack de Python à Laravel 12. La migration est en cours et nous sommes autour de soixante-dix-huit pour cent du chemin. Ce que j’ai appris dans cette migration, c’est que le vrai actif transféré n’était pas le code, c’était la spécification fonctionnelle. Le code Python a été en grande partie jeté et réécrit, le modèle de données a été redessiné, les choix de framework ont changé radicalement. Ce qui a survécu, c’est la connaissance précise, formalisée dans la documentation produit et dans les contrats avec le client, de ce que le système doit faire, dans quel ordre, avec quelles contraintes, vers quelles interfaces externes. Sans cette spécification, la migration aurait été impossible. Avec cette spécification, et avec une équipe qui la traitait comme référence active pendant le travail, la migration a été difficile mais faisable.

La différence entre ce projet et le cas clinique raconté plus haut est une différence de pratique, pas de nature de la spécification. Dans les deux cas il existait une spécification écrite. Dans le cas clinique la spécification avait été signée puis abandonnée. Dans le cas de la migration la spécification était relue tous les quinze jours en rétrospective, contestée quand l’équipe trouvait des incohérences, modifiée quand un choix de produit changeait, complétée quand une fonction était ajoutée. C’était un objet vivant dans le processus, pas une relique de la compliance. C’est la même distinction qui sépare un manuel de vol que le pilote lit avant chaque décollage du même manuel archivé en bibliothèque. Le même texte, deux fonctions complètement différentes, et deux valeurs opérationnelles non comparables. La spécification comme actif transférable, et la spécification comme actif qui vieillit ou ne vieillit pas selon la manière dont on la traite, sont les deux faces de la même chose.

Les outils que nous n’avons pas encore

Une hypothèse qui me semble raisonnable, c’est que la prochaine décennie de l’ingénierie logicielle sera définie par des outils pour le cycle de vie de la spécification analogues à ceux que la décennie passée a définis pour le cycle de vie du code. Déjà aujourd’hui on commence à voir les premières tentatives sérieuses. Des systèmes de traçabilité qui lient les exigences de la spécification aux tests qui les vérifient, et les tests aux modifications de code qui les touchent, de façon à ce que, quand un test change, le système sache quelle exigence a été impactée et demande la mise à jour du document. Des outils de drift detection sur les architectures, qui comparent la topologie de service déclarée à la topologie observée et signalent les divergences. Le versionnage des AIPD dans des repositories git avec reviews obligatoires à chaque modification structurelle du système. Des spécifications produit qui vivent comme objets versionnés à côté du code, avec une CI qui échoue quand l’écart entre spécification et implémentation dépasse un seuil.

J’essaie d’imaginer à quoi pourrait ressembler la pratique quotidienne dans cinq ans, dans une équipe qui a métabolisé ce tournant. L’AIPD a changé de forme et vit comme fichier YAML dans un repository protégé, avec historique des versions, auteurs des modifications, processus d’approbation par pull request. Quand un développeur introduit un nouveau traitement de données personnelles, une pipeline d’analyse statique sur le code détecte le nouveau flux et marque automatiquement la pull request comme « DPIA-impacting ». Le merge reste bloqué jusqu’à ce que le délégué à la protection des données revoie et approuve la modification correspondante au document de traitement. Les évaluations de risque de l’AI Act suivent un mécanisme analogue, avec des drift detectors qui signalent quand le modèle en production s’écarte des métriques déclarées dans la documentation technique. Les SBOM se mettent à jour automatiquement à chaque build et produisent des diffs lisibles qui entrent dans les changelogs de produit. Tout cela n’élimine pas le travail de compliance, mais le transforme d’archéologie reconstructive, comme celle que j’ai faite pendant six semaines sur le système clinique, en maintenance continue, intégrée au même rythme que le travail de développement. Le saut culturel à faire, c’est de comprendre que documenter le système, sous ce nouveau régime, constitue la construction de l’actif juridiquement pertinent du produit, et pas un coût administratif à minimiser. Qui ne le fait pas maintenant le fera dans cinq ans après avoir perdu un procès, et à ce moment-là ce sera plus cher.

Corps et âme

Il y a quelques mois, sur ce blog, j’ai écrit un texte qui s’appelle Cruft, pas patine, et l’argument principal était que le logiciel ne sait pas vieillir comme les objets matériels, parce que la dérive entre le code et l’environnement dans lequel il tourne l’érode plus vite que la culture d’ingénierie n’arrive à le métaboliser. Il y avait un passage qui parlait d’Unix comme exception, parce que dans Unix la spécification s’est détachée du code et est devenue culture, survivant à travers des cycles de réécriture intégrale du corps. Ce passage se fermait sur une note d’optimisme prudent : la spécification, quand elle se détache, est le plan stable qui traverse le changement.

Je dois nuancer cette note. La spécification se détache du code de deux manières différentes, et la différence entre les deux décide de tout. La première manière, c’est celle d’Unix, où la spécification devient culture partagée, décrite dans des livres canoniques, maintenue par une communauté qui sait l’appliquer à des contextes nouveaux, et qui se renouvelle donc sans perdre son identité. La seconde manière, c’est celle de l’AIPD archivée, où la spécification devient un document signé qu’on ne lit plus, et qui reste donc identique à elle-même pendant que le système devient autre chose. Dans le premier cas, le détachement produit de la continuité. Dans le second, le détachement produit une spécification fantôme. La différence entre les deux manières ne tient pas à la nature de la spécification. Elle tient aux pratiques de qui s’en sert. Une spécification qui est lue, contestée, modifiée, rediscutée, appliquée à des cas nouveaux, est une spécification qui vit. Une spécification qui est écrite, signée, archivée, puis ignorée jusqu’au prochain audit, est une spécification qui meurt lentement pendant que personne ne la regarde.

En mettant les deux essais ensemble, l’argument général que j’essaie de construire est celui-ci. Le logiciel a un double problème avec le temps. D’un côté, le code ne sait pas vieillir, parce que son environnement change trop vite et la dérive le transforme en cruft plutôt qu’en patine. De l’autre côté, la spécification, qui pourrait être le plan stable qui traverse la réécriture du code, n’arrive à l’être que lorsqu’une pratique constante la maintient en vie, et dans la grande majorité des cas cette pratique n’existe pas. Le résultat, c’est que le logiciel, sous le régime juridique qui se consolide en Europe, entre dans une époque où le corps et l’âme du produit sont tous deux fragiles, et où la seule chose qui peut tenir les deux plans ensemble est une discipline de maintenance documentaire que la culture d’ingénierie doit encore construire. La culture d’ingénierie du logiciel n’a pas encore distingué les deux choses avec la clarté nécessaire, parce qu’elle a longtemps traité la spécification comme un sous-produit. Le cadre normatif qui se consolide en Europe la force à faire cette distinction, et le prix des prochaines années sera payé par celui qui ne s’en rendra pas compte à temps.

La dette de spécification, c’est la dette technique qu’on ne voit pas tant que personne ne s’est fait mal. Nous l’accumulons en silence, dans des dossiers SharePoint que personne n’ouvre, dans des PDF signés qui ne sont plus une représentation fidèle des systèmes qu’ils certifient, dans des AIPD déposées sur le serveur de la compliance comme si c’étaient des monuments. Le premier grand procès européen sur la responsabilité du logiciel pour défaut, sous le nouveau régime de la Product Liability Directive, se livrera sur la spécification. Quand il arrivera, et il arrivera bientôt, l’industrie se divisera entre ceux qui auront tenu leur spécification en vie et ceux qui se seront contentés de continuer à la signer.

C’est mercredi après-midi. Vous venez de terminer en vingt minutes une tâche qui, il y a six mois, vous aurait pris une demi-journée. L’écran est immobile. L’après-midi s’ouvre devant vous. Selon toute mesure extérieure, vous devriez ressentir quelque chose qui ressemble au triomphe. Au lieu de cela, il y a une fatigue sourde, injustifiée, dont vous n’arrivez pas à nommer la cause. Les heures gagnées ne se sont pas ajoutées à votre vie. Elles ont seulement rendu la journée étrange.

L’explication par défaut — celle qui dit que nous sommes fatigués parce que nous avons compressé plus de choses dans la même journée — est fausse, ou du moins insuffisante. Beaucoup d’entre nous font moins, en temps d’horloge, et se sentent plus vidés. La fatigue n’est pas quantitative, elle est de tissu. Quelque chose, dans la manière même dont nous habitons la journée de travail, s’est déplacé, et nous n’avons pas encore les mots pour le dire.

Temps de l’horloge, temps vécu, et une troisième chose

Depuis plus d’un siècle, la philosophie distingue deux manières d’habiter le temps. Il y a le temps mathématique, celui des horloges et des emplois du temps, divisible et uniforme. Et il y a le temps vécu, ce que Bergson appelait durée : le temps de l’expérience, dans lequel dix minutes d’attente paraissent plus longues qu’une heure d’immersion. Les deux étaient toujours en tension, mais ils couraient grosso modo en parallèle. Une journée de travail avait huit heures de temps d’horloge et une forme sentie qui leur correspondait à peu près, avec un démarrage lourd et une fin qu’on pouvait anticiper. On savait où on en était dans la journée même sans regarder l’heure.

L’IA introduit une troisième chose qui n’a jamais existé auparavant. L’horloge continue de battre uniformément. L’expérience vécue a encore ses variations. Mais la surface des coûts des activités est devenue sauvagement irrégulière, et pas d’une manière que le corps puisse anticiper. Une tâche qui hier a consommé trois heures en demande vingt aujourd’hui. Une autre tâche, similaire en apparence, en demande encore trois. Il n’y a pas de règle. L’asymétrie est locale, et arrive sans préavis. On passe d’un régime où le travail est ardu à un régime où il est banal, puis à nouveau, plusieurs fois dans le même après-midi, sans signaux qui permettent de s’adapter.

Le corps qui ne lit plus la carte

Le corps s’était calibré, au fil des années, sur une cadence précise. Il savait comment distribuer l’énergie sur une journée, quand pousser et quand ralentir. Cette calibration présupposait une carte relativement stable des coûts des activités : écrire un rapport prenait des heures, répondre à un courriel prenait quelques minutes, et la majeure partie du travail intellectuel se distribuait dans cet intervalle. La carte n’est plus exacte. Le corps continue de faire ses calculs sur des coûts qui ne valent plus, et il y a une dépense silencieuse et persistante d’énergie dans ce recalibrage continu que nous n’arrivons même pas à observer pendant qu’il se produit.

Une fatigue sans forme

C’est une fatigue différente de celles que nous connaissions. Ce n’est pas la fatigue de l’effort. C’est la fatigue du temps sans forme, plus difficile à nommer parce que nous en avons peu d’exemples dans notre histoire. Même les contraintes les plus sévères — la prison, la maladie — tendent à imposer un rythme qui leur est propre, et de fait ceux qui en sortent décrivent souvent l’absence de ce rythme comme l’une des choses les plus désorientantes du retour à la vie libre. Même les loisirs ont un rythme, celui du week-end contre celui des jours ouvrés, celui des repas et des habitudes. Ce dans quoi nous sommes maintenant est autre chose : une journée de travail dont la forme change pendant qu’on la travaille, et qui ne se laisse ramener à aucun motif assez stable pour qu’on puisse s’y déposer.

Ce n’est pas seulement une transition

On pourrait objecter que ce n’est qu’une transition. Donnez du temps au système. Nous apprendrons la nouvelle carte et un nouveau rythme émergera, comme cela s’est toujours passé. Peut-être. Mais l’analogie avec les transitions technologiques précédentes est trompeuse d’une manière qu’il vaut la peine de nommer. L’usine imposait une cadence brutale mais lisible, et en quelques décennies le corps collectif des travailleurs s’est recalibré autour de cette nouvelle forme. L’ordinateur personnel a accéléré certaines tâches mais en a maintenu intacte la phénoménologie interne : écrire restait écrire, sur une surface différente.

Ce qui change maintenant est plus fondamental. L’IA n’accélère pas l’activité, elle la remplace par une autre. Les trente minutes que vous passiez à formuler un paragraphe ne sont pas comprimées en trois minutes de formulation plus rapide. Elles sont remplacées par quatre-vingt-dix secondes pendant lesquelles vous décrivez ce que vous voulez et quelques minutes pendant lesquelles vous éditez ce qui revient. Ce ne sont pas la même activité accélérée. Ce sont des activités différentes, avec des coûts différents et des formes senties différentes. Le corps n’a rien sur quoi se recalibrer, parce qu’aucune nouvelle normalité ne se forme assez longtemps pour devenir lisible.

Les pensées qu’on n’atteint pas

Il y a aussi quelque chose que nous perdons quand le tissu de la journée s’aplatit, et qu’il vaut la peine de regarder en face. La tradition du deep work, même après avoir été happée par une certaine rhétorique de la productivité, désignait quelque chose de réel et de subtil : certains types de pensée n’arrivent que dans des plages uniformes prolongées. Les heures du matin que nous protégions pour la tâche difficile n’étaient pas simplement des heures de qualité supérieure. C’étaient des heures qui rendaient possible la tâche elle-même. Certaines pensées ne s’atteignent qu’après quarante minutes d’attention soutenue, et on ne peut pas y arriver en huit minutes d’attention répétées quatre fois.

Quand le tissu de la journée devient fragmenté et imprévisible, ces pensées simplement ne sont plus atteintes. Nous n’en remarquons pas l’absence directement, parce que ce qui n’est pas pensé ne laisse pas de trace sensible. Nous la remarquons comme une sorte d’amincissement cognitif, un output plus rapide mais d’une certaine manière plus léger, la sensation étrange de produire beaucoup et de penser peu sans arriver à dire en quoi consiste exactement la différence.

Les échafaudages contre l’asymétrie

Je n’ai pas de formule pour quoi faire de tout cela, et je me méfie de qui en a déjà une toute prête. Les réponses du productivity genre — qui suggèrent pour la plupart d’imposer une structure artificielle au nouveau chaos par des agendas blindés et des rituels du matin érigés contre l’asymétrie — peuvent aider dans des cas individuels. Elles n’affrontent pas le phénomène sous-jacent, qui est que la forme naturelle de la journée était une chose réelle, soutenue par les coûts relatifs des activités, et que ces coûts ont changé de manière structurelle. La structure artificielle est un échafaudage qui essaie de tenir debout un édifice dont les fondations se sont déplacées. Elle peut fonctionner un temps, et elle use celui qui la maintient.

Ce que je remarque chez moi, et chez les collègues qui m’en parlent quand il y a assez de confiance pour sortir de la rhétorique de la productivité, c’est que la fatigue est plus aiguë les jours où nous nous sommes le plus efforcés d’utiliser le temps gagné. Le mercredi après-midi où la tâche s’est effondrée en vingt minutes et où nous avons rempli les heures restantes d’autres tâches finit par une fatigue particulière, qui ne vient pas du travail mais de la violence intérieure de prétendre que le temps que nous avons vécu était le temps que nous avons mesuré. Le mercredi après-midi où la tâche s’est effondrée en vingt minutes et où nous nous sommes arrêtés — où nous sommes sortis marcher, ou bien sommes restés à regarder l’étrangeté de l’après-midi sans tenter de la renormaliser — finit autrement. Pas de manière productive, au sens ancien. Mais le corps reconnaît que quelque chose a été honoré, et cette fatigue plus propre est autre chose que la première.

Un nouveau respect pour l’absence de rythme

Peut-être que ce qu’il faut n’est pas un nouveau rythme mais un nouveau respect pour l’absence de rythme, au moins tant qu’elle dure. La vieille journée avait une forme parce que le travail avait une forme parce que les coûts avaient une forme. Rien de tout cela ne revient sous l’habit que nous lui connaissions. Essayer de la reconstruire de force, par des échafaudages toujours plus élaborés, continuera à produire la fatigue diffuse que nous traînons tous sans la nommer. Laisser la journée être la chose étrange qu’elle est devenue, tantôt un sprint, tantôt un creux, pourrait au moins nous rendre l’énergie que nous dépensons dans le projet inutile de prétendre que rien n’a changé. C’est une reddition partielle, certes. Mais certaines redditions sont le prélude à une manière d’être dans les choses que la résistance ne nous aurait jamais accordée.

Ceci n’est pas de l’optimisme. La journée asymétrique pourrait être une journée pire à vivre que celle, structurée, d’avant, et je ne suis pas sûr de la façon dont cela finira. Ce dont je suis sûr, c’est que nommer la fatigue par son vrai nom est la première chose que nous devons à nous-mêmes et à nos collègues : nous ne sommes pas fatigués parce que nous avons fait plus, nous sommes fatigués parce que nous avons vécu dans un temps qui avait perdu sa forme, et nous avons continué à nous comporter comme si la forme était encore là.

« Plus on s’impose de contraintes, plus on se libère des chaînes qui entravent l’esprit. » — Igor Stravinsky, Poétique musicale

Le récit qu’on nous a fait

Un récit s’est installé, ces dernières années, au centre du débat européen sur la technologie. Vous le connaissez tous. Dans sa forme la plus condensée il sonne ainsi : « L’Amérique innove, la Chine copie, l’Europe régule. » C’est une formule qu’on entend en conférence, qu’on lit dans les journaux, qu’on retrouve dans les rapports des think tanks, et qui a trouvé sa consécration dans le rapport Draghi sur la compétitivité européenne — un document honnête et dramatique, qui a désigné la fragmentation réglementaire comme l’une des causes de notre retard structurel.

Il y a un fond de vérité dans ce récit. Le cadre normatif européen est dense. La multiplication des exigences — AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act, NIS2, RGPD, Data Act, DSA, DMA — produit une charge cognitive non triviale pour qui développe du logiciel. De nombreuses PME italiennes peinent, le conseil spécialisé coûte cher, l’outillage mature manque encore.

Mais le récit, comme souvent, est plus intéressant que la version qu’on nous en sert. Parce qu’il existe une autre lecture du même scénario, et c’est celle que je voudrais essayer d’articuler dans ces pages. Une lecture qui ne nie pas les difficultés mais refuse la conclusion apparemment évidente : que régulation et innovation s’opposeraient, et qu’être en Europe signifierait perdre par le seul fait d’y être.

La thèse que je défends est simple dans son noyau, complexe dans ses implications : la conformité réglementaire, correctement comprise, n’est pas un coût de la compétition mais l’un de ses terrains. Et le cadre européen, lu comme un projet technique cohérent, configure un avantage compétitif que les entreprises qui l’ont compris monétisent déjà, tandis que celles qui continuent à le subir comme une nuisance s’excluent progressivement des marchés à plus forte valeur ajoutée.

L’erreur de catégorie

Le premier pas pour désamorcer le faux dilemme « régulation vs innovation » est de reconnaître qu’il s’agit, avant même d’une position discutable, d’une erreur de catégorie.

Quand un architecte conçoit un bâtiment, il travaille à l’intérieur d’un réseau serré de contraintes : lois de la physique, codes parasismiques, règles d’urbanisme, exigences énergétiques, accessibilité, sécurité incendie, contraintes paysagères. Personne, devant un bâtiment bien conçu, ne dit qu’il « aurait été plus innovant sans les lois de la statique ». Ce serait absurde. La gravité n’est pas un frein à l’architecture : c’est la condition qui rend l’architecture possible comme discipline. C’est ce qui distingue construire d’empiler des matériaux.

Il en va de même pour le logiciel. Les constantes, les standards, les protocoles, les spécifications — TCP/IP, ANSI SQL, POSIX, IEEE 754, RFC 7231 — sont des contraintes. Des contraintes très sévères. Et pourtant aucun ingénieur sérieux ne les considère comme des obstacles à l’innovation. Elles sont l’inverse : la grammaire partagée qui rend possible la composition de systèmes complexes à partir de pièces indépendantes. Sans ces contraintes nous n’aurions pas Internet, pas de bases de données, pas d’interopérabilité. Nous aurions un archipel de solutions propriétaires incomparables — exactement ce que la régulation européenne, dans son intention, cherche à éviter pour la prochaine couche de la pile technologique : données, intelligence artificielle, sécurité, accessibilité.

La contrainte, autrement dit, n’est pas l’ennemie du design : elle en est la forme. Schönberg le savait avec le dodécaphonisme, l’Oulipo le savait avec ses algorithmes littéraires, Calvino le savait quand il faisait l’éloge de l’exactitude comme valeur de la littérature, tout développeur expérimenté le sait quand il comprend enfin que les types statiques ne ralentissent pas le développement, ils le structurent. La liberté absolue en ingénierie s’appelle chaos, et produit des systèmes fragiles, incomparables, non maintenables. La liberté disciplinée produit de l’architecture.

Traiter la compliance comme l’adversaire du projet technique signifie qu’on n’a pas compris ce qu’est un projet technique.

Le cadre européen comme système, pas comme liste

Le deuxième pas est de lire le corpus normatif européen de la bonne manière. Presque toute la critique conventionnelle — même celle de bonne foi — fait la même erreur : elle traite les régulations comme une liste. Une liste d’obligations déconnectées, dont chacune ajoute du frottement, dont chacune devrait être évaluée individuellement en termes de coût-bénéfice.

Mais ce n’est pas la forme que le cadre européen a effectivement prise. Si l’on regarde le tissage d’ensemble des régulations de la dernière décennie — du RGPD à l’AI Act, en passant par CRA, PLD, EAA, NIS2, Data Act, DSA, DMA — on découvre qu’il ne s’agit pas d’une liste mais d’un système. Et comme tout système conçu, il a sa logique architecturale.

Cette logique se résume ainsi : rendre responsables, by design, les systèmes techniques qui ont des effets significatifs sur les droits et les biens des personnes. Tout le reste est déclinaison de ce principe.

Le RGPD rend responsables les flux de données personnelles. Le RGPD ne vous dit pas comment concevoir la base de données : il vous dit que vous devez pouvoir répondre — toujours, à quiconque le demande — qui touche aux données de qui, pourquoi, pour combien de temps, sur quelle base juridique. Le Cyber Resilience Act fait la même chose pour la sécurité des produits logiciels : il ne vous dit pas quel langage utiliser, mais il vous demande de savoir et de démontrer ce qu’il y a dans votre produit, de le maintenir sûr dans le temps, de gérer les vulnérabilités par des processus traçables. La Product Liability Directive étend la responsabilité du producteur au logiciel lui-même, en déclarant explicitement qu’un bug peut être un défaut de produit. L’European Accessibility Act étend la responsabilité à l’inclusivité : les produits numériques au-dessus d’un certain seuil de marché doivent être utilisables par tout le monde. NIS2 le fait pour les infrastructures critiques. L’AI Act le fait pour les systèmes qui décident ou influencent significativement les choix humains.

Vue ainsi, la compliance européenne n’est pas une jungle de règles. C’est une grammaire unique, appliquée à des domaines différents : conçois de manière à pouvoir répondre de ce que tu fais, by design. Pas comme rattrapage, pas comme couche de peinture ajoutée. Comme architecture.

Et voici le point souvent ignoré : une fois qu’on a construit une organisation qui pense en termes d’accountability — avec SBOM, avec audit trails, avec threat modeling, avec privacy impact assessments, avec accessibilité testée, avec gestion formalisée des vulnérabilités — la conformité marginale au règlement N+1 devient bien moins coûteuse. La courbe des coûts est l’inverse de celle que la critique naïve imagine : haute au début, décroissante dans le temps, alors que pour qui traite chaque règlement comme une nouvelle urgence la courbe est basse au début mais divergente.

Les organisations qui comprennent cela ne « se conforment » pas. Elles sont conformes, au sens fort : elles ont une forme compatible avec le cadre. Les autres courent après.

L’effet Bruxelles, dix ans après

Il y a aussi une dimension de marché qu’on oublie souvent, et qui à elle seule devrait dissuader quiconque de liquider la régulation européenne comme un boulet.

Anu Bradford, juriste à Columbia, a forgé l’expression Brussels Effect pour décrire un phénomène empirique bien documenté : quand l’Union européenne régule un marché de cette taille — deuxième par PIB nominal, troisième en parité de pouvoir d’achat, en tout cas l’un des trois plus grands au monde — les multinationales tendent à adopter le standard européen comme standard mondial, parce que maintenir deux régimes parallèles coûte plus cher que d’adopter partout le régime le plus strict.

Le cas paradigmatique est le RGPD. Approuvé en 2016, applicable depuis 2018, il est aujourd’hui de facto la base normative qui oriente les politiques de vie privée des principales entreprises tech du monde. On le voit dans les bandeaux cookies partout, dans les dashboards de privacy des big tech, dans le California Consumer Privacy Act (qui en reprend les principes et la structure avec une architecture différente, plus légère, basée sur l’opt-out), dans les lois brésilienne, sud-africaine, indienne. Près de huit ans après l’application, on peut dire avec une certitude raisonnable : la grammaire de la vie privée mondiale parle européen.

L’AI Act semble engagé sur la même trajectoire. Pas parce qu’il est parfait — il ne l’est pas — mais parce qu’il est le premier cadre normatif horizontal et organique au monde pour les systèmes d’intelligence artificielle. La Chine est arrivée la première, en 2023, avec des règles contraignantes sur l’IA générative : mais ce sont des règles sectorielles, avec une emphase différente — étiquetage obligatoire, enregistrement auprès de l’autorité, vérification de l’identité des utilisateurs, contrôle des contenus — plus orientées vers la stabilité informationnelle que vers la protection des droits fondamentaux. L’AI Act a été le premier à tenter une architecture générale, par niveaux de risque, applicable à tous les systèmes d’IA dans tous les secteurs. Les grandes entreprises de l’IA structurent déjà leurs processus internes en fonction des exigences européennes. Aux États-Unis, dans un mouvement que peu auraient anticipé, la régulation au niveau des États reprend — surtout au Colorado, avec des échos en Californie et dans quelques lois locales de New York — la logique de catégorisation par risque, même si le parcours n’est pas linéaire : le Colorado AI Act, initialement en vigueur dès 2026, a été reporté et est en cours de retravail au moment où j’écris.

Pour une entreprise européenne qui conçoit du logiciel, cela signifie une chose très concrète : vous travaillez déjà à l’intérieur du standard qui, statistiquement, sera le standard mondial dans cinq ans. Vos concurrents américains et asiatiques devront s’adapter à un cadre que vous avez déjà métabolisé. Ce n’est pas un détail : c’est la définition opérationnelle de l’avantage du first mover.

On objectera : mais si l’effet Bruxelles est si puissant, pourquoi les entreprises européennes peinent-elles ? La réponse demande de l’honnêteté. Parce que beaucoup d’entreprises européennes n’ont pas effectivement métabolisé le cadre : elles le subissent. Elles traitent le RGPD comme une nuisance à minimiser, l’AI Act comme une inconnue à reporter, l’EAA comme quelque chose à faire quand l’inspection arrive. Elles paient deux fois ainsi : le coût de la conformité (qui, mal gérée, est élevé) et l’occasion manquée de transformer cette conformité en positionnement. Pendant ce temps, les entreprises non européennes, contraintes de se conformer pour accéder au marché, le font structurellement — et l’avantage compétitif qui aurait pu être le nôtre devient le leur.

L’effet Bruxelles est une flèche qui vole vers la cible. C’est à nous de décider si la cible est nous ou les autres.

L’asymétrie qui décide

Venons-en au cœur de l’argument, sa partie opérationnelle. Il existe une asymétrie fondamentale entre deux types d’entreprises qui opèrent sur le marché européen, et cette asymétrie — silencieuse, cumulative, aujourd’hui à peine perceptible, demain décisive — déterminera qui gagne et qui sort des segments à plus forte valeur.

Le premier type traite la compliance comme formalité. C’est la position par défaut, et parfaitement compréhensible : le règlement arrive, on nomme un responsable, on remplit des checklists, on produit des documents, on met à jour la politique de vie privée, on ajoute des bandeaux, on commande des évaluations quand il faut. La compliance est un coût à minimiser, une activité défensive, quelque chose qu’on fait pour ne pas prendre de sanctions. C’est une activité qu’on externalise dès que possible : mieux vaut un consultant à la demande qu’un processus interne structuré.

Le deuxième type traite la compliance comme architecture. La différence, c’est que les exigences réglementaires ne sont pas affrontées au moment de leur applicabilité, mais prises comme contraintes de projet dès le départ. Le SBOM n’est pas un document à produire ex post : c’est un artefact généré par le pipeline CI/CD à chaque build. La vie privée n’est pas une checklist à remplir : c’est une dimension du modèle de données. L’accessibilité n’est pas une vérification finale : c’est un set de composants UI qui la garantissent. La sécurité n’est pas un audit annuel : c’est un threat model révisé à chaque modification architecturale significative. L’AI accountability n’est pas une réponse à une inspection : c’est une série de tests, de documentation d’entraînement, de suites d’évaluation.

Pour un observateur extérieur, pendant les deux ou trois premières années, la différence entre les deux types se voit peu. Au contraire, le premier paraît plus efficace : il sort les mêmes produits avec moins d’overhead. Le second investit dans des choses qu’on ne voit pas encore : pipelines, frameworks, processus, formation, documentation structurée.

Puis quelque chose change. Cela change quand le marché pertinent devient la santé, l’administration publique, la finance, l’énergie, les infrastructures critiques — c’est-à-dire les segments où les clients ont leur propre exposition réglementaire, et où leur conformité dépend de celle de leurs fournisseurs. À ce moment-là, il se passe une chose que tout le monde dans le B2B régulé a déjà vu : l’appel d’offres arrive avec une annexe technique de trente pages, et l’entreprise « formalité » découvre que beaucoup des exigences ne sont pas incrémentales mais structurelles. SBOM complet pour chaque composant. Traçabilité des vulnérabilités avec SLA de remédiation. Processus SDLC documentés et audités. Pen tests annuels avec remédiation traçable. Politiques de backup, disaster recovery, business continuity testées. Privacy by design démontrable pour chaque flux. Accessibilité vérifiée. Auditabilité des modèles d’IA utilisés, le cas échéant.

L’entreprise « formalité » a deux options : soit elle se transforme en entreprise « architecture » — en investissant soudainement, sous pression, dans tout ce qu’elle n’avait pas construit — soit elle se retire. Se transformer sous pression coûte cher, est lent, et n’est jamais propre : cela produit une documentation approximative, des processus qui survivent au mieux jusqu’au renouvellement du contrat, des fragilités qui émergent au premier audit sérieux. Se retirer, c’est descendre d’un cran de marché.

L’entreprise « architecture » participe, gagne, et — c’est le point — gagne avec des marges supérieures, parce que dans ces segments le pricing récompense la démontrabilité, pas seulement les fonctionnalités.

Je décris, comme cela devrait être clair, quelque chose que je vis en première personne. Ces trois dernières années, j’ai vu des projets de santé où le discriminant n’était ni le prix ni la feature parity mais la capacité à produire, dans les délais, une documentation de gouvernance, sécurité et accessibilité cohérente avec les exigences du commanditaire. J’ai vu des appels d’offres de l’administration publique où la qualification ACN était un portail, et où l’absence d’un fournisseur qualifié se traduisait en exclusion mécanique. J’ai vu des négociations où une annexe technique de sécurité a redéfini de zéro l’axe du dialogue : non plus « que fait votre produit » mais « comment démontrez-vous que vous saurez le gérer dans la durée ».

La compliance, dans ces contextes, n’est pas la nuisance finale de la négociation. Elle est le terrain de la négociation.

La confiance comme produit

Il y a une formulation qui me semble utile : dans le B2B régulé, on ne vend pas des fonctionnalités, on vend de la confiance documentée.

Les fonctionnalités comptent, évidemment. Mais les fonctionnalités deviennent une commodity plus vite qu’on ne le pense. Tous les CRM se ressemblent. Tous les LMS se ressemblent. Toutes les plateformes de télémétrie se ressemblent. Les différences sont incrémentales, et au-delà d’un certain niveau elles cessent d’être le discriminant d’achat. Devient discriminant ce qui n’est pas une fonctionnalité : la capacité à signer un contrat avec des clauses de responsabilité précises, à passer un audit, à garantir la continuité opérationnelle, à documenter sa supply chain logicielle, à répondre en 24 heures à une demande d’exercice des droits, à démontrer la non-discrimination d’un système de décision, à maintenir ses produits accessibles pendant des années.

Aucune de ces choses n’est une fonctionnalité au sens classique. Ce sont des capacités organisationnelles démontrables. Et ce sont exactement celles que le cadre normatif européen oblige à construire.

C’est là, à mon sens, que se trouve l’inversion conceptuelle fondamentale. Pour une entreprise qui vit la compliance comme formalité, la documentation est un sous-produit : la chose qu’on produit pour que les inspecteurs soient contents. Pour une entreprise qui vit la compliance comme architecture, la documentation est le produit — ou plutôt en est une partie constitutive, parce que ce qu’on vend n’est pas le logiciel mais la capacité organisée à le gérer dans le temps, et cette capacité est démontrable uniquement par voie documentaire.

On comprend, depuis cet angle, pourquoi le SBOM n’est pas de la paperasse : c’est le manifeste de la chaîne d’approvisionnement de votre logiciel, et c’est ce qui permet au client de gérer sa propre exposition. On comprend pourquoi l’audit log n’est pas un coût : c’est une propriété de fiabilité que le client achètera de toute façon, et qui deviendra obligatoire sous peu. On comprend pourquoi un rapport d’accessibilité conforme à la norme EN 301 549 n’est pas une formalité : c’est ce qui permet au client public de gagner son propre appel d’offres, et donc ce qui fait de vous un fournisseur préféré.

Quand on vend de la confiance, la documentation est le produit, et la conformité est le manuel de fonctionnement du produit.

L’objection honnête

Il serait malhonnête de présenter cette lecture sans reconnaître les objections sérieuses. Il y en a au moins trois, et elles méritent d’être prises au sérieux.

La première est celle de la disproportion. La charge réglementaire qui pèse aujourd’hui sur une software house de dix personnes est objectivement très proche de celle qui pèse sur une grande entreprise. Pas en termes absolus — il existe des seuils et des exemptions — mais structurellement : les processus requis pour être véritablement conforme au CRA, à l’AI Act, au RGPD sont par endroits les mêmes que ceux d’une multinationale, simplement avec moins de monde pour les faire tourner. Cette disproportion est réelle, et c’est la raison principale pour laquelle de nombreuses PME européennes peinent. C’est un problème sérieux, qui demande à Bruxelles de mieux travailler la proportionnalité, les régimes simplifiés pour les PME, la disponibilité d’outils de compliance accessibles. Ce n’est cependant pas un argument contre la compliance en soi : c’est un argument pour mieux la mettre en œuvre.

La deuxième objection est celle de l’hétérogénéité de mise en œuvre. Le règlement européen, une fois entré dans les ordres juridiques nationaux, est décliné de manières qui varient d’un pays à l’autre — autorités compétentes, schémas de certification, outils de surveillance, seuils. Cette hétérogénéité est effectivement un coût, surtout pour qui travaille en transfrontalier. C’est une faiblesse spécifiquement européenne, liée à notre histoire institutionnelle, et elle ne se résout pas facilement. Mais — et c’est le point — ce n’est pas une faiblesse de la compliance : c’est une faiblesse de l’intégration du marché unique. Deux problèmes différents. Liquider la régulation européenne parce qu’elle s’applique de manière non uniforme, c’est un peu comme liquider l’idée de langue parce qu’il existe des dialectes.

La troisième objection est la plus intéressante, et mérite la réponse la plus articulée. C’est l’objection du time-to-market : si nos concurrents américains n’ont pas à faire de l’AI Act compliance, et nous oui, ils arrivent les premiers sur le marché. Cette objection se heurte à l’effet Bruxelles sans toutefois l’annuler complètement : il existe une fenêtre réelle où l’asymétrie de contrainte produit une asymétrie de vitesse. Le point, cependant, c’est que cette fenêtre s’applique à un sous-ensemble spécifique de produits — ceux qui visent le mass market consumer, où le time-to-market l’emporte souvent sur la solidité — et non à ceux qui visent les segments régulés. Pour qui vend à des hôpitaux, des banques, l’administration publique, les infrastructures critiques, la vitesse n’est presque jamais le discriminant : c’est la robustesse démontrable. Et là, le cadre européen est un avantage, pas un handicap. Il existe des entreprises européennes qui gagnent dans le B2B régulé précisément parce que le produit américain arrive sans la documentation, sans les processus, sans la culture — et doit être reconstruit sous pression pour passer les audits. Reconstruire sous pression coûte cher : leurs marges descendent, les nôtres montent.

Les trois objections, en résumé, ont un fond de vérité mais aucune ne justifie la conclusion catastrophiste qui les accompagne souvent. La bonne réponse est : mettre en œuvre la compliance mieux, pas la refuser.

Ce que fait une organisation conforme by design

Jusqu’ici le niveau conceptuel. Je voudrais conclure avec quelque chose de plus opérationnel, car un essai sur la compliance qui ne descend pas dans les détails risque d’être apprécié puis oublié.

Une organisation qui a transformé la compliance en avantage compétitif, dans mon expérience, a ces traits.

Elle a un seul modèle d’accountability qui traverse le cycle de vie du logiciel. Pas un modèle pour la sécurité, un pour la vie privée, un pour l’accessibilité, un pour l’IA : un modèle unique, avec des déclinaisons spécifiques, où toutes les exigences convergent dans les mêmes pipelines et la même documentation. Le SBOM, l’AIPD, le threat model, l’enregistrement des tests d’accessibilité, la model card vivent dans le même repository, sont versionnés, sont mis à jour à chaque release, sont liables depuis n’importe où ailleurs dans l’organisation.

Elle a l’automatisation de l’artefact de compliance. La génération de SBOM, de SPDX, de license reports, de vulnerability reports, de scans d’accessibilité, de model evaluation reports est automatique. Ce n’est pas quelque chose que quelqu’un produit à la main en vue d’un audit : c’est quelque chose que le pipeline produit à chaque build, avec timestamp et commit de référence. Le résultat, c’est que lorsqu’une demande client arrive, la réponse est disponible en minutes, pas en semaines.

Elle a les contrats comme spécifications. Les contrats avec les clients — surtout en santé et dans l’administration publique — ne sont pas des textes juridiques disjoints du travail technique, mais des spécifications techniques qui vivent dans le backlog. Les clauses de sécurité sont mappées sur des requirements, les requirements sur des tests, les tests sur des pipelines. Quand un client demande de certifier la conformité à une clause, la réponse n’est pas « demandons au consultant » : c’est une requête dans son propre système.

Elle a une compétence juridique internalisée. Cela ne veut pas dire avoir un avocat à l’organigramme. Cela veut dire que les tech leads connaissent les règlements qui s’appliquent à leur domaine, en comprennent la logique, savent traduire leurs exigences en choix architecturaux. Le consultant externe est une ressource pour les cas spécialisés, pas le propriétaire de la compliance.

Elle a une culture du trade-off explicite. Elle sait quand une exigence de compliance impose un coût, le déclare, en débat, prend des décisions motivées. Elle ne fait pas semblant que la compliance est gratuite. Elle ne fait pas semblant qu’elle est impossible. Elle la traite comme l’une des contraintes du projet, à équilibrer avec les autres.

Et, surtout, elle a un récit commercial fondé sur la conformité. Elle sait raconter aux clients pourquoi son produit est meilleur, et ce « pourquoi » inclut — à côté des fonctionnalités — la structure de fiabilité documentée. Elle sait que le client santé, le client administration publique, le client banque achètent exactement cela : la garantie qu’à trois ans, à cinq ans, devant une inspection, devant un incident, devant un changement réglementaire, vous serez encore un fournisseur solide. Ce n’est pas une concession au marketing : c’est le produit.

La signature civique de l’Europe

Je voudrais conclure en sortant du terrain opérationnel pour revenir au conceptuel, car il y a une dimension supplémentaire — civique, presque politique — qui mérite d’être nommée.

L’Europe, en tant que projet, est une expérience historique singulière : une union d’États qui ont décidé, après les catastrophes du XXᵉ siècle, de mettre en commun la souveraineté en échange de règles. Ce n’est pas une union de force : c’est une union de normes. Notre richesse symbolique, notre capacité à projeter des valeurs, notre crédibilité internationale dépendent en grande partie de l’idée que nous, les règles, nous les faisons, nous les respectons et nous les appliquons à nous-mêmes. Quand nous les exportons, nous ne le faisons pas par la force mais par le marché.

Ce que nous faisons dans le numérique est exactement cela : transposer dans le cyberspace notre signature civique. L’idée, scandaleuse pour une partie du monde, que la technologie doit répondre à ceux qui la subissent, pas seulement à ceux qui la produisent. Que les effets des systèmes techniques sur les individus ne sont pas une externalité mais un objet légitime de régulation. Que l’innovation qui produit des dommages non réparés, des exclusions non remédiées, des opacités non explicables, n’est pas de l’innovation : c’est un transfert de coûts du producteur au citoyen, déguisé en progrès.

On peut ne pas partager cette vision. Il existe des systèmes juridiques qui ont fait d’autres choix, et nous les respectons. Mais soutenir — comme certains parmi nous le font encore — que notre vision serait un frein, et que le vrai progrès serait ailleurs, signifie n’avoir pas compris à quel jeu nous jouons. Le jeu n’est pas qui arrive le premier sur le marché consumer avec un nouveau gadget. Le jeu est qui définit la grammaire à l’intérieur de laquelle les systèmes techniques opéreront pendant les cinquante prochaines années. Le RGPD est déjà la grammaire de la vie privée mondiale. L’AI Act est en train de devenir la grammaire de l’accountability algorithmique mondiale. Le CRA est en train de devenir la grammaire de la sécurité des produits logiciels mondiale.

Pour qui conçoit du logiciel en Europe, participer à ce jeu est un privilège que nous payons d’un coût spécifique — le coût de construire en premier — mais c’est aussi, précisément pour cela, notre principal avantage compétitif structurel. Qui reste à l’extérieur, à l’intérieur même de l’Europe, parce qu’il trouve le cadre embêtant, fait un calcul à courte vue : il se soustrait au seul avantage que nous avons, pour poursuivre un modèle de compétition — celui du pur time-to-market — où nous ne pouvons pas gagner de toute façon, parce que nous n’avons pas la masse de capital de ceux qui le définissent.

La conformité, correctement comprise, n’est pas notre fardeau. Elle est notre forme. Notre forme de construire, notre forme de faire des affaires, notre forme de projeter des valeurs. La traiter comme un boulet, c’est, pour un musicien, traiter l’armure comme une nuisance. On peut le faire, certes. Mais on joue autre chose, et on joue moins bien.

La contrainte, encore une fois, est forme. Et la forme, pour qui sait l’habiter, est un avantage.

Ce n’est que quelques jours plus tard, en le relisant calmement à mon bureau, que j’ai compris ce qui me dérangeait. Le template n’était pas une version plus détaillée du précédent. C’était autre chose. Pas un formulaire amélioré, pas une grille plus fine : le document que j’avais en main exigeait quelque chose de différent de qui le remplit, et plus subtilement quelque chose de différent aussi de qui le lit. L’AIPD cessait d’être un formulaire et devenait, pour reprendre un terme que j’ai passé mes années universitaires à ruminer, un genre.

Ce qui est arrivé, et ce qui ne l’est pas

Précisons d’abord. L’EDPB a adopté le template en version 1.0 par procédure écrite le 10 mars, l’a rendu public en avril avec un explainer accompagnant chaque section, et l’a ouvert à consultation publique jusqu’au 9 juin. L’usage du template n’est pas obligatoire : les responsables peuvent continuer à utiliser les méthodologies AIPD qu’ils préfèrent. Après la consultation, et avec d’éventuelles modifications, toutes les autorités nationales lanceront les démarches pour l’adopter comme standard propre ou comme méta-template auquel les modèles nationaux devront se conformer. Rien n’est encore fermé, mais tout prend forme ; et la forme qui prend corps est exactement le cœur de ce que je veux discuter ici.

Je sais devoir argumenter contre l’intuition courante. La majorité des gens qui travaillent sur l’AIPD la considèrent comme une corvée bureaucratique, une charge à liquider, une feuille que le juriste remplit et que le client archive. En Italie, où la compliance a longtemps gardé un profil défensif, l’AIPD a souvent été écrite pour ne pas être lue, et lue pour ne pas être discutée. La question « de quoi as-tu vraiment besoin dans une AIPD bien faite » reçoit en général des réponses pratiques : qu’elle soit complète, qu’elle couvre les cas d’usage, qu’elle ne contredise pas d’autres documents, qu’elle survive à un contrôle. Réponses honnêtes. Mais à mon sens, fausses, ou plutôt : ce sont les réponses qu’on donnerait si l’AIPD était vraiment un formulaire. Et c’est précisément ce que, jusqu’à il y a quelques semaines, l’AIPD était encore, du moins dans une grande partie de la pratique italienne. Un document sans auteur, au sens le plus faible du mot : quelqu’un le signait, certes, mais personne n’en assumait la responsabilité au sens éditorial.

Un template n’est pas un formulaire

Mais voici le point. Un template n’est pas un formulaire. Un template, à l’instant où il est proposé par une autorité comme l’EDPB avec l’ambition explicite de devenir le standard commun européen, cesse d’être un outil de remplissage et devient quelque chose de plus étrange et plus puissant : la codification d’une forme. Et une forme ne se remplit pas. Une forme s’écrit, en ayant à l’esprit qu’on est lu dans des attentes spécifiques, avec un lexique, une structure narrative, un rythme rhétorique non interchangeables. Cela, en peu de mots, c’est un genre.

Pour comprendre l’importance du passage, il faut prendre du recul. L’AIPD existe formellement depuis 2018, prévue par l’article 35 du RGPD comme évaluation obligatoire pour les traitements à haut risque. Les premières années ont été gérées comme elles ont pu l’être : chaque organisation, chaque cabinet, chaque DPO a produit sa version, avec une variabilité que qui a travaillé en cross-secteur connaît bien. Certaines AIPD étaient des documents de cinq pages qui ressemblaient à un compte rendu de réunion ; d’autres des tomes de cent pages qui ressemblaient à des thèses de doctorat. Certaines avec matrices de risque numériques héritées de cadres de sécurité, d’autres en prose juridique fournie de renvois normatifs, d’autres encore avec des approches hybrides mêlant les deux cultures sans réussir à les faire vraiment cohabiter. La Commission avait suggéré des schémas, le WP29 puis l’EDPB avaient publié des lignes directrices, certaines autorités nationales mis à disposition des modèles plus structurés, mais le paysage restait fragmenté. L’AIPD était dans cet état de chose jeune où les formes ne sont pas encore décantées, où chacun essaie sa voie et peu de ces voies se rencontrent. Les autorités européennes s’étaient plaintes à plusieurs reprises de cette hétérogénéité, qui rendait difficile la construction d’une jurisprudence implicite partagée — celle qui se construit en lisant des centaines de documents écrits selon une forme reconnaissable.

Quand une forme prend corps

Le template EDPB ouvre la fermeture de cette phase. Pas avec l’autorité formelle d’un règlement contraignant — qu’il n’est pas —, mais avec quelque chose qui ressemble à l’autorité qu’une grammaire normative exerce sur une langue vivante : il indique, oriente, crée un centre de gravité. À partir de maintenant, qui écrit une AIPD en Europe sait qu’il existe une forme proposée au niveau supranational, et sait que quand le processus de consultation se sera fermé et que les autorités nationales auront fait leurs pas d’adoption, toute déviation de cette forme devra être justifiée. C’est exactement, dans l’histoire des langues et des genres littéraires, le mouvement par lequel une forme prend corps. Avant Dante, le toscan florentin était l’un des nombreux vulgaires italiens ; après lui, chaque usage du toscan se mesurait à lui, même quand on voulait s’en éloigner. Le rapprochement avec Dante est disproportionné par rapport à un template bureaucratique, je le sais. Je le laisse parce que le mécanisme est le même, même si les hauteurs sont incomparables. Quand une autorité propose une forme et que toutes les autorités sous-jacentes annoncent l’adopter, cette forme cesse d’être une possibilité parmi d’autres et devient le fond sur lequel toutes les autres se découpent.

Architexte et auto-inquisition

Les spécialistes de littérature appellent ce phénomène la stabilisation d’un architexte, terme que je dois à Genette mais qui circulait déjà chez Bakhtine sous le nom de genres du discours secondaires. L’architexte n’est pas une œuvre singulière : c’est l’ensemble des attentes formelles qu’un lecteur emporte en ouvrant un certain type de document. Quand j’ouvre un polar, je sais qu’il y aura un crime à résoudre ; quand j’ouvre un article scientifique, je sais qu’il y aura une section méthodologique ; quand j’ouvre un sonnet, je compte les lignes avant même de les lire. Un architexte stabilisé produit des attentes stabilisées. Et il produit, inévitablement, une forme d’écriture qui sait être lue dans ces attentes. Hans Robert Jauss, à partir de 1970, appelait horizon d’attente cette posture du lecteur qui rencontre un texte dans un cadre de genre déjà connu. Tout texte, pour Jauss, se lit toujours deux fois : une fois contre le cadre que le lecteur emporte, une fois en remodelant ce cadre selon ce que le texte dit effectivement. Une AIPD écrite dans le template EDPB, devenu standard de référence, sera lue ainsi : l’auditeur ou l’inspecteur saura déjà quoi chercher, dans quelle section, et reconnaîtra immédiatement quand le texte s’écarte de la forme attendue, et construira son jugement à partir de cet écart.

Il y a un second filon théorique à invoquer, parce qu’il éclaire le point dans une autre direction. Carlo Ginzburg, dans ses travaux sur les procès inquisitoriaux frioulans des XVIᵉ et XVIIᵉ siècles, a montré comment les procès-verbaux étaient un véritable genre documentaire, avec des conventions rhétoriques précises, un rapport codifié entre interrogateur et interrogé, une gestion particulière de la voix entre discours direct et indirect, une structure narrative traduisant la voix de l’accusé dans le cadre processuel de l’inquisiteur. Ginzburg lisait ces procès-verbaux comme des textes, pas comme de pures transcriptions, et y trouvait les traces d’une subjectivité populaire autrement invisible. Au-delà du parallèle historique, une analogie structurelle me frappe. L’AIPD est, dans son architecture profonde, un document auto-inquisitorial : le responsable du traitement s’interroge sur ses propres actes, reconstruit les raisons de ses choix, argumente devant un lecteur absent mais menaçant (l’autorité) pourquoi ces choix sont adéquats. Une forme de discours qui expose sa propre rationalité pour qu’elle soit jugée. Le fait qu’elle ait désormais un template destiné à devenir genre codifié signifie, entre autres, que cette auto-inquisition s’apprête à avoir une grammaire. Et les grammaires, comme le savent ceux qui les ont sérieusement étudiées, ne sont pas neutres : elles modèlent ce qui peut être dit, et indirectement ce qui peut être pensé.

La fenêtre du canon

Qui écrit une AIPD dans les prochains mois est dans une condition particulière, différente à la fois de celle du pionnier et de celle du compileur dans un genre mature. Le template est sur la table mais n’est pas encore standard, la consultation est ouverte, les autorités nationales préparent leurs étapes de transposition. Qui écrit une AIPD dans cette fenêtre écrit dans une forme en cours de stabilisation — deux conséquences. La première : il ne peut plus se comporter en pionnier ; le template est disponible, ses sections sont claires, sa méthode publique, l’ignorer serait un geste délibéré à motiver. La seconde, moins évidente : il a une opportunité que celui qui écrira dans deux ans n’aura plus — celle de contribuer, par sa pratique, à définir ce que veut dire « bien écrire » dans ce genre. Chaque AIPD produite maintenant qui se confronte sérieusement au template, qui l’utilise comme structure, qui en signale les limites, contribue à la formation du canon. Dans les genres stabilisés, le canon existe déjà ; dans les genres en formation, le canon se fait en l’écrivant. Pour qui fait notre métier, mieux vaut être présent dans cette fenêtre.

Du formulaire à la prose

On pourrait m’objecter que je romantise quelque chose qui n’est qu’un formulaire plus long. Si l’AIPD n’était qu’un formulaire plus long, alors son évolution serait sans intérêt en dehors du périmètre étroit de la compliance : une autre grille à remplir, un autre type de PDF à archiver, un autre coût marginal pour ceux qui traitent des données. Mais un détail du nouveau template, une fois remarqué, démonte cette lecture. Le template ne demande plus seulement d’énumérer. Il demande d’argumenter. Il demande, en particulier, de motiver la proportionnalité des choix, de reconstruire le raisonnement qui mène d’une évaluation du risque à une mesure d’atténuation, de montrer pourquoi un certain équilibre entre utilité et risque résiduel est acceptable. Il demande, en somme, ce qu’un formulaire ne peut demander : il demande de la prose.

L’apparition de la prose dans un document de compliance est le symptôme le plus clair du passage au genre. Un formulaire n’a pas besoin de prose, parce que sa valeur informationnelle est entièrement contenue dans la grille. Un genre, en revanche, vit dans la prose, parce que c’est là que s’expriment les connexions entre les faits, les hiérarchies, les justifications, les nuances. Quand le template EDPB demande d’écrire pourquoi la base juridique choisie est adéquate au contexte, il demande un petit essai. Le contenu aura des contraintes formelles, mais ça reste un essai. Et qui écrit un essai, même de trois cents mots dans une case d’un PDF, n’écrit pas comme qui remplit une case Excel. La prose oblige à choisir un point de vue, à décider de ce qu’on met avant ou après, à montrer quelles informations sont accessoires et quelles centrales. La grille, par nature, aplatit ces hiérarchies. Le passage de la grille à la prose n’est pas un passage de pure forme ; c’est un passage d’épistémologie locale, de ce qu’un certain texte peut raconter et ce qu’il ne peut pas.

Les nombreux lecteurs d’une AIPD

Aspect sous-évalué : qui lit une AIPD. Dans la pratique courante, on pense presque toujours à un seul lecteur — un lecteur hypothétique et peu caractérisé : l’inspecteur d’une autorité de contrôle, figure abstraite, à laquelle la majorité des AIPD ne se confronteront en réalité jamais. Mais un document de genre a toujours plus de lecteurs réels qu’il n’en déclare, et l’AIPD ne fait pas exception. Le commanditaire public qui évalue le fournisseur la lit. Le compliance officer en due diligence d’acquisition la lit. L’avocat qui prépare une défense en contentieux la lit. La personne concernée, si elle est bien écrite et accessible, la lit pour comprendre comment ses données sont traitées. Le fournisseur de techno en amont, dans un contexte de plus en plus fréquent, la lit pour vérifier si son rôle de sous-traitant est correctement délimité. Chacun de ces lecteurs porte un horizon d’attente différent, et le fait que le template EDPB stabilise la forme les aide tous : un lecteur discipliné sait où chercher, sait reconnaître ce qu’il cherche, sait distinguer un texte bien fait d’un texte bâclé. Un formulaire est au fond opaque à tout lecteur extérieur à son rédacteur. Un genre, lui, a la vertu démocratisante d’être lisible pour quiconque en connaît les conventions.

DPIA-as-code

Je reviens un instant à l’expérience d’Oltrematica ces derniers mois, parce que c’est le quotidien sur certains projets qui m’a fait comprendre ce qui changeait. Nous avons des chantiers sur des plateformes sanitaires pour la Région des Abruzzes, sur des systèmes de people analytics en milieu hospitalier, sur des applis pour des administrations locales, sur des plateformes de formation en ligne avec certifications ECM, sur des systèmes de gestion du stationnement pour des régies municipales. Dans tous ces cas, nous avons, ou aurons, une AIPD. Il y a un an, l’approche typique : on cale un call avec le DPO du client, on collecte les infos, on produit un draft, on le revoit ensemble, on le met au repository. Le document était substantiellement clos en fin de processus. Mis à jour au changement du traitement, avec un cycle annuel ou biennal. C’était, clairement, un formulaire. Le plus intéressant : même en interne, l’équipe technique traitait l’AIPD comme un formulaire — quelque chose que le DPO produisait pour nous, pas avec nous, et qui ne nous concernait que si un auditeur nous demandait de confirmer un de ses contenus.

Quand j’ai lu le nouveau template, la première chose que j’ai faite, c’est d’écrire un mémo interne sur ce qui changerait opérationnellement. La seconde, moins immédiate, jeter une proposition que j’ai appelée pour faire bref DPIA-as-code : porter l’AIPD dans le flux de versionnement des projets, l’intégrer à Jira et Confluence, en faire un artefact qui vit dans l’écosystème où vit le code. Pas une idée révolutionnaire. D’autres y pensaient déjà, notamment dans des milieux où la compliance s’est historiquement entrelacée à l’ingénierie logicielle — certaines équipes security du monde cloud-native américain. Mais la raison pour laquelle elle devient une proposition sensée maintenant, et pas il y a deux ans, est exactement le sujet : on ne versionne un document comme on versionne un chapitre de livre que quand il devient genre, plus formulaire. Un formulaire se met à jour avec un nouveau formulaire ; un chapitre se révise avec traçabilité génétique, attention aux variantes, archive des décisions qui te permet de revenir sur tes pas et comprendre pourquoi, il y a un an, tu avais choisi telle formulation plutôt qu’une autre.

Les projets où cette transformation se révèle la plus intéressante sont ceux où le profil de risque évolue avec le produit. Une plateforme de people analytics comme celle développée en partenariat avec Umana Analytics a un cycle où chaque nouvelle feature touche potentiellement des données sensibles, et chaque modif des modèles prédictifs redéfinit les contours du traitement. Une AIPD-formulaire vieillit vite ici : on l’écrit, on l’archive, on la relit un an plus tard et son paragraphe central ne décrit plus fidèlement ce que le produit fait. Une AIPD-genre versionnée, en revanche, suit le produit. Chaque pull request qui touche le périmètre du traitement ouvre une discussion correspondante sur le paragraphe pertinent, qui peut rester invariant ou être mis à jour avec un diff qui explique ce qui a changé et pourquoi. La plateforme sanitaire pour la Région des Abruzzes sur laquelle on travaille depuis des années, avec son flux de données vers une base anagraphique régionale et vers les systèmes nationaux de surveillance, est un cas encore plus clair : tout changement normatif en amont impose une relecture du traitement, et sans AIPD versionnée cette relecture risque de perdre le fil des motivations originales. Avec une AIPD versionnée, tu pars du présent et remontes, décision après décision, au point où le traitement a été défini, en lisant avec le texte les discussions qui l’ont accompagné. Autre cas : la plateforme de formation en ligne pour des organismes ECM, où l’AIPD doit rendre compte d’un traitement relativement stable mais avec un public d’utilisateurs très large et une chaîne de sous-sous-traitants articulée. Ici, la valeur d’une AIPD versionnée est surtout de garder la chaîne de responsabilité alignée à mesure que les fournisseurs changent, chaque mise à jour d’un fournisseur devenant un commit sur la section pertinente — cohérence qu’un formulaire archivé une fois par an ne peut avoir.

Philologie d’auteur, et le git log

Que veut dire, vraiment, versionner un genre. La critique littéraire a une tradition consolidée : ce qu’on appelle en Italie philologie d’auteur ou critique des variantes, associée pour le XXᵉ aux noms de Contini et Isella, et qu’en France on a appelée critique génétique, avec Bellemin-Noël et Pierre-Marc de Biasi. Elle étudie comment un texte a grandi, quelles variantes ont été adoptées et écartées, quelles pressions externes ont modifié la forme, quelles réécritures ont été induites par relecteurs, commanditaires, autocensures. Le git log d’une AIPD versionnée est, banalement, un avant-texte en temps réel. Il montre quand une mesure d’atténuation a été renforcée, qui l’a proposée, en réponse à quel signalement, avec quelles alternatives considérées et écartées. Il produit, en effet collatéral, un niveau de traçabilité qu’aucune AIPD-formulaire n’a jamais eu — parce que le formulaire cache son histoire dans sa version finale, alors que le genre l’exhibe. Et il l’exhibe, non par narcissisme archivistique, mais parce que dans un genre mature l’histoire des choix fait partie de l’argumentation courante. Un auditeur qui sait lire un git log peut comprendre, sans demander confirmation, si une mesure a été implémentée en réponse à une vraie analyse de risque ou rétro-ajustée pour justifier un choix déjà fait. La généalogie d’un texte est un contrôle qualité bien plus efficace que toute signature en bas de page.

Travailler dans ce cadre change, dans mon expérience, plusieurs dimensions opérationnelles. La première : la séparation entre source et rendu. Une AIPD-formulaire vit dans son PDF final, avec tous les problèmes de désalignement que cela implique : tu modifies l’AIPD et découvres que la fiche du traitement dans un autre document dit autre chose, ou que le résumé pour la direction est resté à la version d’il y a six mois. Une AIPD-genre vit dans une source structurée — chez nous, Confluence avec quelques pages clés marquées pour la pipeline d’export — d’où l’on génère les rendus pour les différents lecteurs. La même source produit l’AIPD complète pour le DPO, un résumé exécutif pour la direction, une fiche technique de mitigations pour le dev, éventuellement une version synthétique pour les personnes concernées si le responsable choisit de la rendre accessible. Mêmes contenus, forme adaptée. Cela exige, à la source, une discipline d’écriture plus rigoureuse que ce que prétendait l’AIPD-formulaire — chaque paragraphe doit être pensé pour survivre à des usages multiples. En échange, cela réduit drastiquement ce qui en compliance fait le plus de mal : la prolifération de versions non alignées du même traitement dans des documents différents.

Seconde dimension : le lien avec le ticketing projet. Dans chacun de nos projets, une epic ou story Jira qui touche un nouveau traitement, ou en modifie un existant, ouvre une demande formelle de mise à jour de l’AIPD correspondante. Pas forcément une mise à jour pleine ; une vérification de non-impact suffit, à condition d’être enregistrée. Le lien rend explicite ce qui dans le monde AIPD-formulaire restait implicite, donc oublié : chaque choix produit est un choix de compliance, chaque feature qui touche des données est une modification potentielle du traitement documenté. Lier le ticket au paragraphe d’AIPD revient, en pratique, à imposer que produit et acte d’écriture avancent alignés. Le git log devient une histoire génétique du traitement ; la chronologie Jira devient celle des motivations. Pour une équipe habituée à penser la compliance comme satellite du dev, c’est un changement de posture pas anodin, à accompagner. Les premiers mois ont vu des résistances chez des devs qui voyaient le couplage Jira-Confluence comme bureaucratie supplémentaire ; après six mois, la majorité le considère comme une aide, parce qu’il réduit les réunions d’alignement et rend visible la contribution technique à la construction de la compliance.

Le DPO comme éditeur

Dimension la plus délicate : les rôles. En modèle AIPD-formulaire, le DPO est typiquement auteur principal ou réviseur final, et l’équipe technique fournit des informations. En modèle AIPD-genre, cette géométrie s’inverse partiellement. Le DPO reste responsable de la conformité, mais devient plus précisément éditeur : il fixe des standards, revoit des contributions, garantit la cohérence entre sections, demande des réécritures. Qui écrit le premier draft de nombreuses sections est qui connaît la matière — le product owner, l’architecte, le dev qui a dessiné le data model, le DBA qui a posé la politique de rétention. Le document final reste signé par le DPO et le responsable, mais le tissu du texte est tissé à plusieurs mains. Cela, qui a travaillé en rédaction reconnaît immédiatement, et qui n’a fait que de la compliance trouve déroutant. Pourtant, après six mois d’expériences, c’est la configuration la plus saine.

Je sais que j’introduis une tension. Un DPO devenu éditeur risque de perdre en autorité formelle ce qu’il gagne en qualité du produit. Dans la tradition italienne, où la figure du DPO est souvent juridique et souvent externe à l’organisation, la proposition d’un DPO-éditeur peut sonner comme un affaiblissement. Je crois pourtant que c’est un renforcement, pour une raison subtile mais importante. L’autorité d’un éditeur n’est pas celle de qui produit le texte seul ; c’est celle de qui décide ce qui passe et ce qui ne passe pas. Un DPO qui écrit tout seul peut produire une AIPD formellement inattaquable mais distante de la réalité opérationnelle. Un DPO qui édite ce que l’équipe écrit garde la position finale du non, mais le fait sur du matériau qui a la prise des faits. Résultat, dans mon expérience : plus difficile à attaquer, plus facile à défendre en cas d’inspection.

Lisibilité n’est pas simplicité

Deuxième objection sérieuse à affronter. On pourrait dire : cette reconnaissance de l’AIPD comme genre n’est pas un progrès, c’est une sophistication inutile, une baroquisation de la compliance qui ajoute des charges sans valeur. L’Europe souffre déjà d’inflation normative ; transformer l’AIPD en produit littéraire, fût-il technico-littéraire, aggrave un problème sans le résoudre. Je comprends l’objection mais la crois fausse pour une raison précise. Les genres ne compliquent pas les textes ; ils les rendent lisibles. L’alternative à un genre stabilisé n’est pas un texte plus simple, mais un texte plus difficile à lire — manque la grille permettant au lecteur de s’orienter. Quand un même document arrive sur le bureau d’une autorité dans dix formes différentes, chacune décidée par son auteur, le travail de lecture devient lent et la marge d’erreur grande. Quand le genre est stabilisé, l’autorité peut lire cent AIPD avec l’effort d’un critique expérimenté qui lit cent romans — il reconnaît rapidement où chercher quoi, et perçoit aussi vite les déviations significatives.

Lisibilité, ici, n’est pas synonyme de simplicité. Un sonnet est plus difficile qu’un post sur les réseaux, mais immensément plus lisible pour qui connaît le genre, parce qu’il sait où trouver la chute argumentative, le concept central, la fermeture. De même, une AIPD bien écrite dans le nouveau format sera plus exigeante au détail mais plus rapide à lire pour un auditeur qui connaît le template. Et surtout comparable à d’autres AIPD écrites dans la même forme. La comparabilité est le bénéfice invisible des genres stabilisés, et sera, à mon avis, le gain le plus important des prochaines années pour les autorités. Jusqu’ici, chaque inspection partait de la lecture d’un document comme si c’était le premier de son espèce, en reconstruisant la forme avec les contenus. Quand le nouveau template sera le standard, comparer cent AIPD de cent responsables différents deviendra opération praticable — parce que la forme sera partagée et les différences informatives.

Corollaire de cette comparabilité dans la sphère du commanditaire public — partie de notre portefeuille qui change le plus vite. Dans les procédures d’attribution et les cahiers techniques, l’AIPD (ou la documentation d’impact équivalente) a souvent été demandée comme annexe générique, sans trop de spécifications sur le « comment ». L’administration vérifiait l’existence du document, laissant à la substance une revue tardive, souvent en exécution contractuelle. Avec un genre stabilisé, les acheteurs publics auront la possibilité de faire une chose différente et, du point de vue du candidat, beaucoup plus exigeante : évaluer la qualité du document comme critère de sélection. Une AIPD écrite dans le template EDPB pourra être notée de manière cohérente, comparée aux concurrentes, utilisée comme indicateur de la maturité de compliance de l’offrant. Pour un fournisseur qui a investi dans l’écriture comme pratique, ce sera un avantage net. Pour un fournisseur qui a toujours traité l’AIPD comme une charge à déléguer au dernier moment, un risque croissant. Dans nos domaines spécifiques — santé régionale, chambres de commerce, communes — je crois qu’on verra dans les deux ans précisément ce type de sélection apparaître dans les critères d’attribution : un signal que le genre est entré dans la contractualité publique non plus comme case à cocher mais comme objet de vraie lecture.

La suspicion des LLM

Troisième objection à affronter, qui demande une digression. Si l’AIPD devient un document de prose argumentée, dit-on, alors c’est exactement le type de texte qu’un grand modèle de langage peut produire bien, en quelques minutes. Pourquoi se préoccuper de tout ce discours sur l’écriture, la philologie, les rôles éditoriaux, quand un bon prompt et deux itérations suffisent à avoir une AIPD formellement impeccable ? Question légitime. Réponse courte : cette objection confond deux choses différentes, et la confusion est dangereuse. Un LLM peut produire, oui, un texte qui ressemble à une AIPD et qui dans la majorité des cas passera une vérification formelle superficielle. Mais une AIPD n’est pas seulement son texte final ; c’est la trace documentaire d’un processus de décision. Ses sections ne sont pas une démonstration rhétorique autonome, mais la restitution de conversations réelles entre personnes réelles sur des traitements réels. Un LLM peut m’aider à mieux écrire ces restitutions, à donner du rythme, à suggérer des formulations plus efficaces — il le fait. Il ne peut pas remplacer les conversations en amont du texte, parce que ces conversations sont précisément ce dont l’AIPD doit rendre compte. Une AIPD produite par LLM sans ces conversations est un simulacre, et la différence avec l’authentique se voit vite — surtout au moment de la défendre devant quelqu’un qui pose des questions précises. Le genre, ici, protège qui le pratique honnêtement et démasque qui le simule, parce que la profondeur d’une AIPD bien écrite est inséparable de la profondeur de la réflexion qui l’a produite. C’est, soit dit en passant, un point que la culture de l’AI-native development est en train d’apprendre dans tous les domaines où elle pousse : les outils automatiques sont d’excellents amplificateurs de pensée, pas des substituts. Et c’est précisément dans les genres matures que la différence entre les deux se voit le mieux.

Un écosystème de genres technico-normatifs

L’AIPD-genre, vivant dans l’écosystème du produit, se prête à des intégrations que l’AIPD-formulaire ne pouvait avoir. Je pense en particulier au lien avec le SBOM, qui devient une exigence de plus en plus formalisée dans le cadre du Cyber Resilience Act. Les deux documentations — SBOM et AIPD — ont des histoires séparées et des logiques différentes, mais parlent de la même plateforme. Quand toutes deux vivent versionnées et interrogeables, des choses deviennent possibles : identifier quels composants logiciels sont impliqués dans le traitement de données sensibles décrit dans la section X de l’AIPD, ou signaler quand une mise à jour de dépendance introduit un composant qui change le profil de risque documenté. Un dev qui met à jour une lib de logging peut recevoir automatiquement une alerte : « cette lib est référencée dans l’AIPD du projet Y, paragraphe 4.2, vérifie si la nouvelle version modifie le comportement décrit ». Scénarios science-fictionnels en optique de produit intégré ; en optique de compliance intégrée, ils deviennent, sinon faciles, au moins pensables. Et pensables précisément parce que l’AIPD devient un texte gouverné par des conventions connues, navigable comme un texte — pas une grille opaque au monde extérieur.

Le lien SBOM-AIPD est aussi le point où je perçois que mon propos a des implications plus larges que la seule AIPD. Si l’AIPD se transforme en genre, il est raisonnable de se demander si d’autres artefacts de la compliance européenne subissent la même transformation, et dans quelle direction. Évident, par exemple, que le dossier technique de l’AI Act est en trajectoire vers une identité de genre — sections canoniques, rythme argumentatif, prétention à la lisibilité par une autorité de marché. Idem pour la documentation de vulnérabilité et les politiques de divulgation que le CRA stabilise au fil de l’année, avec les obligations de reporting qui entreront en vigueur en septembre 2026 et les obligations substantielles pleines à partir de décembre 2027. On assiste, en Europe, à une opération décennale de génération de genres technico-normatifs, dont les conséquences sur le travail de qui produit du logiciel restent en grande partie inexplorées. Il y a dix ans, la compliance software était une constellation de formulaires. Dans dix ans, elle sera selon toute probabilité une bibliothèque de genres, chacun avec son canon, ses exemples de référence, sa critique consolidée, son école d’auteurs.

Cette perspective, qui peut paraître abstraite, a un revers commercial concret dont on parle encore trop peu. Une entreprise qui a appris à écrire dans des genres normatifs matures a un avantage compétitif substantiel sur celle qui doit chaque fois apprendre depuis zéro. Et apprendre à écrire dans un genre n’est pas une affaire de cours d’une semaine : ça demande pratique, correction, exposition à de bons et mauvais exemplaires, critique entre pairs, expérience progressive de quelle formulation tient et laquelle non. L’Europe construit, avec des temps et modes pas toujours coordonnés, un écosystème de genres technico-normatifs qui récompensera les organisations capables de faire de cette écriture une compétence stable. Pour qui fait notre métier — software pour PA et santé — cela signifie que le prochain quinquennat ne sera pas gagné par qui écrit du code plus élégant, mais par qui écrit de meilleurs documents de compliance — meilleurs au sens non plus détaillés mais lisibles, argumentés, capables de soutenir une confrontation avec des lecteurs compétents. Changement de paradigme transversal qui redéfinit quelles compétences sont rares et lesquelles ne le sont pas.

Je reviens à l’AIPD avec une observation que j’espère pas trop abstraite. Qu’un formulaire se transforme en genre est une de ces choses qui, une fois advenues, changent rétrospectivement la lecture du passé. Les AIPD écrites entre 2018 et 2025 étaient déjà en quelque mesure du genre — il existait des attentes de lecture, circulaient des exemplaires considérés bons ou mauvais, les autorités commençaient à construire une jurisprudence implicite. Genre en formation, fluide, à contours incertains. Le template EDPB, une fois la consultation close et les pas d’adoption nationale faits, fixera ces contours, cristallisera ce genre, et rendra rétrospectivement visible une trajectoire jusque-là ambiguë. Dès lors, l’AIPD aura un avant et un après, et la différence ne sera pas de détail mais de nature. La fenêtre dans laquelle nous écrivons est exactement le moment où ce passage s’accomplit : plus l’avant, pas tout à fait l’après, c’est le seuil.

Que faire demain matin

Tout ce discours peut sonner, à un ingénieur pragmatique, comme une abstraction philosophique inutile. À quoi ça me sert, dans le travail concret de demain, de savoir que l’AIPD devient un genre ? La réponse pratique est déjà répartie dans les paragraphes précédents, mais ça vaut la peine de la recomposer plus près de ce qu’une équipe doit faire quand elle ouvre le prochain projet. Cesser de traiter l’AIPD comme un document de clôture, produit en aval de la conception, et commencer à la traiter comme un document d’accompagnement, qui naît avec le projet et grandit avec lui. Accepter que les personnes qui contribuent à l’AIPD ne sont plus seulement le juriste et le DPO, mais aussi qui construit le produit — ce qui exige un investissement, petit mais constant, dans leur capacité à écrire des textes argumentés. Introduire dans les processus de dev les couplages, techniques et organisationnels, entre tickets projet et paragraphes d’AIPD, pour que l’écriture ne reste pas une activité parallèle mais devienne partie du travail courant. Repenser le rôle du DPO comme éditeur plutôt que comme rédacteur unique, avec tout ce que cela implique pour la relation avec le reste de l’équipe. Aucun de ces changements n’est dramatique pris seul. Mis ensemble, ils redessinent la façon dont la compliance données se fait, et font émerger la différence entre organisations qui ont compris le passage et celles qui continueront à produire des formulaires dans un monde qui lit des genres.

Une chose à signaler à qui, comme nous, opère dans cette fenêtre de formation du genre. La consultation publique ouverte par l’EDPB n’est pas un adempiment formel pour les seuls initiés à la protection des données : c’est le moment où le template est encore modelable, donc le moment où une voix informée peut laisser une marque. Un fournisseur de software pour la PA italienne qui envoie une contribution raisonnée, ancrée dans l’expérience concrète d’écrire des AIPD pour des organismes publics, participe à la définition du genre plus qu’il ne l’imagine. Pas un geste symbolique : la consultation est l’instrument par lequel les autorités européennes recueillent les cas-limite, les difficultés opérationnelles, les incompatibilités avec des pratiques consolidées, et reformulent les sections en réponse. Dans les deux mois qui viennent, jusqu’au 9 juin, il y a un temps utile pour contribuer. Après, il sera tard au sens spécifique que les formes du canon auront été choisies. Ça vaut la peine d’y consacrer une journée.

Une heure de réécriture

Je voudrais clore par une image qui m’est venue il y a quelques semaines, en relisant pour la énième fois un paragraphe sur les mesures d’atténuation dans une AIPD d’un projet sanitaire. Le paragraphe était formellement correct, couvrait les points requis, citait les bonnes normes. Mais mal écrit, avec cette opacité particulière des textes techniques non soignés où la syntaxe est un parking de propositions. Je l’ai relu en pensant : si un auditeur le lit en vitesse, qu’en retient-il ? Réponse : presque rien — le texte n’est pas fait pour être lu vite, ni pour être lu du tout. Il est fait pour être présent. Archéologie de compliance avant même d’être archivé. J’ai passé une heure à le réécrire, sans ajouter de contenu, juste en remettant en ordre le rythme. À la fin, le paragraphe était 30 % plus court et, surtout, disait les mêmes choses avec une clarté qu’il n’avait pas avant. La différence était éditoriale, pas technique. Mais c’était exactement la différence entre formulaire et genre.

Cette heure de travail, à y réfléchir, est le chiffre exact du changement que je décris. Dans un monde AIPD-formulaire, une heure de réécriture sur un paragraphe formellement correct est du temps gaspillé : le document est conforme, on ferme le ticket, on passe au suivant. Dans un monde AIPD-genre, cette heure est la seule partie vraiment productive de la journée — la seule qui améliore la qualité du texte comme texte. La transformation décrite change donc aussi la définition de temps bien dépensé. Elle change ce qu’une équipe est autorisée à considérer comme du travail. Et change, par conséquence, comment le travail se planifie. Un sprint planning qui réserve deux heures par semaine à l’écriture et à la révision collaborative de l’AIPD n’est pas une excentricité d’équipe qui aime perdre du temps en littérature technique ; c’est une équipe qui a compris dans quel régime documentaire elle commence à opérer. Une équipe qui continue à traiter l’AIPD comme un artefact à produire en une après-midi en fin de projet vit, littéralement, dans un régime qui cesse d’exister.

Ce petit épisode se relie, dans ma tête, à un fil que je tire depuis des mois sur des choses apparemment différentes : le logiciel qui ne vieillit pas bien, le produit qui cesse d’être une catégorie stable, l’internet qui a été clôturé plus que dégradé. Dans tous ces cas, la question de fond est la même, et concerne l’écriture. Quand un artefact technique cesse d’être autosuffisant et devient partie d’un écosystème de textes qui en documentent l’existence, les propriétés du texte comptent autant ou plus que celles de l’artefact. Le software moderne, disais-je dans Cruft, pas patine, ne vieillit pas parce qu’il n’est jamais assez fini pour vieillir. L’AIPD, dans un repli spéculaire, ne peut plus être assez finie pour être archivée : elle vit tant que vit le traitement qu’elle documente, et chacune de ses versions est une photographie en mouvement, pas un monument. La compliance devient, sans que presque personne ne s’en rende compte, une pratique d’écriture continue, pas d’archivage final. Et comme toute pratique d’écriture continue, elle récompense qui la prend au sérieux comme écriture, pas qui la simule comme paperasse.

C’est une direction qui demandera plus à qui écrit, mais qui rendra aussi plus, à long terme, en qualité des décisions prises, en défendabilité des choix, en transmissibilité du savoir accumulé. La traduire en pratique, dans nos flux de travail, est le travail des prochains mois. Pas un travail urgent au sens des deadlines ; urgent au sens que plus on tarde, plus la dette d’écriture s’accumule. Et une dette d’écriture, dans un genre en stabilisation, est difficile à rembourser quand vient le moment du jugement. Qui écrit aujourd’hui ses premières AIPD dans le nouveau template participe aussi, sans tout à fait le savoir, à la formation d’un canon. Dans les deux ou trois prochaines années se décidera, par la somme des pratiques concrètes de milliers d’organisations européennes, quels traits du genre se consolideront comme normaux et lesquels resteront marginaux. Ça vaut la peine d’y être, pour une fois, non comme spectateurs mais comme auteurs.

Le logiciel n’apprend pas, en ce sens. Le logiciel accumule des commentaires qui s’excusent.

L’archéologie du vieux code

Quiconque a travaillé sur une codebase de plus de dix ans reconnaît un certain type de commentaire. // HACK: à retirer quand on migrera à l'API v2. // TODO: comprendre pourquoi ça marche. // NE PAS TOUCHER: a cassé la prod trois fois. Signatures de personnes qui ne travaillent plus là, destinées à des lecteurs futurs qui ne viendront jamais vraiment les résoudre. Sont-ils patine ? Plutôt tissu cicatriciel. La différence n’est pas seulement lexicale. Une chaise d’Alvar Aalto de 1932, si elle a été vraiment utilisée, a aujourd’hui une valeur esthétique que la chaise sortie d’usine en 32 n’avait pas. Le bois s’est foncé là où les mains se posent. La finition mate a perdu son éclat de manière non uniforme, elle a appris le corps qui s’y est assis. Il y a peut-être une réparation au point de jonction entre pied et assise, une vis changée, un renfort fait avec goût par un propriétaire intermédiaire. Tout cela ne la rend pas pire. Cela la rend plus belle, plus précieuse, plus elle-même. Un restaurateur sérieux refuse d’ôter la patine, parce que la patine est devenue partie constitutive de l’objet. La restauration est l’art de distinguer le dommage de l’histoire.

Un logiciel PHP de 1998, s’il a été vraiment utilisé, n’a aujourd’hui aucune valeur esthétique ajoutée. Il a des workarounds stratifiés pour des navigateurs qui n’existent plus. Des contrôles de validation ajoutés trois fois à trois niveaux différents parce qu’à chaque cycle de maintenance personne ne se fiait aux précédents. Des fonctions de quatre cents lignes qui gèrent des cas particuliers introduits par des clients qui ne sont plus clients depuis dix ans. Personne ne propose de préserver cette condition comme partie de la valeur du produit. On parle de dette technique, terme révélateur : dette, pas histoire. Quelque chose à éteindre, pas à honorer. Le vocabulaire avec lequel le secteur décrit son rapport au temps révèle qu’aucun concept disponible ne permet de qualifier de beau un système ancien. Au mieux on dira « solide », « battle-tested », « proven ». Vertus de résistance, pas vertus d’accumulation.

L’archéologie du vieux code est une discipline informelle que tout senior pratique sans l’avoir étudiée. Couches de compatibilité avec des navigateurs éteints : if (window.ActiveXObject) pour les vieilles versions d’IE, hacks CSS qui exploitent des bugs spécifiques à Firefox d’avant les grandes refontes, conditions qui vérifient la présence de window.attachEvent pour distinguer IE du reste à l’époque où les concurrents étaient nombreux et tous différents. Feature flags allumés pour des rollouts graduels jamais terminés, où la moitié du code est derrière un if (feature_active('new_checkout_flow')) et l’autre dans le else, et la feature est en prod à 100 % depuis sept ans mais personne n’ose retirer la branche morte. Migrations de schéma jamais terminées : deux colonnes coexistent, ancienne et nouvelle, les deux écrites « par sécurité », lues sélectivement. Fonctions nommées processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal — progression de tentatives jamais achevées. Rien de tout cela n’est patine. C’est un registre sédimentaire de promesses non tenues, d’intentions que la vie d’entreprise a dépassées avant qu’elles ne se concrétisent. Si un restaurateur trouvait dans une commode du XVIIIᵉ vingt couches de vernis superposées, chacune posée sans retirer la précédente, il ne dirait pas que l’objet a gagné en valeur — il dirait qu’il a été mal traité. Le vieux code est traité ainsi par les pros eux-mêmes, qui l’appellent legacy avec un ton qui mélange la neutralité technique au mépris voilé. Le mot vient du latin legare, léguer, mais a pris en pratique technique un sens presque opposé : quelque chose qu’on subit et dont on aimerait se débarrasser. L’héritage comme fardeau, pas comme don.

Pourquoi le logiciel ne vieillit pas

La question est pourquoi. Pourquoi les objets matériels gagnent quelque chose à travers le temps, alors que les objets numériques ne semblent pouvoir que perdre. Réponse facile : différence ontologique — le code est sémantique pure, sans substrat matériel sur lequel les marques d’usage puissent se déposer. Le bois respire, absorbe l’humidité, s’oxyde, s’use aux points de friction. Le byte ne fait rien de cela. Un fichier binaire est aujourd’hui bit-pour-bit identique à sa naissance, sauf corruption accidentelle, et ces corruptions n’ont aucune valeur sémantique. La réponse facile a le défaut de toutes les réponses faciles : fermer le débat exactement là où il devrait s’ouvrir.

Allons plus loin. Une chaise vieillit bien non parce qu’elle est en bois mais parce que son entour reste substantiellement stable. La gravité ne change pas. La physiologie humaine non plus. La fonction « soutenir un corps assis » non plus. Les modifications qu’elle subit sont internes à son tissu, en dialogue avec un environnement qui bouge bien plus lentement. La chaise et le monde autour vieillissent ensemble, à la même vitesse, et le résultat est une co-évolution domestique. Le logiciel existe dans un environnement qui bouge bien plus vite que lui. Le navigateur change de version toutes les quatre semaines. Le langage casse la rétrocompatibilité tous les deux ans. Les bibliothèques ont un cycle de vie plus court qu’un mandat parlementaire. L’OS sous lequel il tourne cesse d’exister sous la forme où il avait été compilé. Le logiciel ne vieillit pas en interne comme le bois. Il se détache progressivement de son environnement, comme un vaisseau qui n’a plus de propergol et voit la station s’éloigner. Ce qu’on appelle « software aging » n’est pas vieillissement au sens de la chaise. C’est une dérive environnementale. C’est la mesure de la distance croissante entre un artefact figé et un contexte mouvant.

Cette différence est ontologiquement pertinente. Un bâtiment et son contexte urbain vieillissent ensemble en dialogue continu, et cette co-appartenance est la condition même qu’on puisse parler de « vieillissement » au sens propre. Le logiciel n’a pas de co-appartenance : il a la compatibilité, relation bien plus pauvre. Compatibilité ne signifie que ceci : deux choses qui ne se parlent plus peuvent continuer à faire semblant de se parler pour un cycle de release de plus. Quand Brand écrit que les bâtiments apprennent, il décrit un processus où le bâtiment et ses habitants se modifient mutuellement. Quand un sysadmin ajoute un compatibility shim pour faire tourner un vieux binaire sur un nouveau kernel, il met un coin entre deux mondes qui ne se parlent plus, et il achète du temps. Le shim est l’opposé de l’apprentissage : c’est l’aveu que l’apprentissage est impossible et qu’on ne peut que simuler la communication.

Ruskin, et la vérité de l’usage

Il y a un passage de Ruskin, dans Les Sept Lampes de l’architecture, qui soutient qu’un bâtiment neuf est par nature faux, et ne devient vrai qu’à travers la fréquentation des années. Ruskin est victorien, emphatique, souvent agaçant, mais cette phrase est une des choses les plus précises jamais dites sur l’objet construit. La vérité d’un bâtiment n’est pas dans le projet mais dans l’histoire de son usage. Si l’on applique le même critère au logiciel, il faut conclure que le logiciel ne devient jamais vrai. Il reste dans un état permanent de nouveauté, même quand sa date de compilation a vingt-cinq ans, parce que l’accumulation d’histoire qui devrait le rendre réel au sens ruskinien n’est pas possible dans son médium. La seule chose qu’il accumule est l’incompatibilité croissante avec son entour, et ce n’est pas histoire : c’est érosion.

L’objection Unix

Il faut aborder l’objection forte. Mais Unix a plus d’un demi-siècle, et non seulement il fonctionne encore, mais il est devenu plus élégant avec le temps. POSIX, TCP/IP, SQL, le système de fichiers hiérarchique, le pipe. Idées qui ont entre quarante ans et un demi-siècle. Encore au cœur de l’infrastructure numérique de la planète. Elles ne se comportent pas comme le PHP de 1998. Elles se comportent, si l’on veut, comme la chaise d’Aalto. Quelque chose dans le raisonnement précédent ne tient pas.

L’objection est sérieuse et mérite réponse sérieuse. La réponse facile : Unix est une exception, un outlier, un cas chanceux qui n’invalide pas la règle. Réponse pauvre. La réponse intéressante : Unix ne contredit pas le raisonnement, il en montre le mécanisme exact, et clarifie une distinction restée implicite. Distinction entre logiciel-comme-code et logiciel-comme-spécification.

Spécification, pas code

Ce qu’on appelle « Unix » aujourd’hui n’est pas, littéralement, le logiciel que Thompson et Ritchie ont écrit aux Bell Labs entre 1969 et 1971. Ce code est mort depuis des décennies. La branche commerciale AT&T a été vendue, démantelée, réabsorbée. BSD a été forké de nombreuses fois, et chaque fork à son tour réécrit. Linux, qui est aujourd’hui la forme dominante d’Unix dans l’infrastructure mondiale, ne partage pas une seule ligne de code avec l’Unix originel : c’est une réimplémentation indépendante, lancée par Linus Torvalds en 1991, qui expose les mêmes interfaces système (appels, structure du système de fichiers, conventions) mais a été écrite à partir de zéro. macOS dérive de NeXTSTEP, qui repose sur le micro-noyau Mach et sur des composants BSD, et là aussi le code a été réécrit et refondu tant de fois que la continuité matérielle avec le point de départ est purement rituelle. Ce qui a survécu n’est pas le corps d’Unix, mais sa forme. Son interface. Sa grammaire. Le fait qu’il y ait des appels système qui s’appellent open, read, write, close, et qu’ils fonctionnent à peu près comme en 1973, ne signifie pas que le code qui les implémente a bien vieilli. Cela signifie que la spécification qui les définit est devenue autre chose que le code : elle est devenue culture, convention, langue partagée, norme de fait puis norme de droit via POSIX.

Idem pour TCP/IP. Le protocole a survécu, l’implémentation non — pas dans sa forme originelle. Toute pile TCP/IP moderne, de Linux à Windows à iOS jusqu’à l’ESP32 d’une lampe connectée, a été réécrite ou réalignée plusieurs fois au fil des décennies. Le 4.4BSD networking code, longtemps base de référence du noyau réseau, a été progressivement absorbé, ramifié, réimplémenté au point que les codes modernes maintiennent une parenté plus historique que matérielle. Ce qui persiste, immuable, est la RFC : un document texte qui décrit, en anglais technique, comment deux machines devraient se parler. La RFC n’est pas du logiciel. Elle est plus proche d’un traité diplomatique. C’est pourquoi elle vieillit bien : elle appartient à la même classe d’objets qu’un traité, une constitution, une grammaire. Une convention partagée dont la force ne tient pas à son implémentation mais au nombre d’acteurs qui la reconnaissent comme contraignante.

SQL est le cas le plus instructif. La syntaxe SELECT ... FROM ... WHERE a été définie au milieu des années 70 par Donald Chamberlin et Raymond Boyce chez IBM. Tout le monde l’utilise aujourd’hui. Mais aucune base relationnelle en prod ne tourne sur le code original de System R. Postgres est une réimplémentation. MySQL aussi. SQLite a été écrit à partir de zéro dans les années 2000 et est aujourd’hui probablement la base la plus répandue au monde. Le code qui implémente SQL est mort et renaît tant de fois qu’il n’a plus de sens de parler de continuité matérielle. Ce qui demeure : le modèle relationnel — objet mathématique — et une certaine syntaxe — objet culturel. Les deux se sont détachés du code qui les avait initialement incarnés, et c’est précisément pour cela qu’ils ont pu traverser le temps.

TeX, SQLite et les exceptions qui confirment

Quelques cas, rarissimes, où le code lui-même semble avoir réussi quelque chose qui ressemble vraiment à la patine, et qui éclairent par contraste la condition générale. TeX, le système de composition typographique de Knuth depuis 1978. Knuth a décidé à un certain moment que TeX était fini, au sens littéral : aucune nouvelle feature, seulement des corrections de bugs, le numéro de version convergeant asymptotiquement vers π à chaque release, l’intention explicite que la dernière version, à la mort de Knuth, prenne la valeur exacte de π et que le logiciel cesse de changer pour toujours. Knuth offre une petite récompense monétaire qui double chaque année à quiconque trouve un bug dans TeX, et personne ne la réclame plus depuis longtemps. Pas parce qu’il n’y en a pas, mais parce que le logiciel a été si massivement utilisé que les bugs résiduels vivent dans des coins jamais visités. TeX fonctionne aujourd’hui comme à la fin des années 80, compile les mêmes sources, produit la même sortie typographique. Son code, écrit en WEB (literate programming inventé par Knuth, combinant Pascal pour la logique et TeX pour la documentation), a été publié en 1986 sous le titre TeX: The Program, comme volume B de Computers and Typesetting, traité comme une œuvre littéraire. Lu, commenté, étudié. Une des rares fois où le code a dépassé le seuil de la pure implémentation pour devenir lui-même quelque chose qui ressemble à une spécification, mais sous forme concrète de programme, pas sous forme abstraite de RFC. Knuth a obtenu ce résultat en imposant à son œuvre une condition extrême : refuser toute évolution. TeX ne vieillit pas parce qu’il a choisi de ne pas vivre, en un sens. Il a accepté la momification comme prix de la permanence.

SQLite est l’autre cas intéressant, plus récent et moins mystique. Ses développeurs ont déclaré publiquement, dans la doc, l’intention de maintenir la lib jusqu’en 2050, avec rétrocompatibilité totale de l’API C et du format on-disk. Engagement non décoratif mais contrainte concrète parce que SQLite est intégré dans des systèmes avioniques (Airbus A350 entre autres), des dispositifs médicaux, des appareils militaires — tous objets aux cycles de vie de plus de quarante ans. Pour soutenir cet horizon, SQLite a construit un appareil de tests qui, selon les chiffres déclarés, atteint environ 92 millions de lignes de tests contre 150 000 lignes de la lib elle-même — un ratio de presque 600 pour 1. Chaque branchement conditionnel est couvert par tests MC/DC, le standard utilisé en avionique pour les certifications DO-178B. Le code lui-même est écrit avec une attention explicite au fait qu’il sera lu et maintenu par des personnes pas encore nées. SQLite a pris la durée comme problème de design dès le début, traitant la stabilité de son interface comme question éthique plus que technique. Résultat : un logiciel qui existe depuis plus de vingt-cinq ans, tourne sur des milliards de dispositifs, et que personne n’a jamais ressenti le besoin de réécrire. Cas où le code lui-même, et non la spec, semble avoir bien vieilli. Mais en regardant de près, on comprend que ce résultat n’a été obtenu qu’au prix d’une acceptation radicale de contraintes que le reste du secteur ne serait pas prêt à accepter. SQLite ne change presque jamais, au prix de renoncer à des features qui rendraient le code plus moderne. SQLite n’a pas de dépendances externes, presque une protestation contre la façon dont le reste du monde fait du software aujourd’hui. SQLite a une culture interne disciplinaire qui frôle le monastique. Autrement dit, SQLite vieillit bien parce qu’il s’est fabriqué une niche écologique dans laquelle l’environnement autour du code a été artificiellement stabilisé. Il a recréé, dans un petit périmètre, les conditions qui permettent à la chaise d’Aalto de devenir plus belle avec les années : un environnement qui bouge lentement, un utilisateur attentif, une culture qui reconnaît la valeur de la durée. Pas un hasard que ces exemples soient, statistiquement, des anomalies. Ce sont les exceptions qui révèlent exactement quelles sont les conditions nécessaires au vieillissement du logiciel — et confirment que ces conditions, dans le corps principal du secteur, n’existent pas.

Le corps meurt, la spécification ressuscite

Sous cet angle, Unix ne vieillit pas bien. Unix est continuellement ressuscité. Le corps meurt et est refait à zéro à partir d’une spécification entre-temps devenue assez sacrée pour mériter la réécriture intégrale du corps tous les vingt ou trente ans. C’est la structure d’une religion plus que d’un objet matériel. La chaise d’Aalto, pour rester sur la métaphore, n’a jamais été refaite à zéro : la chaise de 1932 est physiquement là, avec ses cabosses. Si l’on appliquait au bois la logique d’Unix, on dirait que le concept de « chaise Paimio modèle 41 » a survécu parce qu’Artek, depuis sa fondation en 1935, en a continué la production pendant plus de quatre-vingt-dix ans, et que les chaises de 2026 sont descendantes de celles de 1932 mais ne sont pas les mêmes chaises. Vrai, mais déplacé : ce qui nous intéresse de la chaise de 1932 c’est précisément sa durée matérielle, pas la persistance de son modèle. Dans le logiciel, c’est l’inverse. Le code originel ne nous intéresse pas, et personne ne le conserve comme relique. C’est la persistance du modèle qui nous intéresse, et cette persistance exige la destruction et la réécriture périodiques du code.

L’objection Unix, donc, ne dément pas le raisonnement, elle le redéfinit. Ce qui vieillit bien dans le numérique n’est pas du code. Ce sont des spécifications qui ont eu la chance et le capital culturel de s’élever au-dessus de leur substrat d’implémentation et de devenir autre chose. Normes. Interfaces stables. Lingua franca. La majorité du code n’atteint jamais ce niveau et ne peut l’atteindre. Le 99 % du logiciel qui tourne dans le monde aujourd’hui ne deviendra pas POSIX. Le CRM sur mesure d’une boîte de quatre cents personnes ne deviendra pas SQL. Le site e-commerce d’une chaîne de magasins ne deviendra pas TCP/IP. Pas parce qu’il est mal écrit, mais parce qu’il n’est pas ce type d’objet. Il est, structurellement, implémentation. Et l’implémentation, dans le numérique, ne peut pas vieillir bien — elle n’a aucun des prérequis : pas de substrat matériel qui enregistre l’usage, pas d’environnement stable où demeurer, pas le poids culturel qui permet la réincarnation périodique.

Réécrire n’est pas un péché

Cette distinction éclaire aussi un débat interne au secteur, mal posé depuis toujours. Joel Spolsky, en 2000, écrivit un article devenu fameux, Things You Should Never Do, Part I, soutenant que réécrire à zéro un logiciel fonctionnel est la pire erreur stratégique d’une boîte de software. L’argument était bon et précis : Netscape avait perdu le marché parce qu’elle s’était mise à réécrire le navigateur depuis zéro, laissant trois ans de fenêtre à Internet Explorer. Le problème de Spolsky : il généralise un cas particulier sans reconnaître que la majorité du logiciel doit être réécrit, tôt ou tard, parce qu’il ne peut être maintenu indéfiniment dans la forme conçue. Unix a été réécrit plusieurs fois. Linux lui-même, au niveau de sous-systèmes, est continuellement réécrit : le scheduler a été remplacé, le networking stack refait, le filesystem repensé. Ce que Spolsky appelait « ne jamais réécrire » est en réalité « ne pas perdre la continuité de la spécification durant la réécriture », chose très différente et bien plus difficile. La réécriture échoue quand elle perd contact avec ce que le code devait faire pour ses utilisateurs réels. Elle réussit quand elle conserve la spec et jette l’implémentation, comme le corps d’un catholique est enterré tandis que l’âme migre.

Une dignité interdite

Si cette lecture est juste, alors la tristesse sous-jacente d’une bonne partie du travail technique quotidien a une explication structurelle, pas psychologique. Nous n’écrivons pas mal. Nous écrivons des objets qui ne peuvent pas vieillir, parce que nous n’appartenons pas à la classe restreinte des artefacts qui peuvent s’élever à la spécification culturelle. Le 99 % de ce que nous écrivons est destiné à mourir sans laisser de traces, non par défaut de fabrication mais par propriété du médium. Un maçon du XIIIᵉ savait que si son mur était bien fait, il serait là au XVIᵉ, et probablement au-delà. Un plombier du XXᵉ savait que ses tuyaux, avec un peu d’entretien, serviraient trois générations. Une développeuse de 2026 sait que le code qu’elle écrit aujourd’hui sera, avec bonne probabilité, démantelé d’ici cinq à sept ans. Pas parce qu’elle écrit moins bien que les tuyaux. Parce que le tuyau et le mur appartiennent à un régime où le vieillissement est possible, et le code non.

Cela change la nature éthique du métier d’une façon qu’on n’a pas encore métabolisée. Construire quelque chose de durable a été pendant des millénaires une des plus hautes dignités du travail humain. La cathédrale, le pont, le livre imprimé, le violon. Objets faits dans la conscience de durer au-delà de la vie de qui les construit. Le développement logiciel est un des rares métiers à haute qualification où cette dignité est structurellement interdite. Pas parce que personne ne travaille bien, mais parce que le médium n’admet pas ce type de durée. La dette technique évoquée au début, vue de cet angle, n’est pas un défaut gérable par meilleures pratiques, plus de discipline, tests plus rigoureux, revues plus attentives. C’est la forme spécifique que prend le détérioration inévitable d’un artefact qui n’a pas d’autre façon de se détériorer. C’est la manière dont le logiciel vieillit mal parce qu’il ne sait pas vieillir autrement.

La lampe de la mémoire

Lecture plus large, qui sort du strictement technique. Ruskin, encore, identifiait sept vertus de l’architecture, qu’il appelait lampes. Sacrifice, vérité, puissance, beauté, vie, mémoire, obéissance. La lampe de la mémoire était, pour lui, la vertu des bâtiments qui se laissent traverser par le temps sans lui résister, qui conservent les traces de qui les a habités, qui deviennent à leur manière des archives biographiques du passage humain. Une civilisation qui ne sait construire des objets capables de mémoire, disait Ruskin, est une civilisation qui a renoncé à une de ses fonctions fondamentales : se transmettre à travers ses choses.

Le numérique est, sous cet angle, l’opposé exact de l’architecture ruskinienne. Une culture matérielle, si l’on peut encore l’appeler ainsi, où la mémoire ne s’accumule pas dans les choses mais les quitte. Le logiciel d’il y a cinq ans est déjà une antiquité. Le site web d’il y a dix ans n’est plus accessible, son domaine est expiré, ses liens cassés, ses images pointent vers des serveurs démantelés. Les archives numériques n’existent que par des efforts héroïques et marginaux : Internet Archive est un point unique de défaillance pour la mémoire de trois décennies de culture en ligne, et personne n’a vraiment compris comment le remplacer. Nos photos sont sur des serveurs que nous ne possédons pas, dans des formats peut-être illisibles dans vingt ans, protégés par des CGU modifiables unilatéralement. Notre correspondance est dans des boîtes qui disparaîtront quand la boîte qui les héberge changera de modèle. La continuité matérielle du patrimoine humain, garantie pour des millénaires, fût-ce imparfaitement, par la durée physique des objets, est devenue précaire d’une façon qu’aucune civilisation précédente n’avait connue.

Cette précarité n’est pas un effet collatéral mais une propriété structurelle du médium. Et le logiciel, cœur de cette nouvelle condition, hérite et amplifie la précarité. Il ne vieillit pas parce qu’il ne sait pas accumuler de mémoire dans ses fibres. Il n’a pas de fibres. Sa seule forme de continuité est la réécriture, qui est l’opposé exact de la mémoire : la production périodique d’un nouvel objet qui feint d’être le même.

Quelqu’un objectera ici que je dramatise, que chaque époque a eu sa précarité, que le papyrus se décomposait, que le parchemin était gratté pour être réutilisé, que le livre imprimé brûle. Vrai, mais la différence quantitative devient qualitative. La durée moyenne d’un livre imprimé bien conservé se mesure en siècles. La durée moyenne d’un fichier numérique se mesure en années, peut-être en décennies dans les cas heureux. Le delta est d’un ou deux ordres de grandeur. Une civilisation où les objets culturels durent cent fois moins est une civilisation structurellement différente, pas seulement quantitativement. Elle a un autre rapport au temps. Produit une autre subjectivité chez qui l’habite. Une développeuse sait, d’une façon qu’un typographe du XVIᵉ ne savait pas, que son travail ne lui survivra pas.

L’objection de l’éphémère

Il y a une lecture moins tragique, qui mérite d’être traversée. L’objection : la permanence n’est pas nécessairement une vertu, et le logiciel pourrait représenter une forme de production culturelle délibérément éphémère, au sens où une performance théâtrale ou un concert de jazz sont éphémères, et leur éphémérité n’est pas un défaut mais une caractéristique constitutive. Une fonction lambda qui tourne pendant 37 millisecondes puis disparaît n’est pas un objet raté parce qu’il ne dure pas : c’est un objet pleinement réalisé parce qu’il a fait exactement ce qu’il devait faire au moment juste. La métaphore du monument, héritée de l’architecture, pourrait être inadaptée au médium, et insister sur le fait que le logiciel « ne vieillit pas bien » pourrait revenir à se plaindre qu’un orage ne vieillit pas bien : confondre une catégorie qui ne s’applique pas.

L’objection est intéressante mais se brise quand on la prend au sérieux. Le problème n’est pas le code qui tourne 37 ms. Cela, c’est vraiment un événement, pas un objet. Le problème : la quasi-totalité du logiciel dont nous dépendons quotidiennement n’est pas un événement en ce sens — c’est de l’infrastructure. Le système avec lequel notre banque gère les comptes n’est pas une performance jazz. Le software médical qui contrôle le respirateur en réa n’est pas un orage. La base anagraphique de la mairie n’est pas une fonction éphémère. Ce sont des objets qui prétendent être infrastructure, que nous traitons comme infrastructure, que les institutions inscrivent dans leurs processus comme s’ils l’étaient — mais qui ont les propriétés de durée et de mémoire d’un nuage. Cette discordance entre la fonction sociale du logiciel et ses propriétés matérielles de durée est le point où la question cesse d’être philosophique et devient civile. Une société qui confie ses fonctions vitales à des objets qui ne savent pas vieillir transfère silencieusement le coût de la maintenance de sa propre continuité à un substrat technique qui ne sait pas le soutenir.

Infrastructure précaire, droit qui court derrière

Le Cyber Resilience Act européen, adopté comme Règlement (UE) 2024/2847, en pleine application à partir de décembre 2027, la nouvelle PLD (UE) 2024/2853, les obligations NIS2, sont, sous cet angle, des tentatives maladroites mais indicatives de forcer le logiciel à se comporter comme infrastructure sérieuse. Ils obligent les producteurs à définir une période de support reflétant le cycle de vie attendu (au moins cinq ans dans la plupart des cas), à maintenir des SBOM à jour, à répondre des vulnérabilités introduites dans le produit même après vente. C’est en un sens la tentative législative d’imposer à l’objet logiciel les propriétés de durée qu’il n’a pas par nature. Que ces règles existent et soient perçues par le secteur comme un coût supplémentaire plutôt que comme une reconnaissance de responsabilité civile dit quelque chose sur le fait que qui produit du logiciel a intériorisé l’éphémère comme privilège. Le maçon sait qu’il doit répondre de son mur pendant de nombreuses années. La développeuse est habituée à répondre de son code jusqu’au terme de la garantie contractuelle, en général douze ou vingt-quatre mois. Les deux figures professionnelles ont des horizons temporels de responsabilité qui diffèrent d’un ordre de grandeur — différence invisible dans le langage avec lequel on les décrit.

Une éthique de la durée

Revenons à la question initiale, pourquoi le logiciel ne sait pas vieillir, on peut donner une réponse moins lapidaire. Il ne sait pas vieillir parce qu’il est fait d’un matériau sans grain, dans un environnement qui bouge plus vite que lui, dans une culture productive qui a renoncé à considérer la durée comme dimension de la valeur. Chacun de ces trois facteurs est cause suffisante du résultat ; sommés, ils le rendent quasi inévitable. Le premier est ontologique et probablement irrésoluble : le code ne deviendra jamais bois. Le second est systémique et pourrait être atténué si la culture technique apprenait à traiter la stabilité comme qualité plutôt que signe d’arriération. Le troisième est purement culturel, et c’est le seul sur lequel on peut agir vraiment.

Agir comment ? Probablement dans des directions que le secteur considère aujourd’hui régressives. Ralentir les cycles de release. Préférer la rétrocompatibilité à l’élégance. Écrire moins de code et plus de spec. Traiter les interfaces stables comme des monuments — c’est-à-dire des objets dont la valeur tient à leur résistance au changement. Accepter que la majorité du code ne devienne pas Unix, et précisément pour cela, l’écrire avec une certaine conscience de son destin de transitoire — sans l’ambition fausse de la durée et sans le désespoir nihiliste de son absence. Un métier qui sait qu’il ne construit pas de cathédrales mais qui refuse de bâtir des baraques. Une dignité intermédiaire, qu’on n’a pas encore de bon mot pour décrire, et qui est peut-être une des choses que cette génération de techniciens devrait essayer de formuler.

S’il y a une consolation dans le fait que le logiciel ne vieillit pas bien, c’est que cette caractéristique nous oblige à mettre au point, par contraste, ce que vieillir bien signifie en général. Elle nous force à reconnaître que la patine de la chaise d’Aalto n’est pas un fait automatique du bois, mais le résultat d’une longue relation entre un objet bien fait, un environnement stable, une utilisatrice attentive et une culture qui sait reconnaître la valeur de cette triangulation. Quand l’un de ces termes manque, la patine ne se forme pas. Le bois laissé sous la pluie ne prend pas patine, il pourrit. Le bois enfermé dans un dépôt ne prend pas patine, il sèche. La patine est une œuvre collective qui exige temps, soin, contexte. Le logiciel, en l’état, n’a aucun des trois, et l’idée même qu’il pourrait les avoir sonne comme une rêverie nostalgique.

Ce n’est pas une rêverie. C’est une question de design. Que voudrait dire écrire du code en sachant qu’il doit durer comme un mur ? On ne le sait pas encore vraiment, parce qu’on ne s’y est presque jamais essayés sérieusement, et quand on l’a fait, ce fut presque toujours dans des domaines marginaux par rapport au mainstream : avionique, contrôle industriel, systèmes bancaires legacy, où la durée est imposée de l’extérieur comme contrainte normative plus que comme choix culturel. Le software civil — qui construit la vie publique et privée de la majorité des gens — a été bâti sur l’hypothèse implicite que la durée n’est pas son problème. Cette hypothèse devient insoutenable au moment même où la société délègue au logiciel des fonctions de plus en plus vitales. Parmi les responsabilités de cette génération de techniciens, commencer à formuler une éthique de la durée pour le métier est probablement l’une des plus sérieuses, et l’une des moins reportables.

Reste, à la fin, la question de fond. Le logiciel ne vieillit pas bien. Cette phrase, au début, ressemblait à une plainte technique. Arrivés ici, on comprend que c’est autre chose. C’est une description exacte du type d’artefacts que nous avons décidé, collectivement, de mettre au centre de notre vie commune, et une demande implicite de tirer les conséquences de cette décision. Les objets que nous mettons au centre d’une civilisation devraient, dans la mesure du possible, savoir l’accompagner dans le temps. S’ils ne le savent pas, il faut soit les changer, soit changer la place qu’ils occupent. Jusqu’ici nous n’avons fait ni l’un ni l’autre. Nous avons laissé qu’ils occupent le centre en se comportant comme s’ils étaient à la périphérie, et nous avons appelé cette condition « progrès ». Il vaut la peine de commencer à l’appeler par un nom plus précis.

Quand la seconde moitié du liquide fut versée dans le verre avec la glace fondue, sortit de la bouteille, entraîné par le soda, un escargot en état de décomposition avancée. May Donoghue tomba malade d’une gastro-entérite sévère, fut visitée par un médecin le 29 août et hospitalisée en urgence à la Glasgow Royal Infirmary le 16 septembre. Quatre ans plus tard, en 1932, la House of Lords rendit un arrêt considéré comme la pierre angulaire du droit moderne de la responsabilité du fait des produits dans le monde de common law.

L’escargot dans la bouteille

La décision fut prise à la majorité de trois voix contre deux. Le rédacteur de l’opinion majoritaire fut Lord Atkin, qui dans le passage célèbre que tous les étudiants en droit continuent à mémoriser formula ce qu’on appelle le neighbour principle — l’obligation pour chacun de prendre soin de son voisin au sens juridique, où voisin signifiait quiconque était raisonnablement prévisible comme destinataire des effets de son comportement.

Dès lors, le producteur répond de son produit même envers ceux avec qui il n’a pas de relation contractuelle, même si la bouteille passe par un distributeur et un café avant d’arriver au consommateur, même si entre l’usine et la gastro-entérite de Mrs Donoghue s’interposent des semaines d’entrepôt et des kilomètres de route.

Ce que presque personne ne remarque en lisant l’arrêt, c’est que le juge, pour pouvoir écrire le neighbour principle, avait besoin d’un présupposé ontologique précis — d’une certaine idée de l’objet dont on parlait. L’objet était la bouteille. Un artefact borné, doté de contours nets, identifiable, examinable, conservable.

La bouteille était produite dans une usine spécifique, chez David Stevenson de Paisley, remplie à un moment daté, scellée par un bouchon qui en garantissait l’intégrité jusqu’au point de vente. Si nécessaire, les avocats auraient pu demander à examiner le lot de production, à analyser la composition du verre, à vérifier la chaîne d’approvisionnement des sucres et des arômes. La cause matérielle, au sens aristotélicien, était joignable. La cause efficiente — le processus productif — était documentée. La cause formelle — la forme typique d’une bouteille de soda — connue de tous.

Tout le droit moderne de la responsabilité du fait des produits qui s’est construit sur Donoghue v. Stevenson présuppose ceci de très simple et capital : on peut pointer du doigt un objet et dire « ceci », et le doigt qui pointe trouve toujours quelque chose au bout.

La nouvelle PLD et le problème d’une catégorie

En 1985, l’Europe, avec la Directive 85/374/CEE, a transposé en forme continentale le principe de Donoghue, en l’étendant et en le systématisant. La Product Liability Directive parle de « produits défectueux » et établit une responsabilité objective du producteur, indépendante de la faute, pour les dommages causés par le produit.

Quarante ans plus tard, le 23 octobre 2024, la Directive 2024/2853 a été adoptée, entrée en vigueur le 9 décembre 2024 et à transposer dans les ordres nationaux d’ici le 9 décembre 2026, date à partir de laquelle l’ancienne directive de 1985 est abrogée. La nouvelle PLD a été pensée expressément pour le logiciel et inclut dans la définition de produit les fichiers numériques, les composants logiciels, les applications, les systèmes d’IA. C’est l’une des plus ambitieuses réformes du droit de la responsabilité civile jamais tentées par l’UE.

Le fait qu’il ait fallu quarante ans pour la repenser, et que malgré l’effort énorme de ses rédacteurs elle risque d’être déjà inadaptée le jour de son entrée en vigueur, n’est la faute de personne en particulier. C’est la conséquence d’un problème que le droit n’a pas encore su nommer avec précision. Le problème est que le « produit » sur lequel Lord Atkin et ses successeurs ont bâti deux siècles de jurisprudence, dans le logiciel contemporain, n’existe plus.

Vaut la peine de prendre une minute pour comprendre où il est passé, parce que le diagnostic est le point de départ de tout ce qui suit.

Du disque au concert

Pendant longtemps, le logiciel a été un produit au sens plein et conventionnel. On est sorti du laboratoire des Bell Labs et on est entré dans la distribution de masse avec Unix puis avec les OS pour PC.

Une application des années 80 ou 90 était un ensemble de fichiers distribués sur disquette, puis sur CD, puis sur DVD, avec un numéro de version, un hash identificateur, une copie conservable au coffre. Si le logiciel présentait un défaut, on pouvait, du moins en théorie, isoler la version exacte du binaire, la comparer à la version supposée correcte, identifier le bug. Windows 95 était un produit. Word 97 aussi. Même un jeu comme Baldur’s Gate, avec ses patchs numérotés et conservables.

Bien sûr, déjà alors, le logiciel dépendait de choses qui n’étaient pas le produit au sens strict — drivers, firmware, protocoles réseau, services système. Mais ces dépendances étaient statiques, déclarées, en nombre limité et surtout médiées par un artefact autosuffisant qu’on pouvait conserver et reproduire bien des années plus tard. La copie du CD de Windows 95 qu’un archiviste numérique conserve aujourd’hui est encore identique à celle de 1995, bit pour bit. Le produit, comme objet doté de continuité dans le temps, existait.

Au début des années 2000, quelque chose commence à changer, et la vitesse du changement s’accélère dramatiquement la décennie suivante. La transition au software as a service déplace l’application du disque local du client au serveur du fournisseur. Au début c’est une simple question de distribution, mais bientôt cela devient une transformation ontologique.

Quand l’application tourne sur un serveur distant, la version qu’utilise l’utilisateur à un moment donné n’est plus une propriété stable — c’est une propriété momentanée, renégociable par le fournisseur à tout instant sans même prévenir. Le continuous deployment pousse cette fluidité à son aboutissement, avec des entreprises qui mettent en production des dizaines ou des centaines de changements par jour, sans que personne, même en interne, ne soit en mesure de reconstituer exactement la configuration du système à 14h23 d’un mardi d’il y a trois mois.

En parallèle, la composition interne du logiciel change de nature. Depuis le début des années 2010, grâce aux écosystèmes comme npm, Maven ou PyPI, écrire une application signifie importer des centaines ou milliers de paquets tiers, chacun composé à son tour de paquets tiers, dans un graphe de dépendances transitives qu’aucun humain ne lit entièrement et qui se met à jour de façon asynchrone par rapport au code écrit. L’affaire left-pad en 2016, quand un seul dev a effacé de npm un paquet de onze lignes et a cassé une grande partie des pipelines de build et processus d’installation du monde JavaScript, fut le moment où l’industrie s’est aperçue, un instant, à quel point fragile et distribué était devenu ce qu’elle continuait à appeler produit.

La dernière accélération, vécue ces mois-ci, est l’entrée des modèles de langage dans la chaîne productive du logiciel. Ici le saut n’est pas seulement quantitatif mais catégorial, parce que ce qui entre dans le produit n’est plus un ensemble d’instructions déterministes mais un composant probabiliste dont les outputs ne sont pas exactement reproductibles, et dont les poids, une fois écartés par le fournisseur pour passer au modèle suivant, pourraient ne plus être accessibles.

Une application qui tourne aujourd’hui via API sur un modèle frontier est une application dont le comportement observable dépend d’un composant qui pourrait demain se comporter différemment, dans deux ans n’exister plus sous une forme récupérable, et dont le fonctionnement interne n’est inspectable par personne, pas même son entraîneur. Qui développe sait : si un utilisateur d’il y a cinq ans nous demandait de reproduire exactement le bug qu’il avait vu, la réponse honnête serait que nous ne le pouvons pas, parce que le système qui a produit ce bug n’existe plus dans une configuration restorable. Les dépendances ont été mises à jour, les API externes ont changé de contrat, la base a été migrée, le modèle d’IA a été remplacé. Nous avons les logs. Nous avons le code de notre application. Mais l’événement qui a produit le bug était un concert, et des concerts, il reste les enregistrements, pas les concerts.

C’est la métaphore qui rend, je crois, le saut ontologique en cours. Le logiciel contemporain n’est plus un disque, c’est un concert.

Le disque est un artefact stable, conservable, comparable, doté d’une identité dans le temps. Le concert est un événement distribué dans l’espace et le temps, coproduit par de nombreuses agences en temps réel, irrépétible, dont on peut avoir des traces mais pas d’originaux. Quand on réécoute l’enregistrement d’un concert de Keith Jarrett de 1975, on écoute un artefact dérivé, pas le concert — qui a eu lieu une seule fois et est terminé. Idem pour une appli SaaS aujourd’hui.

Ce que l’utilisateur a vécu hier à 11h est un événement coproduit par l’application, le navigateur, la latence du réseau, la version courante du LLM sous-jacent, la configuration de douze API tierces, un rate limit qui à cet instant exact avait une valeur. Cet événement n’est pas reproductible, pas conservable, pas ontologiquement un objet. C’est, justement, un concert.

L’objection et la copie qui n’est plus

Quelqu’un objectera ici que la distinction est exagérée : en 1998 aussi, le logiciel tournait sur un OS dépendant de drivers et de matériel ; la contingence runtime existait alors aussi ; tout usage d’une application a toujours été en quelque mesure un événement et non un objet.

L’objection est partiellement correcte, et la prendre au sérieux est important pour éviter de transformer le diagnostic en nostalgie. La différence qui change tout, cependant, est unique, et c’est celle que le droit n’a pas encore métabolisée.

En 1998 il existait toujours une copie de l’artefact. Au sens le plus strict, dans le coffre du fournisseur ou sur les disques durs des utilisateurs ou dans l’archive d’un archiviste numérique, il y avait un objet matériel contenant le logiciel sous sa forme autonome. Cette copie était le point de contact entre le produit juridique et l’événement exécutif. Le point archimédien permettant de revenir en arrière, examiner, comparer, juger. Ce qui permettait au juriste de dire « ce produit était défectueux » parce qu’un produit existait.

Aujourd’hui, cette copie n’existe plus, et pas par négligence ou mauvais choix, mais par construction. L’application SaaS du fournisseur X, à 14h23 d’un mardi d’il y a trois mois, n’existe dans aucune sauvegarde, aucun coffre, aucune archive. N’existe que la possibilité de reconstituer, de manière approximative et partielle, ce qu’elle aurait dû être, en croisant logs, versions du code, configurations des dépendances, poids des modèles, état de la base.

C’est une reconstitution archéologique, pas un accès à l’objet. Et même portée à son terme, elle aboutirait à autre chose — un modèle de l’application de ce moment, pas l’application de ce moment. Le produit, au sens bicentenaire du terme juridique, a disparu. Ce qui existe à sa place n’a jamais été nommé.

Le corpus européen et son désalignement

Le législateur européen, il faut le reconnaître, s’est aperçu que quelque chose clochait. Ces dernières années, il a produit un paquet impressionnant de normes qui tentent d’attraper le nouvel objet avec les outils disponibles.

Le Cyber Resilience Act, en vigueur depuis décembre 2024, applicable pleinement en décembre 2027, introduit le security by design/default pour les produits avec éléments numériques, impose des obligations de support sur tout le cycle de vie, exige la fourniture d’un Software Bill of Materials. La nouvelle PLD étend explicitement la responsabilité aux défauts de cybersécurité et aux dysfonctionnements des mises à jour. L’AI Act, en vigueur depuis le 1er août 2024 avec application générale au 2 août 2026 et certaines provisions au 2 août 2027, classifie les systèmes d’IA par risque et impose obligations de documentation, transparence, évaluation de conformité. À cela s’ajoutent NIS2, DORA, Data Act, EAA.

Mis bout à bout, ils forment le corpus normatif le plus ambitieux jamais bâti pour discipliner la production de logiciel, un effort sérieux, techniquement informé, culturellement important. L’erreur serait de les banaliser comme bureaucratie ou frein à l’innovation, à la mode d’une certaine vulgate libertarienne californienne. La thèse de cet essai est plutôt que, tout en étant sérieux et importants, ces instruments tentent de capturer le concert avec les catégories du disque, et le désalignement catégorial est destiné à produire des conséquences qu’on commence seulement à entrevoir.

Le cas du Software Bill of Materials est paradigmatique de cette difficulté. Le SBOM est un document énumérant tous les composants entrant dans un logiciel, leurs versions, leurs dépendances, leurs licences. Sur le papier, un outil parfaitement raisonnable, l’équivalent logiciel de la liste d’ingrédients sur les emballages alimentaires.

En pratique, le SBOM est la photographie d’un concert, avec toutes les limites épistémiques que cette condition implique. Une photo du concert n’est pas le concert, c’est déjà un autre objet, dérivé, partiel, daté. À l’instant exact où la photo est prise, le concert change déjà, et au dixième de seconde suivant les dépendances transitives ont pu se mettre à jour, la version de l’API externe peut avoir changé, le poids du modèle peut avoir été remplacé.

Le SBOM capture un état, mais le logiciel contemporain n’a pas d’états stables — seulement des flux. La norme demande donc aux développeurs de maintenir la photographie à jour, ce qui génère des processus de continuous SBOM generation, avec des outils qui produisent un SBOM à chaque build, à chaque deploy, idéalement en temps réel. Résultat paradoxal : le document censé capturer l’identité du produit se multiplie en milliers de snapshots quotidiens, dont chacun est déjà obsolète au moment de sa génération. Le SBOM ne capture pas le produit, parce que le produit n’existe pas. Il capture le flux, sous forme de fragments discrets, et chaque fragment est un document juridiquement pertinent. La charge documentaire qui en découle est énorme, et sa valeur probante, quand il s’agit de reconstituer qui était responsable de quoi à un moment précis, est bien moins nette que ce que les législateurs ont supposé.

Le même problème, aggravé par la nature stochastique des modèles, se pose pour l’AI Act. L’article 10 demande que les datasets d’entraînement soient documentés, traçables, gouvernés par des critères de qualité. L’article 15 demande que les systèmes à haut risque soient exacts, robustes, cybersécurisés. L’article 72 impose le monitoring post-market. Chaque obligation a du sens prise isolément, et renvoie à des pratiques que la meilleure ingénierie du machine learning devrait déjà adopter.

Ce que les législateurs n’ont pas pleinement absorbé, c’est que le modèle qu’un fournisseur offre aujourd’hui via API est un objet dont l’identité dans le temps est, au mieux, conventionnelle. Les poids sont mis à jour, le RLHF est affiné, les guardrails modifiés, et ce qui continue à s’appeler GPT-4 ou Claude Opus ou Gemini Ultra est, du point de vue du comportement observable, un objet différent de ce qui portait le même nom il y a six mois.

Demander la documentation du training, c’est demander la documentation de quelque chose qui, au moment où la documentation est produite, peut déjà avoir été dépassé par un autre training. Le monitoring post-market est une excellente pratique, mais il présuppose un marché où le produit est le même au moment de la vente et de l’usage, ce qui n’est presque jamais vrai pour les modèles de langage.

L’AI Act n’est pas faux — c’est une des réponses régulatoires les plus articulées jamais tentées à cette échelle. Il hérite simplement du droit de la responsabilité du fait des produits une série de présupposés ontologiques que l’objet qu’il cherche à régler ne satisfait pas, et la tension entre les présupposés et l’objet se déchargera dans les années à venir sur les épaules des praticiens, sous forme d’obligations à valeur ambiguë, de documents dont le rapport au réel sera difficile à établir, de contentieux où le différend se réduira à un débat sur la représentativité d’un snapshot.

CrowdStrike, 19 juillet 2024

Un exemple récent, d’une portée telle qu’il est entré dans les cours de risk management du monde entier, aide à voir concrètement ce que cela signifie.

Le 19 juillet 2024, une mise à jour défectueuse du capteur Falcon de CrowdStrike a provoqué le crash simultané d’environ 8,5 millions de machines Windows à travers la planète, avec un boot loop nécessitant une intervention manuelle sur chaque appareil. Aéroports paralysés, hôpitaux repassés au papier, banques inopérantes, télévisions bloquées, appels d’urgence non routés. Delta Airlines à elle seule a déclaré plus de 500 millions de dollars de dommage direct, les seules Fortune 500 ont déclaré des pertes non assurées de l’ordre de 5,5 milliards, avec des estimations globales que diverses sources placent dans les dizaines de milliards.

Dans le contentieux qui a suivi — toujours ouvert dans plusieurs juridictions —, toute la question s’est concentrée sur : qui était responsable.

• CrowdStrike, qui avait diffusé une mise à jour avec un défaut détectable par n’importe quel test sérieux.
• Microsoft, qui avait permis à un logiciel tiers d’opérer avec des privilèges kernel suffisants pour mettre l’OS en boot loop.
• Les organisations déployeuses, qui acceptaient les mises à jour en push automatique sans phases canary.
• Les régulateurs européens, selon la défense de Microsoft, qui des années plus tôt avaient imposé l’ouverture du kernel pour des raisons de concurrence.

Chacune de ces quatre attributions, prise isolément, capte un aspect réel. Aucune, prise isolément, ne raconte ce qui s’est passé. Ce qui s’est passé, c’est un échec d’orchestration — un événement où de nombreux acteurs avaient, chacun à son degré, une influence effective sur le comportement runtime, et où aucun n’avait exercé cette influence proportionnellement aux conséquences possibles.

Le droit actuel n’a pas d’outils adéquats pour distribuer la responsabilité ainsi, et le contentieux glisse en conséquence vers des scénarios où gagne qui a les meilleurs avocats ou la position contractuelle la plus défendable — autre manière de dire que le droit a renoncé à dire quelque chose de substantiel sur l’incident. Un cas comme CrowdStrike, lu à la lumière de la catégorie d’assemblage responsable que je tente d’esquisser, aurait dû produire un arrêt distribuant la responsabilité en quotités identifiables entre les acteurs en fonction de leur blast radius et de leur contrôle effectif, et créer un précédent utilisable pour les incidents futurs, qui seront certainement nombreux. Rien de tout cela n’arrive, parce que la catégorie pour le faire n’existe pas.

Latour, Ricœur et la pluralité de l’action

L’assemblage responsable n’est pas une invention ex nihilo, mais l’adaptation au domaine juridique de réflexions que la philosophie du XXᵉ a développées ailleurs.

Bruno Latour, avec l’actor-network theory, a montré dès les années 80 que les actions complexes n’ont jamais un seul agent, mais émergent de réseaux d’acteurs humains et non humains dont l’analyse exige de suspendre l’obsession du sujet individuel et de suivre les connexions effectives. Son exemple canonique du dos d’âne, le sleeping policeman, est éclairant : le dos d’âne enforce la limitation indépendamment du policier, agissant comme acteur non humain doté d’agency.

Le ralentissement de l’auto est coproduit par le conducteur, le dos d’âne, le code de la route, la peur d’abîmer la suspension, la culture partagée qui reconnaît le dos d’âne comme signal de prudence. Aucun de ces acteurs, seul, n’explique le ralentissement. Le droit positif tend à découper la responsabilité sur le conducteur pour des raisons pratiques, mais la compréhension philosophique de l’événement exige de voir les cinq ensemble. Le pas que le droit n’a pas fait, et que la philosophie a fait il y a quarante ans, c’est d’accepter que cette distribution de l’agence soit la norme, pas l’exception, et d’en tirer les conséquences.

Paul Ricœur, dans Soi-même comme un autre (1990), a ajouté un volet : l’imputation est un acte narratif qui exige de reconstruire une histoire plausible de causation, et quand l’histoire plausible implique de nombreux agents, la narration imputative ne peut se réduire à un seul sujet sans trahir la vérité de l’événement. L’imputation, pour Ricœur, est une herméneutique de la responsabilité, et comme toute herméneutique elle exige de la patience, de l’écoute des différents niveaux, le refus des simplifications.

Le droit contemporain de la responsabilité du fait des produits simplifie trop, parce qu’il a hérité d’une grammaire narrative dix-neuviémiste où le producteur était un, identifiable, imputable. Reconstruire l’imputabilité pour le logiciel contemporain, c’est accepter la nature plurielle de l’action et la restituer dans le texte de l’arrêt.

L’assemblage responsable

Si l’on s’arrête là, le diagnostic risque d’apparaître pessimiste ou purement critique. Le point que je veux essayer de développer est l’opposé : si le concept de produit ne tient plus sa fonction d’attribution de responsabilité, il devient nécessaire d’imaginer la catégorie de remplacement.

Cette tâche ne peut être déléguée ni aux juristes purs, qui n’ont pas de contact avec le runtime des systèmes réels, ni aux ingénieurs purs, qui tendent à considérer le droit comme une nuisance externe plutôt qu’une tentative d’attribuer un sens moral à ce qu’ils font. La catégorie doit être pensée à quatre mains, par qui a la pratique du code et la lecture du droit, et partir du fait que le logiciel contemporain est une orchestration, un assemblage, un événement distribué — pas un objet.

Je propose de l’appeler, provisoirement, assemblage responsable.

Qu’est-ce qu’un assemblage responsable, en première approximation. Une configuration de composants, humains et non humains, organisés autour d’une fonction spécifique offerte à un utilisateur, dont aucun participant ne détient le contrôle intégral mais dont chacun exerce un degré identifiable d’influence effective sur le comportement observable en runtime.

La responsabilité, dans cette grille, ne suit plus la titularité formelle (« qui a contracté répond de tout »), ni l’origine historique des composants (« si le bug est dans la lib importée, c’est la faute du mainteneur »). Elle suit le gradient de l’influence effective.

Qui a pu, au moment du dommage, modifier le comportement du système par une action technique ciblée, répond proportionnellement au degré de cette possibilité. Le fournisseur du modèle d’IA qui aurait pu mettre à jour les guardrails et ne l’a pas fait répond d’une quotité. L’intégrateur qui a choisi ce modèle pour une fonction sensible sans évaluer adéquatement les risques répond d’une autre. L’utilisateur qui a configuré le système anormalement, contournant les avertissements, répond d’une troisième. Aucun ne répond de tout, aucun ne répond de rien — chacun répond de sa portion d’orchestration.

Formule simple à énoncer, infernalement complexe à implémenter, comme c’est naturel pour toute catégorie juridique nouvelle dans ses premières décennies.

Les objections viennent vite. Première : l’influence effective est difficile à mesurer, et un système juridique fondé sur un concept aussi fuyant serait source d’incertitude. Vraie, mais moins grave qu’il n’y paraît : le droit civil opère déjà avec des concepts fuyants — faute, prévisibilité, causation adéquate — et a développé des outils opérationnels pour les manier.

L’influence effective sur un système distribué est mesurable via ce que les ingénieurs appellent blast radius — l’estimation de l’ampleur des conséquences d’une action technique. Un fournisseur d’API LLM a un blast radius qui couvre potentiellement tous ses intégrateurs, parce qu’une modification se propage instantanément. Un intégrateur a un blast radius limité à ses utilisateurs, qui peut s’amplifier si son application est elle-même infrastructure d’autres applications.

Il existe des métriques techniques, grossières mais traitables, pour estimer le blast radius de chaque acteur, et la doctrine pourrait construire dessus une taxonomie graduée de la responsabilité. Pas plus fuyant que ne l’étaient les doctrines de la faute aquilienne au XIXᵉ avant que des décennies de jurisprudence ne les rendent opérationnelles.

Deux déformations à résister

La seconde objection est plus politique et vient de deux directions opposées, toutes deux intéressées.

La première : les milieux californiens de la grande tech, qui ont construit ces vingt dernières années une narration selon laquelle la nature open source et componentisée du logiciel rendrait impossible toute attribution de responsabilité particulière, et que la responsabilité devrait donc se limiter aux termes contractuels acceptés explicitement. Selon cette lecture, si un utilisateur subit un dommage d’une application qui utilise une lib open source d’auteur anonyme, hébergée sur un cloud qui décline toute responsabilité dans ses CGU, alors personne ne répond de rien — ou seulement qui a délibérément assumé la responsabilité par contrat.

C’est la doctrine de l’irresponsabilité distribuée, confortable rente de position pour qui occupe les nœuds les plus centraux de l’orchestration : on encaisse la valeur, on externalise les risques. L’assemblage responsable s’y oppose frontalement, parce qu’il refuse l’idée que l’absence de titulaire formel équivale à l’absence de responsabilité substantielle. Si ton modèle est le composant critique de milliers d’applications en aval, ta responsabilité ne dépend pas du fait que tu as ou non signé un contrat avec les utilisateurs finaux. Elle dépend de ton rôle dans l’orchestration, et ce rôle est objectivement mesurable.

L’autre direction : le formalisme européen continental, dans la doctrine du titulaire absolu.

Selon cette tradition, le titulaire du traitement, ou le fournisseur du service, ou le déployeur du système d’IA, répond de tout ce qui se produit dans la chaîne, indépendamment d’où la non-conformité est née. Doctrine intuitivement égalitaire — elle protège l’utilisateur en lui assurant que quelqu’un répondra toujours. Mais en pratique, elle produit deux distorsions sérieuses.

La première : elle décharge sur le titulaire une responsabilité dont il n’a pas le contrôle technique, le contraignant à se défendre contre des contentieux pour des dysfonctionnements issus de composants qu’il n’a pas écrits, pas choisis, ne peut inspecter. La seconde : elle déresponsabilise les nœuds en amont — ceux qui ont l’influence la plus systémique — parce qu’ils savent que leur quote-part sera formellement déchargée sur le déployeur final, et que les tribunaux continueront à pointer du doigt celui qui occupe la position la plus visible.

L’assemblage responsable s’oppose aussi à cette doctrine. La position formelle du titulaire n’épuise pas la question, et une distribution seulement apparente du fardeau, qui se concentre dans les faits sur le nœud le plus accessible, maintient les choses telles qu’elles sont dans les rapports de force réels de l’industrie.

La proposition se trouve donc dans un territoire inconfortable pour les deux sensibilités dominantes, et c’est précisément pour cela qu’elle mérite d’être articulée. Qui travaille dans le software sait que l’idée d’une responsabilité purement contractuelle est une fiction utile à qui est dans la Silicon Valley et une expérience quotidienne d’impuissance pour qui est à Pescara, Milan ou Francfort et doit livrer un système qui fonctionne réellement sous des contraintes réelles. En même temps, qui travaille avec la compliance européenne sait que la doctrine du titulaire absolu transforme le déployeur en fusible juridique — fonction économique : sauter quand le système se rompt, permettant aux composants amont de continuer à produire des externalités.

Le logiciel contemporain a besoin d’une catégorie qui ne soit ni l’une ni l’autre, qui distribue la responsabilité de façon à refléter la distribution effective du pouvoir technique. Pas une distribution symétrique — le pouvoir technique n’est pas symétrique. Pas une concentration sur le titulaire — le pouvoir n’est pas concentré là. Une distribution qui suit le gradient de l’influence effective, avec des métriques transparentes, une doctrine pratique que les tribunaux puissent manier, une ratio que les praticiens reconnaissent comme adhérente à leur expérience de travail.

Certains domaines bougent déjà dans cette direction, sans que personne ne nomme la chose. Le RGPD, à l’article 28 et dans les lignes directrices de l’EDPB sur la chaîne des sous-traitants, a timidement commencé à reconnaître la gradation de responsabilité le long de la chaîne du traitement — formellement et sans l’appareil conceptuel nécessaire. Les AIPD, sérieusement faites, contiennent en germe un blast-radius appliqué à la donnée personnelle.

NIS2 introduit pour les fournisseurs de services managés des obligations qui reconnaissent leur rôle systémique. L’AI Act, avec sa distinction provider/deployer/importer/distributor, tente une taxonomie des rôles qui, encore trop rigide, va dans le sens d’une distribution non centrée sur le titulaire.

Aucun de ces instruments n’a encore formulé explicitement le principe de l’influence effective comme gradient de responsabilité, mais tous contiennent les traces d’un repensement qui n’attend qu’une systématisation doctrinale. L’impression : il manque quelque chose de comparable à ce que fut le neighbour principle pour Lord Atkin — une formulation synthétique, mémorable, opérationnelle, qui oriente cinquante ans de jurisprudence à venir. Qui l’écrira aura fait pour le XXIᵉ ce que la House of Lords fit pour le XXᵉ.

Pour que cette formulation puisse être écrite, il faudra une figure d’intellectuel qui n’existe pratiquement pas aujourd’hui. Pas des juristes purs (la grammaire des systèmes distribués ne s’apprend pas en faculté de droit). Pas des ingénieurs purs (la grammaire du droit et son histoire bicentenaire de catégories ne s’apprend pas en computer science).

Il faut des hybrides, des figures de frontière qui aient pratiqué les deux métiers assez longtemps pour en avoir compris les logiques internes et les limites, et qui soient prêts à imaginer ce qu’aucun des deux corpus, seul, ne saurait imaginer. En Italie, cette figure n’a pas encore de nom consolidé. Dans les pays anglo-saxons s’est affirmé ces dernières années le compliance engineer ou technical counsel, mais ce sont encore des définitions qui se limitent à mettre en communication les deux cultures sans en construire vraiment une troisième.

Il faut quelque chose de plus ambitieux : une figure qui ne traduise pas seulement le jargon technique en jargon juridique et inversement, mais qui élabore des catégories nouvelles capables de dire ce qu’aucun des deux jargons d’origine ne saurait dire. Métier en partie théorique (formation philosophique pour manier des catégories abstraites) et en partie pratique (expérience quotidienne du deployment, des dépendances transitives, des rétrocompatibilités cassées par un minor release du fournisseur, des stack traces ambiguës qui ne disent pas qui est en faute). Sans expérience pratique, les catégories abstraites restent suspendues. Sans formation abstraite, l’expérience pratique s’épuise en fatigue et tickets fermés.

La troisième voie est difficile non parce qu’elle exige des dons rares, mais parce que le marché du travail ne la valorise pas, les universités ne la forment pas, les entreprises ne l’organisent pas. Elle existe par seule volonté individuelle, et c’est précisément pour cela que qui la pratique a une responsabilité intellectuelle disproportionnée à sa position formelle.

Du Bill of Materials au Bill of Accountability

Revenons au problème concret du départ : comment attribuer la responsabilité pour un dommage causé par un logiciel contemporain.

Si l’on accepte que le logiciel n’est plus un produit mais un assemblage, et que l’assemblage s’analyse selon le gradient de l’influence effective, alors le premier pas opérationnel est de bâtir une pratique de documentation de l’assemblage qui ne soit pas la photo statique du SBOM, mais une carte dynamique des relations d’influence.

Un tel outil devrait permettre de répondre, pour chaque application, à des questions comme :

• Quels composants, modifiés, changeraient le comportement observable du système.
• Quels acteurs ont la capacité technique de modifier ces composants.
• Quelles sont les obligations contractuelles et normatives qui pèsent sur chacun.
• Quelles sont les évidences (logs, audit) permettant de reconstituer ex post l’état du système à un moment précis.
• Quels canaux de communication permettent à un acteur en aval de faire arriver un signal d’alarme à un acteur en amont.
• Quels sont les délais de réponse typiques le long de la chaîne.

Le document résultant ne serait plus un bill of materials, mais quelque chose de plus proche d’un bill of accountability — une carte des pouvoirs et devoirs le long de toute l’orchestration. Le produire exigerait du travail, exigerait coopération entre acteurs qui n’ont pas toujours intérêt à coopérer, exigerait des normes pour l’imposer. Mais ce serait un outil qui nommerait le problème pour ce qu’il est, plutôt que de le réduire à un problème d’inventaire.

Trois conséquences pour qui développe

Du point de vue de la pratique quotidienne, cette ré-articulation aurait des conséquences importantes.

Première : le contrat-type, qui aujourd’hui tend à décharger toute la responsabilité sur le fournisseur final ou, au mieux, à la limiter au montant annuel payé, deviendrait un document de structure très différente. Il serait construit en aval d’une analyse de l’orchestration, avec une articulation claire des composants que le fournisseur contrôle vs. qu’il intègre seulement, des risques qu’il assume pleinement vs. dont il fait canal de transfert, des obligations informationnelles qu’il accepte vs. qu’il n’est pas techniquement à même d’honorer. Plus long, plus complexe, plus honnête — et à long terme plus défendable, parce qu’il raconte la chose telle qu’elle est.

Deuxième : le processus de développement devrait inclure, dès le début, une réflexion sur l’orchestration dans laquelle le système s’insérera, pas seulement sur les exigences fonctionnelles.

• Qui sont les acteurs amont dont nous dépendrons.
• Quelles garanties nous donnent-ils.
• Quel blast radius ont-ils à notre égard.
• Comment vérifierons-nous leurs changements.
• Comment réagirons-nous si l’un de leurs changements casse notre comportement attendu.

Aujourd’hui reléguées à quelques slides d’architecture puis oubliées, ces questions devraient devenir partie intégrante de la spec. Leur absence dans une doc projet serait un indicateur d’immaturité, comme l’est aujourd’hui l’absence d’un threat model.

Troisième — la plus intéressante culturellement, qui touche la formation. Aujourd’hui, on apprend à écrire du code qui marche, puis, si on a de la chance, à écrire du code qui marche en production. Presque personne n’apprend à écrire du code qui marche au sein d’une orchestration dont il a conscience.

La conscience de l’orchestration arrive tard, souvent par un incident, rarement comme compétence enseignée. Une formation qui prendrait au sérieux la nature distribuée du logiciel contemporain devrait partir de là — montrer dès le premier jour qu’écrire une API, c’est entrer dans une orchestration ; choisir une lib, c’est accepter un fournisseur amont ; déployer en cloud, c’est s’héberger dans une infra dont les choix d’archi sont ailleurs.

Pas pour terroriser les jeunes, mais pour les habituer à voir ce que voient les développeurs expérimentés après vingt ans de cicatrices. L’orchestration est l’objet de leur travail, pas un décor. Le code qu’ils écrivent est une participation à un concert, pas un objet autosuffisant. S’ils grandissent avec cette conscience, la question de la responsabilité n’arrivera pas comme nuisance externe, mais comme dimension intrinsèque du métier.

Quand l’écriture aussi est orchestration

À qui soupçonne que tout ceci est exagéré par la lentille du SaaS et que dans des contextes plus simples la catégorie de produit pourrait encore tenir, on peut répondre que la direction du développement AI-natif rend le problème plus aigu, pas moins.

Quand on travaille avec des outils comme Claude Code ou des pratiques comme la specification-driven development style SpecKit, le code cesse d’être l’objet que le développeur écrit directement et devient le produit d’une chaîne de génération qui part de la spec, passe par un modèle, produit un artefact et l’intègre dans une orchestration déjà distribuée. La spec écrite hier et le code généré hier, régénérés aujourd’hui par le même modèle, produiraient un code plausible mais non identique, parce que le modèle a changé.

La notion de version, déjà affaiblie par le continuous deployment, devient encore plus instable, parce qu’elle ne l’est plus seulement au temps d’exécution mais aussi au temps d’écriture. Qui développe ainsi sait que la reproductibilité exacte est un horizon régulateur, pas une propriété effective.

L’assemblage responsable, dans un monde où l’écriture du code aussi est une orchestration entre développeur, spec, modèle, toolchain et pipeline, devient la catégorie naturelle pour penser la responsabilité — la seule où l’absence d’auteur monolithique ne se traduit pas automatiquement par l’absence d’imputabilité.

La mort d’une catégorie

Reste une question à laquelle l’essai doit répondre. Est-ce qu’il a vraiment du sens de parler de la mort d’une catégorie juridique, ou ne décrit-on qu’une évolution, une transformation, une mise à jour ?

Le langage de la mort est fort, et peut sembler exagéré. La justification : une catégorie meurt au sens où Foucault le disait à propos de catégories plus générales — quand elle cesse d’organiser le champ discursif de manière productive et commence à l’entraver.

Le concept de produit, appliqué au logiciel contemporain, n’organise plus le champ, il l’entrave. Il produit des obligations qui ne correspondent pas à des pratiques, des documents qui ne représentent pas d’objets, des contentieux qui s’enlisent sur la définition de l’objet avant même de pouvoir traiter le fond.

Un concept qui entrave le champ n’est pas un concept utile, même s’il reste formellement en vigueur. Le concept d’éther luminifère, en physique de fin XIXᵉ, n’était pas faux au sens d’affirmations singulières, c’était un concept qui avait cessé d’organiser productivement le champ, jusqu’à ce qu’Einstein le retire simplement.

Le concept de produit, en droit contemporain du logiciel, est dans une phase comparable. Encore là, encore dans les textes, encore dans les prétoires. Mais il ne travaille plus. Et faire comme s’il travaillait est plus dangereux qu’admettre qu’il ne travaille pas.

Je ne dis pas que le législateur européen aurait dû attendre d’avoir la bonne catégorie avant d’intervenir. Position intellectuellement pure et politiquement impossible — et le dommage de l’absence de régulation aurait dépassé celui d’une régulation catégorialement imparfaite.

Je dis, plus modestement, que la régulation actuelle est un work in progress, que son imperfection catégoriale doit être reconnue ouvertement, et que la construction de la catégorie de remplacement n’est pas un chantier réservé aux législateurs — il appartient aussi à qui travaille quotidiennement dans le software et à qui possède en philosophie du droit les outils pour penser. Qui a les deux pieds dedans peut contribuer plus que qui n’en a qu’un. Et la contribution n’est pas un exercice académique : chaque année passée sans que la catégorie émerge est une année où le contentieux se résout par des voies formelles ne reflétant pas les responsabilités substantielles, où les fournisseurs amont continuent à transférer du risque sans en payer le prix, où les déployeurs finaux continuent à servir de fusibles sans que l’ensemble du système s’améliore.

La salle de Lord Atkin

Je me suis étendu, et qui m’a suivi mérite au moins une synthèse honnête.

Nous sommes arrivés à dire que le concept juridique de produit, bâti au XXᵉ sur une ontologie d’objets bornés, préservables, identifiables, est insuffisant pour le logiciel contemporain — qui est plutôt une orchestration de composants humains et non humains, un événement distribué plus qu’un objet, un concert plus qu’un disque.

Nous avons dit que la régulation européenne, bien que l’effort le plus sérieux jamais tenté, tente de capturer le concert avec les catégories du disque, et que cette tension produit des obligations dont la valeur juridique substantielle est ambiguë.

Nous avons dit qu’à la place de la catégorie de produit, il faut en construire une nouvelle, provisoirement appelable assemblage responsable, qui distribue la responsabilité selon le gradient de l’influence effective en runtime — pas selon la titularité formelle ni selon l’irresponsabilité distribuée.

Nous avons dit que cette construction exige une figure intellectuelle hybride, avec pratique du code et lecture du droit, que le marché ne valorise pas et qui n’existe que par volonté individuelle.

Et nous avons dit que tant que la catégorie de remplacement n’émerge pas, les contentieux continueront à se décharger par des voies formelles ne reflétant pas les responsabilités substantielles, avec des coûts réels pour qui exerce le métier honnêtement.

Le point qui mérite peut-être d’être fixé, à la fin : Lord Atkin en 1932 n’était pas un juriste pur, c’était un juge qui avait vu beaucoup de bouteilles se briser et beaucoup de gens tomber malades, et qui avait compris quelque chose de pratique sur le monde industriel que l’instrumentaire conceptuel précédent ne savait pas dire.

L’arrêt Donoghue v. Stevenson a été possible parce que quelqu’un avait tenu ensemble, dans une seule tête, l’expérience matérielle du monde industriel et la tradition conceptuelle du droit civil. Aujourd’hui, il faut tenir ensemble, dans une seule tête, l’expérience matérielle des systèmes distribués et la tradition conceptuelle du droit de la responsabilité. Tâche qu’on ne peut déléguer, et qu’on ne peut pas finir en un seul essai. Ce qu’on peut faire avec un essai, c’est tenter de nommer le problème, offrir une direction, inviter qui a des outils similaires aux miens à continuer le travail.

La bouteille de Mrs Donoghue était opaque, et dedans il y avait un escargot que personne n’avait vu. Le logiciel contemporain est encore plus opaque, et dedans il y a beaucoup plus d’escargots, et la jurisprudence qui nous protège a été écrite pour un monde où les bouteilles étaient en verre. Il est temps d’écrire la jurisprudence d’un monde où les bouteilles ne sont plus.

À l’intérieur, trois images qui me sont restées. Aaron Levie dit que dans la Silicon Valley personne ne travaille moins, plutôt l’inverse. Tyler Cowen, en économiste, soutient que tu devrais travailler beaucoup plus dur maintenant, que tu penses que l’IA dévaluera ton travail ou qu’elle le rendra plus précieux. Et puis Simon Last de Notion qui parle de nuits blanches et d’une nouvelle anxiété, la « token anxiety », un truc qui n’existait pas il y a deux ans, pas même comme concept.

Le paradoxe que swyx met au centre est simple et, justement pour ça, un peu inquiétant. Les agents font plus de travail que jamais, les benchmarks saturent, les modèles dépassent les experts humains dans des proportions qu’on aurait dites de la science-fiction il y a peu. Et pourtant, les gens qui construisent et opèrent ces systèmes n’ont jamais autant travaillé.

Et là une question s’allume que je n’arrive pas à éteindre facilement : si la promesse était « plus de productivité », pourquoi la sensation diffuse est « plus de pression » ?

L’explication confortable : ce n’est qu’une phase

L’objection la plus raisonnable est aussi celle qui me vient spontanément, si j’essaie d’être honnête. Peut-être une phase transitoire. La dynamique habituelle de la disruption : d’abord ça casse, puis ça recompose. On a vu ça avec le PC, internet, les smartphones. Les emplois changent, certains disparaissent, d’autres naissent, la productivité grimpe, et au bout, du moins pour qui pilote bien la transition, le bien-être moyen progresse.

Objection sérieuse. L’ignorer, c’est risquer de glisser dans une forme de luddisme de clavier — se convaincre que le problème est la techno elle-même, plutôt que la façon dont on l’insère dans les systèmes économiques et sociaux.

Mais il y a un point où cette objection cesse de marcher. Et ce point, pour moi, c’est le corps.

Le corps ne scale pas

Le problème n’est pas seulement de savoir si l’IA remplacera ou augmentera les knowledge workers. Le problème, c’est que le corps humain ne scale pas.

Pas comme scalent les tokens. Pas comme scale un cluster en dizaines de gigawatts. Pas comme scale la courbe d’apprentissage d’un modèle qui ingurgite une quantité énorme de connaissance en quelques semaines.

Le corps a une horloge biologique qui ne se reset pas avec un update. Il a besoin de sommeil, et si tu lui en prives pendant des mois, peut-être tu tiens encore, en apparence, jusqu’au moment où quelque chose casse. Et souvent ça casse de façons que tu n’avais pas prévues et qui ne sont pas faciles à inverser.

Il a besoin de mouvement, de lumière naturelle, de rythmes. Il n’a pas été conçu pour les trois heures du matin passées à débugger un agent qui a généré huit cents lignes de code qui « marchent », mais que tu ne comprends pas vraiment.

Ces choses ne sont pas nouvelles. La médecine du travail le dit, les neurosciences le disent, n’importe quel généraliste avec un minimum d’honnêteté intellectuelle le dit. Pourtant, dans le discours dominant sur l’IA, le corps a l’air d’un détail d’implémentation. Une contrainte legacy à contourner avec assez de caféine et de volonté.

D’où je le regarde

Je suis associé et responsable technique d’une petite ICT à Pescara. On est une dizaine. Je n’écris plus vraiment de code en production depuis un moment, en tout cas plus comme avant. Mon travail est devenu recherche, spikes stratégiques, évaluation d’architectures, et aussi compliance — mot peu sexy, mais très réel.

Je passe mes journées à comprendre où va le marché et à décider ce qui a du sens à faire et ce qui n’en a pas, pour une boîte qui n’a pas le luxe d’un round pour absorber les erreurs. Et qui a une responsabilité directe sur les personnes qui y travaillent — qui rentrent le soir, qui ont des familles, des corps, des limites.

Depuis cette position, je vois quelque chose que, peut-être, quand tu es dans le flux quotidien, tu fais plus mal à mettre au point. L’IA n’a réduit la charge de personne dans mon équipe. Elle l’a transformée.

Elle a déplacé le poids de la production de code à la supervision de code produit par d’autres — où « d’autres », ici, est un modèle statistique qui ne dort pas, ne se fatigue pas, ne tombe pas malade. Mais qui se trompe. Et se trompe de façons créatives et imprévisibles.

Détail qui me semble important, même si je n’arrive pas encore à dire à quel point. Lire du code écrit par une intelligence étrangère est un travail différent de l’écrire. Ça demande une vigilance constante. Une forme d’attention qui te tient toujours un peu en alerte.

Et cette alerte est incompatible avec une chose qui, dans le travail cognitif, est presque une protection naturelle : le flow, l’état de concentration profonde où tu n’es pas découpé, pas continuellement interrompu, pas obligé de faire un micro-jugement toutes les trente secondes.

La demande monte, le contrôle baisse

Il y a un concept en médecine du travail qui s’appelle « job strain », dans le modèle de Karasek. En résumé, il décrit la combinaison la plus toxique : haute demande de travail et faible contrôle sur sa propre activité.

Et j’ai l’impression que l’introduction massive des agents IA fait exactement ça : elle modifie le rapport entre demande et contrôle.

La demande augmente parce que, si les outils sont plus rapides, l’attente d’output grimpe avec eux. « Si l’agent peut le faire en une heure, pourquoi on y met une journée ? » est une question qui arrive presque automatiquement, souvent sans méchanceté, juste par inertie.

Le contrôle baisse parce que tu délègues une part croissante du processus à des systèmes que tu ne comprends pas en profondeur et qui changent toutes les quelques semaines. Même quand tu les comprends, tu les comprends d’une façon différente de celle dont tu comprends un collègue ou un composant logiciel traditionnel. Une compréhension plus probabiliste, plus fragile.

En ce sens, la « token anxiety » ne me semble pas une mode lexicale. Elle me semble un symptôme. L’anxiété, après tout, est une fonction adaptative. Quand elle apparaît à l’échelle industrielle, ce n’est peut-être pas un problème individuel. C’est peut-être un signal système.

« Si on ralentit, la Chine ne ralentit pas »

Arrive presque toujours une autre objection, et elle aussi a un noyau de vérité. Si on ralentit, d’autres ne ralentissent pas. Si on met des limites, d’autres poussent. Et dans une course mondiale, qui arrive premier gagne.

Mais je me demande s’il n’y a pas une erreur de catégorie cachée dans cette phrase.

La compétition entre nations et entreprises est une compétition entre systèmes, pas entre individus. Un système qui brûle les personnes qui le composent n’est pas un système compétitif. C’est un système qui consomme son capital le plus précieux : l’intelligence et la créativité d’humains qui ne fonctionnent bien que quand ils sont sains, reposés, et motivés par autre chose que la peur.

L’histoire du software est pleine d’entreprises qui ont « gagné » à court terme grâce au crunch et perdu à moyen terme. Parce que les meilleurs partent, ou tombent malades, ou cessent simplement d’avoir des idées. Un cerveau épuisé n’est pas un moteur à presser, c’est un écosystème qui s’effondre.

Le premier problème est peut-être dans le thorax

Si le sujet n’est pas seulement la course aux benchmarks, alors quel est le premier problème ?

Je crois qu’il est sous notre nez, ou plutôt dans notre thorax. Le problème le plus précieux est de comprendre comment intégrer des outils de puissance extraordinaire dans la vie professionnelle sans que la vie professionnelle dévore la vie.

Pas un problème technique, ou pas seulement. C’est un problème de design organisationnel, de culture managériale, de politique du travail. Et au bout, c’est un problème philosophique, parce qu’il t’oblige à décider de ce qui vaut la peine d’être fait avec le temps qu’on a. Qui est fini d’une manière qu’aucune technologie ne peut changer.

Une chose personnelle, qui pourtant pèse

J’ai un fils. Pas un argument logique, un fait biographique. Mais les faits biographiques pèsent parfois plus que les arguments.

Quand le soir je referme l’ordi et que je le regarde, je pense que tout le code écrit dans la journée, même celui « multiplié » par les agents, ne vaut pas une heure de ce temps. Pas parce que le travail ne compte pas. Il compte. Mais parce que ce temps est irrécupérable d’une façon dont le code ne l’est pas.

Le code se réécrit. Une enfance, non.

Je sais que dans certains milieux ça sonne comme de la faiblesse. Comme un manque d’ambition. Comme du sentimentalisme qui ne survit pas à la prochaine évaluation marché. Pourtant, peut-être, c’est le contraire. Peut-être la vraie ambition est de bâtir des systèmes, des entreprises et des vies qui durent.

Et durer demande de prendre soin du moyen par lequel tout le reste advient. Le corps humain, avec son besoin non négociable de repos, de relation, et d’un temps qui ne soit pas mesuré en tokens par seconde.

L’alignement qu’on ne regarde pas

L’industrie de l’IA aime parler d’alignement, de comment faire en sorte que les modèles fassent ce qu’on veut.

Mais je me demande si le premier problème d’alignement ne concerne pas les modèles. Il nous concerne, nous.

Nous bâtissons une économie de l’attention et de la productivité où les incitations sont souvent désalignées par rapport à ce que l’on sait nécessaire à la santé humaine. On dort peu, on bouge peu, on s’arrête peu. Et on essaie de compenser avec la techno — apps de méditation, trackers de sommeil, compléments.

Comme si on avait créé un système productif qui ne produit plus de bien-être comme effet collatéral du travail, et qu’on s’étonnait ensuite qu’une industrie du bien-être naisse pour réparer les dégâts.

Une direction, pas une solution

Je n’ai pas de solution propre, et je me méfie de qui en propose. Mais une direction, je l’ai.

Prendre au sérieux que la santé et le temps humain sont la contrainte primaire. Pas l’efficacité des modèles, pas la vitesse de déploiement, pas le nombre de lignes de code générées par heure.

Chaque décision d’organisation, chaque sprint planning, chaque architecture devrait aussi être évaluée avec une question très concrète : combien de vie ça coûte ?

Et si la réponse est « trop », alors ce n’est peut-être pas le bon problème. Ou pas le bon moment. Ou pas la bonne manière.

Cela ne signifie pas « travailler moins » au sens trivial. Cela signifie travailler en sachant que le système le plus sophistiqué de l’univers connu n’est pas un LLM. C’est le cerveau humain qui l’a conçu. Et ce cerveau fonctionne selon des règles qu’on n’a pas écrites et qu’on ne peut pas réécrire à volonté.

Ce dernier souffle, peut-être, n’est pas le dernier souffle de l’humanité. C’est peut-être le dernier souffle d’une manière de travailler qui traite les personnes comme des ressources fongibles dans un pipeline d’optimisation.

S’il en est ainsi, peut-être qu’on ne devrait pas chercher à le prolonger. Peut-être qu’on devrait le laisser partir et apprendre à respirer autrement. D’une façon qui tienne compte du fait qu’on est faits de chair, de temps et de relations. Et qu’aucun agent, aussi puissant soit-il, ne pourra jamais vivre à notre place.

L’idée est élégante, et l’article qui la défend est solide. Un récent papier de Brandon Janes sur Towards Data Science, intitulé « Behavior is the New Credential », raconte comment les systèmes de biométrie comportementale deviennent le standard du secteur bancaire. Le point de départ : une étude de 2012 de Berkeley, Touchalytics, qui a démontré qu’onze scrolls sur smartphone suffisent à identifier un utilisateur précis dans un groupe de 41 personnes, sans erreur. Trente caractéristiques comportementales uniques : longueur du geste, vitesse, courbure, trajectoire, temps entre scrolls, et même la zone du doigt utilisée.

La théorie sous-jacente est celle du contrôle moteur computationnel, champ interdisciplinaire entre neurosciences, biomécanique et informatique. Les corrections inconscientes que notre cerveau opère pendant chaque geste — ces micro-ajustements qui se déroulent à l’échelle de la milliseconde — sont si individuelles que le profil comportemental d’une personne est presque impossible à reproduire. Paradoxalement, c’est ce que nous percevons comme « robotique » (ces corrections neurales automatiques) qui rend chacun de nous irréductiblement humain.

Pourquoi les vieilles défenses ne suffisent plus

Le contexte qui rend cette transition nécessaire est concret et documenté. Les malwares modernes ont atteint des capacités qui rendent obsolètes les mécanismes traditionnels de vérification. Des outils comme ProKYC, un deepfake utilisé dans le cybercrime, permettent de passer 2FA, reconnaissance faciale et même les vérifications vidéo en temps réel. BingoMod, un trojan d’accès distant distribué par SMS de phishing, se déguise en antivirus sur Android et permet à un attaquant distant d’intercepter credentials, messages et OTP, jusqu’à exécuter des virements depuis l’appareil infecté.

Quand l’appareil est compromis, du point de vue de la banque tout paraît normal : empreinte de l’appareil correcte, IP correcte, codes MFA qui rentrent. La vérification traditionnelle, qui opère en un instant unique (le login), ne suffit plus. Le périmètre de sécurité n’est plus le portail d’entrée. C’est la session entière.

Voilà où entre la biométrie comportementale, qui opère comme authentification continue. Les modèles d’anomaly detection, construits sur le profil spécifique de chaque utilisateur, surveillent la session du début à la fin. Quand les signaux de risque montent, le système peut demander des vérifications additionnelles ou bloquer la transaction. Quand le comportement est cohérent, la session continue sans interruption. Le résultat, ironiquement, est une meilleure UX : moins d’OTP, moins d’interruptions, plus de fluidité. Sécurité passive plutôt qu’active.

L’envers du décor

Jusqu’ici, le récit de l’industrie de la cybersécurité. Récit qui fonctionne, techniquement fondé, opérationnellement efficace. Mais récit qui évite systématiquement une question : que signifie, du point de vue des droits fondamentaux, transformer le comportement humain en credential ?

Partons d’un fait normatif que l’article de Janes ne mentionne pas. Le RGPD, à l’article 4(14), définit les données biométriques comme « les données à caractère personnel résultant d’un traitement technique spécifique, relatives aux caractéristiques physiques, physiologiques ou comportementales d’une personne physique, qui permettent ou confirment son identification unique ». Mot-clé : comportementales. Le législateur européen a explicitement inclus les données comportementales dans la définition. L’article 9 classe ensuite les données biométriques comme « catégorie particulière » de données personnelles, dont le traitement est en principe interdit, sauf exceptions précises : consentement explicite, intérêt public substantiel, protection d’intérêts vitaux.

Ce qui veut dire que tout système de biométrie comportementale opérant dans l’UE traite des données de catégorie spéciale. Pas des données personnelles génériques. Des données qui exigent consentement explicite, AIPD, limitation des finalités, minimisation, droit à l’effacement.

La question qu’aucun vendor ne veut traiter : comment concilier le droit à l’effacement avec un profil comportemental construit par analyse continue de milliers de micro-interactions ? Tu peux effacer un profil. Mais peux-tu effacer la connaissance dérivée, une fois qu’elle a servi à entraîner un modèle ? Le RGPD pose des questions précises sur la minimisation et la limitation des finalités quand les données ont été utilisées pour entraîner des modèles d’IA.

La double contrainte de l’AI Act

Le tableau se complique avec l’AI Act, dont le régime des systèmes à haut risque s’applique pleinement à partir d’août 2026. L’intersection RGPD/AI Act crée un cadre normatif stratifié pour la biométrie.

L’AI Act distingue plusieurs types de systèmes biométriques. L’identification biométrique à distance en temps réel est interdite aux forces de l’ordre, sauf exceptions limitées. Les autres systèmes d’identification biométrique à distance sont à haut risque. Les systèmes de catégorisation biométrique inférant des attributs sensibles (race, opinions politiques, appartenance syndicale, orientation sexuelle) sont interdits. Les systèmes de reconnaissance d’émotions sont interdits sur le lieu de travail et à l’école, et à haut risque ailleurs.

Où se situe la biométrie comportementale bancaire dans cette taxonomie ? L’AI Act exclut explicitement de la définition d’identification biométrique à distance les outils de vérification biométrique qui confirment qu’une personne est bien celle qu’elle prétend être, à condition qu’ils exigent la participation active de l’individu. Mais la biométrie comportementale est par définition passive. L’utilisateur ne « participe pas activement » à son authentification. Le système l’observe pendant qu’il fait autre chose. Cette zone grise entre vérification active et surveillance passive est précisément le terrain où les droits fondamentaux commencent à craquer.

Élément additionnel. L’AI Act interdit les systèmes d’IA qui classifient les personnes selon leur comportement social, lorsque cette classification produit un traitement défavorable dans des contextes non liés au contexte initial de collecte, ou un traitement disproportionné par rapport à la gravité du comportement. La frontière entre « authentification comportementale anti-fraude » et « profilage comportemental pour classer les utilisateurs » n’est pas aussi nette que l’industrie aimerait le faire croire.

Function creep : le risque structurel

L’histoire de la technologie nous apprend que les systèmes construits pour un objectif tendent à étendre leur portée dans le temps. Phénomène connu sous le nom de function creep, particulièrement insidieux dans la biométrie comportementale.

Un système qui aujourd’hui analyse comment tu fais défiler une page pour vérifier que c’est bien toi pourrait demain utiliser les mêmes données pour inférer ton état émotionnel, ton niveau d’attention, ta condition cognitive, ta propension au risque financier. Les données comportementales sont extraordinairement riches en information implicite. Le rythme de frappe peut révéler anxiété ou fatigue. La vitesse de scroll peut indiquer intérêt ou ennui. La pression du toucher peut suggérer irritation ou calme.

Les banques, qui utilisent aujourd’hui ces données pour la prévention de la fraude, sont assises sur un patrimoine informationnel dont la valeur potentielle dépasse de loin la sécurité des transactions. La tentation de les monétiser, ou de les utiliser à des fins commerciales (personnalisation, scoring crédit, profilage assurantiel), est une force économique que les seules policies internes peineront à contenir à long terme.

En Australie, une base biométrique conçue pour prévenir la criminalité transfrontalière a ensuite été utilisée pour identifier des personnes ayant perdu leurs documents dans des incendies. Là, l’extension d’usage avait une intention bénigne. Mais le précédent est posé : une fois que la donnée existe et que le système est opérationnel, les finalités s’élargissent.

Le corps informatisé

Il y a une dimension plus profonde, qui dépasse le droit et touche à l’anthropologie de la technique. La biométrie comportementale transforme la façon dont nous interagissons avec nos appareils en donnée d’identification permanente. Le National Research Council américain a décrit cela comme la création d’un « corps informatisé » : un corps qui n’est plus représenté par ses caractéristiques anatomiques observables, mais par les informations numériques sur le corps conservées dans des bases.

Quand ta façon de faire défiler une page devient un credential, ton geste inconscient devient une donnée. La spontanéité de ton mouvement est captée, analysée, modélisée, archivée. Tu ne fournis pas activement une information, comme quand tu tapes un mot de passe. Tu vis simplement, et le système extrait de la valeur de ton existence ordinaire.

Shoshana Zuboff a décrit cette dynamique comme la caractéristique fondamentale du capitalisme de surveillance : l’appropriation de l’expérience personnelle et sa transformation en données comportementales, utilisées ensuite pour prédire et modifier le comportement lui-même. La biométrie comportementale pour la cybersécurité est, en un sens, la version « gentille » de ce mécanisme. Mais le mécanisme est le même. Et la distance entre la version gentille et les versions moins gentilles n’est qu’une question de finalités déclarées — qui peuvent changer.

L’asymétrie du consentement

Aspect particulièrement problématique : la nature du consentement dans ces systèmes. Le RGPD exige un consentement « libre, spécifique, éclairé et univoque », avec un fardeau encore plus lourd pour les catégories spéciales. Mais comment un consentement à un système de biométrie comportementale dans ton appli bancaire peut-il être réellement libre, quand l’alternative est de ne pas pouvoir accéder à ton compte courant ?

Les autorités de protection des données européennes ont déjà traité cette question dans des contextes analogues. L’autorité néerlandaise a sanctionné une entreprise pour 725 000 € parce que les salariés percevaient le scan d’empreintes comme une obligation, rendant le consentement non libre. L’autorité suédoise a sanctionné une école pour l’usage de la reconnaissance faciale au pointage, soulignant le déséquilibre de pouvoir entre l’institution et les élèves.

Pour la biométrie comportementale bancaire, le déséquilibre est analogue. Le service bancaire n’est pas optionnel dans la société contemporaine. Si la banque déploie l’authentification comportementale, le client n’a pas d’alternative réelle au consentement. La dynamique ressemble plus à une condition imposée qu’à un choix éclairé.

Le paradoxe de l’irrévocabilité

À la différence d’un mot de passe compromis, qu’on change en quelques secondes, un profil comportemental compromis pose un problème structurel : tu ne peux pas changer ta façon de faire défiler une page ou de taper avec la même facilité que tu changes une chaîne de caractères. Tes patterns comportementaux sont intrinsèquement liés à ta physiologie et à ta neurologie. Ils sont, en un sens très concret, toi-même.

Cela introduit un risque de long terme que l’industrie tend à minimiser. Si une base de profils comportementaux est compromise, les données exfiltrées ne deviennent pas obsolètes par rotation des credentials. Elles restent utilisables jusqu’à ce que les caractéristiques biométriques de l’individu changent significativement — ce qui, dans la majorité des cas, n’arrive qu’avec le vieillissement ou suite à un événement traumatique.

Les fournisseurs soulignent que les profils sont typiquement traités localement et que seul un score de risque est transmis, pas les données brutes. Mitigation réelle, mais qui n’élimine pas le problème fondamental : quelque part, sous une certaine forme, une représentation de ton comportement inconscient existe en tant que donnée numérique.

Discrimination algorithmique et biais comportementaux

Aspect critique supplémentaire : le potentiel discriminatoire des systèmes de biométrie comportementale. Les patterns d’interaction avec les appareils ne sont pas universels. Ils varient selon âge, conditions physiques, handicaps moteurs, différences culturelles d’usage, type d’appareil utilisé.

Un utilisateur âgé avec de l’arthrose aux mains aura des patterns de scroll et de frappe significativement différents d’un vingtenaire. Un utilisateur sur un appareil bas de gamme produira des données capteurs différentes de celles d’un utilisateur sur le dernier flagship. Un utilisateur qui alterne main droite et gauche, ou utilise des technologies d’assistance, génèrera des profils atypiques.

Si le modèle d’anomaly detection a été entraîné majoritairement sur des profils valides de classe moyenne, les utilisateurs qui s’écartent de ce profil moyen seront soumis plus fréquemment à des vérifications additionnelles, blocages de session, demandes de step-up. Autrement dit, la sécurité « passive » que l’industrie vante comme meilleure UX pourrait se traduire par une UX systématiquement pire pour les catégories les plus vulnérables.

L’European Accessibility Act (EAA), pleinement applicable depuis juin 2025, exige que les produits et services numériques soient accessibles aux personnes en situation de handicap. Un système d’authentification comportementale qui pénalise systématiquement les utilisateurs en situation de handicap moteur ou cognitif pose des questions de conformité non seulement RGPD/AI Act, mais aussi accessibilité.

Le devoir de regarder au-delà de la solution technique

Rien de ce qui précède ne signifie que la biométrie comportementale est une mauvaise idée. Le problème de cybersécurité est réel, les pertes sont énormes (l’IC3 de l’FBI documente des milliards de dollars de pertes annuelles), et les défenses traditionnelles sont effectivement insuffisantes face aux menaces actuelles. L’authentification continue est probablement le futur de la sécurité numérique.

Mais la façon dont l’industrie raconte cette transition est incomplète, et pas par accident. L’article de Janes, comme la majorité de la littérature technique, présente la biométrie comportementale uniquement du point de vue de l’efficacité opérationnelle. Le sous-texte : ça marche mieux, c’est plus sûr, l’UX s’améliore. Tout vrai. Mais pas tout.

Pour qui opère dans l’ICT européen, la responsabilité est double. D’un côté, déployer ces technos là où elles sont nécessaires et créent une vraie valeur. De l’autre, le faire avec une conscience normative et éthique que le marché américain — d’où provient l’essentiel de l’innovation dans ce champ — n’a pas la même urgence à développer.

L’Europe, avec son cadre régulatoire stratifié (RGPD, AI Act, EAA, NIS2), ne rend pas la vie difficile à qui travaille avec la techno. Elle pose les questions que le marché, seul, ne pose pas. Des questions comme : à qui appartient ta façon de bouger le doigt sur un écran ? Quels droits as-tu sur un geste inconscient transformé en donnée ? Que se passe-t-il quand ton corps informatisé devient une marchandise ?

Questions inconfortables. Mais à l’instant où le comportement devient credential, on n’a plus le luxe de les ignorer.

Il existe un document que vous devriez lire. Pas long, pas caché, ne demande pas de compétences juridiques particulières. À l’adresse microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse, mis à jour le 24 octobre 2025, il contient une phrase qui mérite d’être prise au sérieux. Dans la section, en majuscules et gras, « IMPORTANT DISCLOSURES & WARNINGS », elle dit : Copilot est à considérer comme étant à des fins de divertissement uniquement. Il peut faire des erreurs et ne pas fonctionner comme prévu. Ne vous appuyez pas sur Copilot pour des conseils importants. Utilisez Copilot à vos propres risques.

Si ça vous semble la clause d’une appli à mèmes, je vous comprends. Mais nous parlons du produit que Microsoft a intégré à Windows 11, Excel, PowerPoint, Teams, Outlook — au cœur d’une suite que plus de 430 millions de personnes utilisent chaque jour. Le produit pour lequel Microsoft a engagé environ 80 milliards de dollars de capex IA pour le seul exercice 2025 — datacenters, infrastructure, capacité de calcul — auxquels s’ajoutent les quelque 13 milliards investis cumulativement dans OpenAI, dont la techno alimente les modèles sous-jacents. Le produit vendu aux grandes entreprises 30 $ par utilisateur et par mois, et 21 (réduits à 18 avec les promos du premier semestre 2026) aux PME. Les ToU de ce produit disent que c’est un jouet.

La réaction de Microsoft, quand la clause a circulé sur les réseaux début avril 2026, a été prévisible. Un porte-parole a déclaré à PCMag qu’il s’agissait d’« un langage legacy » qui « ne reflète plus l’usage actuel du produit » et qui serait « modifié à la prochaine mise à jour ». Pas de date. Aucun engagement contraignant. Aucune explication sur le maintien d’un langage qui ne reflète pas la réalité dans des documents légaux après tant de mois, sous les yeux du même service juridique qui les rédige. Le porte-parole en a parlé comme on parle d’un panneau oublié sur un chantier fermé. Mais les chantiers fermés ne facturent pas 30 $ par siège.

Tentation de classer ça comme bourde du juridique. Faux. Les ToU ne s’écrivent pas par distraction. Ils sont pesés mot à mot par des avocats sachant qu’ils serviront en audience. « Entertainment » n’est pas un synonyme paresseux d’« expérimental » ou « beta ». Entertainment a un sens juridique précis dans le droit anglo-saxon : c’est la catégorie qui protège qui produit du contenu déclarativement non factuel — jeux, fiction, simulations. Dire qu’un produit est « for entertainment purposes only », c’est dire qu’aucun utilisateur raisonnable ne devrait attendre que les réponses soient exactes, fiables ou adaptées à un usage pratique.

On objectera que les chiffres racontent une autre histoire. Que l’adoption de Copilot est plus lente que prévu. Que Microsoft sait que le produit a des problèmes. Vrai. Au T2 FY2026, seuls 15 millions de sièges sur 450 millions de sièges commerciaux payants étaient abonnés à M365 Copilot : 3,3 %. La part des abonnés payants aux US a chuté de 39 % en six mois (de 18,8 % en juillet 2025 à 11,5 % en janvier 2026). Le NPS sur l’exactitude des réponses est passé de –3,5 à –24,1 entre juillet et septembre 2025, selon Recon Analytics. 44,2 % de ceux qui abandonnent Copilot citent la défiance dans les réponses comme motif principal. Quand les salariés peuvent choisir librement entre Copilot, ChatGPT et Gemini, seuls 8 % choisissent Microsoft.

Ces chiffres n’atténuent pas le problème. Ils l’aggravent. Ils montrent que Microsoft sait parfaitement que le produit n’est pas fiable, le déclare dans les documents juridiques, et continue de le vendre comme outil de productivité enterprise. Satya Nadella a appelé Copilot « a true daily habit » devant les investisseurs. Le marketing le présente comme l’assistant qui transforme votre façon de travailler. Les ToU disent que c’est un jouet. Pas une contradiction. Une stratégie.

II. Le chœur des disclaimers

Il serait malhonnête de présenter la clause Microsoft comme une anomalie. Elle ne l’est pas. C’est le cas le plus spectaculaire d’un pattern qui traverse toute l’industrie IA, qu’il vaut la peine de cartographier.

OpenAI, dans ses ToU, prévient les utilisateurs de ne pas s’appuyer sur les outputs comme unique source de vérité ou d’information factuelle, et limite sa responsabilité agrégée à 100 $ ou au montant payé pendant les douze mois précédents. Google, dans les ToU de Gemini, écrit de ne pas s’appuyer sur les services pour des conseils médicaux, mentaux, juridiques, financiers ou autres conseils professionnels. xAI, l’entreprise d’Elon Musk, prévient que son IA est « probabiliste par nature » et peut produire des outputs erronés. Aucune de ces entreprises, pour être juste, n’est allée jusqu’au « for entertainment purposes only ». Cela reste une exclusivité Microsoft.

La différence entre Microsoft et les autres n’est pas de fond. Elle est de nuance. Tous les grands fournisseurs d’IA construisent un mur juridique entre le produit qu’ils vendent et les conséquences de son usage. Ils le font en sachant que leurs modèles peuvent produire — et produisent — des outputs faux, trompeurs, potentiellement nuisibles. En août 2024, Copilot a faussement identifié le journaliste allemand Martin Bernklau comme un pédophile condamné et un escroc, en fournissant aussi son adresse personnelle. Microsoft n’a bloqué les requêtes sur Bernklau qu’après une plainte pour protection des données. Ce ne sont pas des cas-limites. C’est le fonctionnement ordinaire d’un système probabiliste vendu commercialement comme s’il était déterministe.

Et les disclaimers, en justice, fonctionnent. Le 19 mai 2025, la Superior Court du comté de Gwinnett, Géorgie, a prononcé un summary judgment en faveur d’OpenAI dans Walters v. OpenAI (23-A-04860-2). L’animateur radio Mark Walters avait poursuivi OpenAI après que ChatGPT, à la demande d’un journaliste, avait généré un faux résumé d’un procès où Walters figurait accusé de détournement de fonds aux dépens de la Second Amendment Foundation. Le tribunal a rejeté l’action sur trois motifs indépendants : les déclarations ne pouvaient être raisonnablement comprises comme des faits réels (notamment parce que ChatGPT avait averti le journaliste de ses limites et que les ToU contenaient des disclaimers explicites sur la possibilité d’erreurs) ; Walters n’avait démontré ni négligence ni malice d’OpenAI ; et Walters avait admis n’avoir subi aucun dommage. Une issue qui tient sur plusieurs jambes, pas seulement sur les disclaimers. Mais les disclaimers ont pesé, et pèsent. Le tribunal a explicitement reconnu que les avertissements répétés sur la possibilité d’« hallucination » contribuaient à rendre déraisonnable toute attente d’exactitude factuelle de la part de l’utilisateur.

C’est ici que beaucoup s’arrêtent, indignés. Mais c’est ici que le propos doit devenir plus précis, parce que tous les disclaimers ne sont pas équivalents, ne servent pas le même but, et ne sont pas tous, en soi, négatifs.

L’AI Act européen, le Règlement 2024/1689, exige explicitement que les fournisseurs de systèmes IA communiquent les limites de leurs produits. L’article 13 impose que les systèmes à haut risque soient suffisamment transparents pour permettre aux deployers d’interpréter les outputs et de les utiliser correctement, et qu’ils soient accompagnés d’instructions concises, complètes, exactes et claires sur caractéristiques, capacités et limites. L’article 14 impose une supervision humaine effective et prescrit que les superviseurs soient mis en mesure de rester conscients de la possible tendance à se reposer automatiquement ou excessivement sur les outputs — l’« automation bias ». L’article 50 exige que l’utilisateur soit informé qu’il interagit avec un système IA et que les contenus générés soient marqués comme tels.

Dire « ce système IA peut se tromper, vérifie toujours, ne lui fais pas une confiance aveugle » n’est donc pas seulement légitime. C’est une obligation. L’Europe a posé que la transparence sur les limites des systèmes IA est un pilier de la sécurité et de la confiance. L’utilisateur doit savoir avec quoi il interagit, quels sont les risques, et il doit pouvoir ignorer ou outrepasser tout output. C’est le cadre que toute entreprise sérieuse devrait suivre.

Mais une chose est de dire « ce système a ces limites, voici comment le superviser pour l’utiliser sûrement ». Une autre est de dire « c’est un jouet de divertissement, utilise-le à tes risques, on ne garantit rien ». La première formule, c’est de la transparence. C’est de la conformité avec l’AI Act. Un acte de responsabilité qui met le deployer en mesure de faire son travail. La seconde est un transfert de responsabilité déguisé en transparence. Elle ne met pas l’utilisateur en mesure d’utiliser le système correctement : elle le met en incapacité de se retourner quand ça tourne mal.

L’AI Act demande au fournisseur de déclarer les limites pour permettre un usage sûr. Les ToU de Microsoft déclarent les limites pour empêcher tout recours. L’un sert l’utilisateur. L’autre sert le service juridique. Et quand un tribunal américain valorise les disclaimers d’un fournisseur en rejetant une action en diffamation, il ne récompense pas nécessairement la transparence. Il prend acte du legalese.

III. La directive qui change tout (et l’angle mort)

D’ici au 9 décembre 2026, les États membres de l’UE doivent transposer en droit national la Directive 2024/2853, la nouvelle Product Liability Directive. Premier remaniement en quarante ans du régime européen de responsabilité du fait des produits défectueux. Pour les entreprises qui produisent, intègrent ou distribuent du logiciel et des systèmes IA, les conséquences sont profondes.

La directive redéfinit d’abord ce qu’est un « produit ». La directive de 1985 était conçue pour un monde d’objets physiques : voitures, électroménager, jouets. La nouvelle inclut explicitement le logiciel, indépendamment du mode de fourniture ou d’utilisation — qu’il soit embedded, standalone, cloud ou SaaS. Elle inclut firmware, OS, applications. Les Considérants précisent que les systèmes d’intelligence artificielle relèvent aussi de la définition. Le logiciel n’est plus un service qui échappe à la responsabilité produit. C’est un produit. À ce titre soumis à responsabilité objective : pas besoin de prouver la faute du producteur. Il suffit de prouver que le produit était défectueux et que le défaut a causé un dommage.

Reste la question des clauses d’exonération. L’article 10 dispose que les États membres garantissent que la responsabilité d’un opérateur économique au titre de la directive ne peut être limitée ou exclue, vis-à-vis de la personne lésée, par une disposition contractuelle ou par le droit national. Formulation sans ambiguïté. Disclaimers dans les ToU, clauses limitatives, formules « as is » et « for entertainment purposes only » : dès lors qu’un consommateur européen subit un dommage du fait d’un produit défectueux, elles ne valent rien.

Comprenez la portée transatlantique. La clause « Copilot is for entertainment purposes only » continuera à fonctionner aux États-Unis, où Walters v. OpenAI a confirmé que les tribunaux prennent les disclaimers au sérieux. En Europe, après transposition de la directive, cette même clause devient inapplicable. Si Copilot génère un output défectueux causant un dommage à une personne physique (mort, blessures, dommages psychologiques médicalement reconnus, destruction ou corruption de données non professionnelles, dégâts à des biens privés), le fournisseur répond. Indépendamment de ce qui est écrit dans les ToU.

La directive réécrit aussi les règles de la charge de la preuve, et là ça se complique. Elle introduit des présomptions en faveur de la victime. Si le défendeur ne divulgue pas les informations pertinentes, le défaut est présumé. Si le produit n’est pas conforme à des exigences obligatoires de droit national ou européen, le défaut est présumé. S’il y a un dysfonctionnement manifeste lors d’un usage raisonnablement prévisible, idem. Si la victime rencontre « des difficultés excessives » à prouver le défaut en raison de la complexité technique ou scientifique du produit, les tribunaux peuvent présumer à la fois le défaut et le lien de causalité. Pour les systèmes IA, où l’opacité interne est structurelle et non accidentelle, cette présomption sera la norme. La victime n’aura pas à expliquer le fonctionnement du modèle qui a généré l’output faux. Elle devra démontrer que l’output était défectueux et que le dommage en a découlé.

La PLD s’imbrique avec tout le cadre normatif européen. La non-conformité aux exigences du Cyber Resilience Act (security-by-design, gestion des vulnérabilités, mises à jour de sécurité) peut constituer une présomption de défectuosité. Idem pour le non-respect des obligations NIS2. Et idem, implicitement, pour les exigences de l’AI Act : un système IA qui ne respecte pas les obligations de transparence, supervision humaine, exactitude et robustesse est un système qui ne respecte pas des exigences obligatoires de droit européen, et donc un système pour lequel la PLD peut présumer la défectuosité.

Le court-circuit saute aux yeux. L’AI Act demande aux fournisseurs de déclarer les limites pour permettre un usage sûr. La PLD dit que si le produit cause un dommage, le fournisseur répond indépendamment des disclaimers. Le fournisseur est obligé d’informer que son système peut se tromper, et en même temps il ne peut pas utiliser cette information comme bouclier quand le système se trompe effectivement. Régime cohérent, conçu pour protéger le consommateur. Mais qui crée une tension forte entre devoir de transparence et impossibilité d’utiliser cette transparence comme bouclier.

Pour Microsoft, la tension est gérable. Pour qui se trouve au milieu de la chaîne, elle peut être létale.

IV. Qui modifie, paie : l’intégrateur comme bouc émissaire structurel

La PLD ne se contente pas de dire que le producteur du logiciel répond. Elle élargit la chaîne des opérateurs économiques potentiellement responsables, selon une logique en cascade pensée pour qu’un consommateur européen ait toujours un interlocuteur joignable dans l’UE. Si le manufacturer est hors UE, c’est l’importateur. Sinon le représentant autorisé. Puis le fulfilment service provider. Puis le distributeur, s’il n’identifie pas l’opérateur pertinent dans le mois de la demande de la victime. La responsabilité est solidaire : plusieurs opérateurs répondant du même dommage répondent ensemble, chacun pour le tout.

Jusqu’ici, le système paraît raisonnable. Mais il y a une figure que la PLD traite avec une dureté particulière, cruciale pour comprendre les implications pratiques de la clause « entertainment only » : quiconque modifie substantiellement un produit après sa mise sur le marché est considéré comme un manufacturer du produit modifié et est responsable dans la mesure où le défaut résulte de la modification. Les Considérants précisent qu’une modification substantielle peut découler aussi d’une mise à jour logicielle, d’un upgrade, ou de l’apprentissage continu d’un système IA. Le produit ainsi modifié est considéré comme mis sur le marché au moment où la modification est effectivement opérée.

Pensez à ce qui se passe dans le réel. Un system integrator, une software house, un consultant IT prend Copilot et l’intègre dans un workflow d’entreprise. Il configure les prompts, branche les sources de données du client, personnalise les réponses, automatise les flux. Modifie-t-il substantiellement le produit ? Selon la PLD, très probablement oui. Le moment où vous prenez un modèle généraliste pour le spécialiser sur un contexte précis, vous créez un produit différent. Si ce produit modifié génère un output défectueux causant un dommage, l’intégrateur répond comme manufacturer.

L’article 12 prévoit une protection spécifique pour les micro et petites entreprises produisant un logiciel défectueux intégré au produit d’autrui. Elles peuvent, par accord contractuel avec le manufacturer du produit final, se protéger des actions récursoires. Mais cette protection a deux limites qui en réduisent fortement l’utilité. Première : elle ne protège en aucun cas la micro/petite entreprise d’une action directe du consommateur. Le consommateur peut toujours agir directement contre l’intégrateur, et l’intégrateur répond. Seconde : la protection contre les actions récursoires exige un accord contractuel avec le manufacturer du produit. Microsoft n’a aucune obligation et aucun incitatif à concéder ces accords aux SI qui utilisent Copilot. Ses ToU disent déjà que le produit est « for entertainment purposes only » et que l’utilisateur est « solely responsible » de toute action prise sur la base des outputs. Dans une éventuelle action récursoire, Microsoft pourra dire : on vous avait prévenus. Vous avez choisi vous-mêmes de l’intégrer dans un produit professionnel. Ce n’est pas notre faute si vous l’avez vendu à un client comme outil fiable alors que nous-mêmes vous avions dit que c’était un jouet.

La PLD empêche de déverser la responsabilité vers le bas — c’est-à-dire vers le consommateur — par des clauses contractuelles. Mais elle n’empêche pas les grands de refuser des protections contractuelles vers le haut, dans la relation entre intégrateur et manufacturer. Résultat : l’intégrateur est exposé au consommateur sans pouvoir se protéger contractuellement, et n’a aucune garantie de pouvoir efficacement se retourner contre Microsoft. Microsoft a les avocats, les représentants autorisés dans chaque État membre, la masse financière pour absorber le contentieux. L’intégrateur de dix personnes à Pescara, à Brno, à Lisbonne, non.

L’objection évidente : l’intégrateur peut et doit implémenter la supervision humaine prévue par l’AI Act. Mettre en place processus de vérification, formation, supervision des outputs. C’est vrai. L’intégrateur responsable le fera, et devra le faire aussi pour ses propres obligations de deployer sous AI Act. Mais la PLD ne demande pas si vous avez fait de votre mieux. La PLD demande si le produit était défectueux et si le défaut a causé un dommage. Un output faux d’un système IA intégré dans un workflow professionnel qui cause un dommage à une personne physique est un produit défectueux, indépendamment du nombre de couches de supervision humaine implémentées. Vous pouvez avoir tout bien fait et répondre quand même.

Pensez à ce qui arrive quand un système IA intégré dans un ERP génère un rapport financier erroné menant à une mauvaise décision d’investissement. Ou quand un assistant IA intégré à un CRM produit une communication diffamatoire sur un client. Ou quand un système d’analyse intégré à une plateforme de santé fournit une indication erronée influençant un parcours diagnostique. Dans tous ces cas, sous la PLD, la victime peut agir contre l’intégrateur. L’intégrateur est là, dans l’UE, joignable, avec un code SIRET et un compte en banque. Microsoft est à Redmond. Et dans ses ToU, c’est écrit que Copilot est pour le divertissement.

V. La facture et qui la paie

Il y a un moment, dans l’histoire de la régulation technologique, où l’on voit clairement que les règles ont été écrites pour un monde qui n’existe plus. La PLD de 1985 était pensée pour un monde d’objets physiques fabriqués par des entreprises identifiables, vendus par des chaînes linéaires, utilisés par des consommateurs qui pouvaient raisonnablement en juger la sécurité. La nouvelle PLD est une mise à jour nécessaire et à bien des égards admirable : elle étend la protection au logiciel, abaisse les barrières pour les consommateurs, introduit des présomptions qui rééquilibrent l’asymétrie informationnelle. Mais le monde qu’elle régule n’est pas fait de chaînes linéaires. Il est fait de couches superposées, d’API qui appellent des API, de modèles probabilistes dont le fonctionnement interne n’est compréhensible même pas par leurs constructeurs.

L’architecture logique du cadre européen est la plus avancée au monde. L’AI Act fixe les obligations de transparence, supervision humaine, gestion du risque. Le Cyber Resilience Act impose security-by-design et mises à jour continues. NIS2 étend la cybersécurité à des secteurs critiques. La PLD ferme la boucle en disant que celui qui viole ces obligations et cause un dommage paie. L’objection ne porte pas sur la logique du cadre. Elle porte sur la distribution pratique des conséquences.

Les conséquences, dans la réalité, suivent une loi de gravitation économique qu’aucune directive ne peut inverser : elles tombent vers le bas. Vers qui a moins de ressources juridiques, moins de masse financière, moins de capacité d’absorption du contentieux. Microsoft, Google, OpenAI ont chacune des centaines d’avocats, des représentants autorisés dans chaque juridiction, des budgets juridiques qui dépassent le CA de filières entières de PME. Elles ont écrit des ToU qui, même inopposables au consommateur sous la PLD, restent pleinement opérationnels comme arguments dans les actions récursoires entre opérateurs économiques. Elles ont classifié leurs produits comme « entertainment », « probabilistic », « not a source of truth » avec une précision chirurgicale, sachant quel rôle chaque mot jouerait dans une procédure future.

La PLD présente la facture, mais qui la paie ? Le system integrator de dix personnes qui a pris Copilot, l’a intégré dans le gestionnaire du client, a fait de la formation, mis en place la supervision humaine, et qui découvre que quand l’output défectueux génère un dommage, c’est lui qui est joignable, identifiable, attaquable. Le fournisseur est de l’autre côté de l’océan, ou protégé par des clauses contractuelles B2B, des arbitrages à Dublin, et des limitations de responsabilité entre opérateurs économiques que la PLD ne touche pas, parce qu’elles concernent des rapports entre professionnels et non la protection directe du consommateur.

Il serait faux de dire que la PLD est une erreur. La PLD est incomplète. Son incomplétude produit un effet régressif qui récompense ceux qui ont les ressources pour naviguer le système et pénalise ceux qui ne les ont pas. L’article 12 reconnaît le problème pour les micro/petites entreprises, mais le résout circulairement : on te protège contre le récursoire si tu as un accord contractuel avec le manufacturer. Mais le manufacturer n’a aucune obligation de te le concéder. Et si dans ses ToU c’est écrit « entertainment only », son incitatif à te le concéder est même négatif : signer cet accord reviendrait à admettre implicitement que le produit a un usage professionnel, contredisant son propre bouclier.

Paradoxe supplémentaire. Les entreprises qui prennent le plus au sérieux la conformité, qui mettent en place la supervision humaine, qui informent les clients, qui documentent les processus, sont aussi celles qui laissent la trace documentaire la plus riche pour une action en responsabilité. Qui intègre Copilot à la va-vite, sans processus, sans doc, sans supervision, est paradoxalement plus difficile à attaquer faute de preuves d’un rapport structuré avec le produit. La PLD, en cherchant à protéger le consommateur, risque d’inciter à la superficialité : qui fait bien est plus exposé que qui fait mal.

Considérons la dimension temporelle. La PLD s’applique aux produits mis sur le marché ou en service après la transposition. Mais les systèmes IA ne sont pas des produits statiques. Ils sont mis à jour en continu. Les modèles changent. Les outputs changent. Un système IA qui marche aujourd’hui d’une manière pourrait, dans six mois, après un update du modèle sous-jacent, marcher tout autrement. Chaque mise à jour substantielle, selon les Considérants, remet le produit sur le marché. L’intégrateur qui a construit un workflow sur Copilot en 2025 pourrait se retrouver, après un update du modèle en 2027, avec un produit substantiellement différent générant des outputs différents, sans contrôle sur la modification et avec pleine responsabilité de ses effets.

Je n’ai pas de solution clef en main. Mais qui travaille dans ce secteur devrait commencer à lire les ToU de ses fournisseurs IA non pour s’indigner, mais pour saisir exactement ce que le fournisseur refuse de garantir, parce que cette liste est la carte du risque résiduel qui reste sur les épaules de l’intégrateur. Il devrait négocier des accords contractuels spécifiques sur la responsabilité produit avant la transposition de la PLD, parce qu’après le pouvoir de négociation sera encore moindre. Il devrait documenter chaque processus de supervision humaine, chaque évaluation de risque, chaque information au client — non parce que cela élimine la responsabilité PLD, mais parce que dans une action récursoire la documentation est la seule arme. Et il devrait poser sérieusement la question de la soutenabilité assurantielle de l’intégration de systèmes IA tiers dans des produits professionnels — car aujourd’hui la plupart des polices RC pro ne couvrent pas les dommages de sortie d’IA, et demain cette couverture sera nécessaire.

Quand Microsoft écrit « for entertainment purposes only », elle ne bafouille pas. Elle parle clair, et délibérément. Elle dit que la responsabilité de tout usage professionnel du produit n’est pas la sienne. Elle dit que celui qui prend ce produit et le vend comme outil fiable le fait entièrement à ses risques. L’Europe a bâti un cadre normatif qui en théorie tient tout le monde responsable. En pratique, il tient pour responsables ceux qui peuvent le moins se le permettre. Le fournisseur qui a écrit « for entertainment purposes only » sachant pertinemment que personne ne le lirait, qui a empoché 30 $ par siège et par mois sachant pertinemment que son produit n’était pas fiable, celui-là a encore ses avocats, ses clauses, ses arbitrages internationaux. La prochaine fois qu’on lui demandera des comptes, il ressortira les Terms of Use. Tout y est écrit. Il suffit de lire.

L’intuition fondatrice de Bloch et Febvre

Partons d’où la séduction est la plus forte, parce que c’est là qu’il faut regarder pour comprendre où les choses ont commencé à craquer. Marc Bloch et Lucien Febvre fondent la revue en 1929 avec un programme qui, relu aujourd’hui, conserve une force indéniable : assez de l’histoire des rois et des batailles, assez de la narration événementielle qui réduit le passé à une suite de faits politiques et diplomatiques. L’histoire doit dialoguer avec la géographie, l’économie, la sociologie, l’anthropologie. Elle doit s’occuper des structures profondes, des temps longs, des mentalités collectives. Elle doit, en un mot, devenir totale. L’intuition était authentique et répondait à un vrai problème. L’historiographie positiviste du XIXᵉ s’était effectivement réduite à un catalogue d’événements, et l’idée qu’il existait des forces plus profondes modelant les sociétés humaines était non seulement légitime mais nécessaire. Personne qui ait lu Les rois thaumaturges de Bloch ou Le problème de l’incroyance au XVIᵉ siècle de Febvre ne peut nier la puissance de ce regard. Le problème n’a jamais été l’intuition. Le problème, c’est ce qu’on en a fait.

Braudel et l’impasse de la longue durée

Fernand Braudel publie La Méditerranée et le monde méditerranéen à l’époque de Philippe II en 1949, et ce livre devient le monument de l’école — et son impasse. Braudel introduit la tripartition temporelle qui deviendra la marque de fabrique de l’école : le temps quasi immobile de la géographie et du climat, le temps lent des structures économiques et sociales, le temps rapide des événements politiques. Hiérarchie explicite et non négociable. Le protagoniste, c’est la Méditerranée, pas Philippe II. Les courants marins, les vents, les routes commerciales, les cycles agricoles déterminent le cadre. C’est un renversement radical. Et ça fonctionne, du moins tant qu’on reste dans la prose de Braudel, dont la force rend crédible presque tout.

Mais quand on sort de la suggestion littéraire pour regarder le modèle d’un œil analytique, on tombe sur un problème que Braudel n’a jamais résolu et que ses héritiers ont préféré ignorer : si la longue durée est le niveau explicatif fondamental, quelle place reste-t-il pour l’action humaine ? La question n’est pas rhétorique. Paul Ricœur, dans Temps et récit, la pose avec une clarté que les historiens des Annales n’ont jamais égalée : le temps de la longue durée est un temps sans sujet, où les choses arrivent mais où personne ne les fait arriver. Braudel le savait-il ? Probablement, et probablement il s’en moquait. Dans son schéma l’histoire événementielle est « poussière », formule fameuse qui liquide des siècles d’historiographie en une métaphore méprisante. Mais la poussière, à y regarder, est faite de personnes qui décident, qui agissent, qui se trompent, qui changent le cours des choses d’une manière qu’aucune structure profonde ne pouvait prévoir. Le choix de Philippe II de lancer l’Invincible Armada en 1588 n’est pas explicable par les vents ni les cycles du blé. C’est une décision politique d’un individu spécifique dans un contexte spécifique, aux conséquences énormes. La reléguer à de la « poussière » n’est pas un acte de rigueur scientifique, c’est un acte d’arrogance épistémologique.

Le point doit être poussé plus loin, car il ne concerne pas que Braudel, mais un vice logique de toute l’école. Si la structure explique plus que l’événement, et si l’événement est « poussière », le changement historique devient un problème insoluble. Les structures, par définition, sont ce qui persiste. Mais l’histoire est aussi, peut-être surtout, ce qui change. Comment passe-t-on d’une structure à l’autre ? Braudel ne le dit pas, parce que dans son schéma le passage se fait sur des temps si longs qu’ils deviennent presque imperceptibles, un mouvement géologique sans acteurs. Ce n’est crédible que tant qu’on regarde les siècles d’en haut. Quand on descend là où les gens vivent, décident, se révoltent, inventent, le cadre braudélien devient inutilisable. La Révolution française n’est pas explicable en longue durée. Les facteurs structurels créent les conditions, certes, mais n’expliquent ni juillet 1789 ni Robespierre ni les formes concrètes de l’événement. Marc Bloch, paradoxalement, était bien plus attentif à ces nuances que son successeur. La société féodale est un livre structural, oui, mais Bloch ne perd jamais de vue les mécanismes concrets par lesquels les humains construisent et reproduisent les structures dans lesquelles ils vivent. Avec Braudel, ce lien se rompt, et l’école n’a jamais réussi à le renouer.

On objectera que la critique est ancienne, qu’elle a été formulée mille fois, que les Annales eux-mêmes l’ont reçue et métabolisée. Vrai, ils l’ont reçue. Mais comment ? Le discours devient ici intéressant, parce que la façon dont l’école a géré ses crises internes en révèle plus que les crises elles-mêmes.

Les mentalités comme retraite stratégique

La deuxième génération, celle de Braudel, règne sur l’historiographie française et largement internationale des années 1950 aux années 1970. Le modèle est solide, les chaires occupées, la revue est le centre de gravité de la discipline. Puis, dans les années 1970-80, la troisième génération arrive : Le Goff, Le Roy Ladurie, Duby, et avec eux le grand basculement vers l’histoire des mentalités. Pas une évolution naturelle, une retraite stratégique. La longue durée braudélienne a montré ses limites : trop déterministe, trop structurelle, trop indifférente à tout ce qui n’est pas mesurable. L’histoire des mentalités promet de récupérer la dimension subjective sans abandonner l’ambition interdisciplinaire. On étudie les représentations collectives, les croyances, les peurs, les rêves, les conceptions de la mort et du temps. C’est fascinant. Montaillou, village occitan de Le Roy Ladurie est un livre extraordinaire, et les recherches de Le Goff sur le Purgatoire ou sur la naissance du temps du marchand restent parmi les meilleures choses produites par l’historiographie du XXᵉ.

Mais le prix est élevé, et personne ne le dit assez clairement. Passer de la longue durée aux mentalités, ce n’est pas intégrer les deux, c’est abandonner le premier parce qu’il ne fonctionnait pas et adopter l’autre en espérant qu’il fonctionne mieux. Ce geste a quelque chose de familier pour qui a fréquenté l’académie : ce n’est pas un changement de paradigme au sens kuhnien (avec crise explicite, anomalies reconnues, substitution argumentée), c’est un changement de sujet présenté comme évolution. La différence est cruciale. Un changement de paradigme implique que l’ancien ait été réfuté ou sérieusement remis en cause. Un changement de sujet implique seulement que l’ancien sujet ne tire plus de financements, ne génère plus de thèses, ne remplit plus les colloques. L’historiographie des Annales, de la deuxième à la troisième génération, ressemble bien plus à la seconde dynamique qu’à la première.

Et les mentalités, à leur tour, posent d’énormes problèmes. Comment reconstruit-on une « mentalité collective » ? Avec quelles sources, quelle méthode ? La réponse, en pratique, a souvent été : avec beaucoup de créativité interprétative et peu de vérifiabilité. Geoffrey Lloyd, l’historien des sciences anciennes de Cambridge, dans Demystifying Mentalities (1990), met en doute la validité même du concept de mentalité collective : attribuer des « mentalités » distinctes à des sociétés ou à des époques entières est intellectuellement fragile, masque la coexistence de formes de pensée différentes au sein d’une même culture. Et il n’était pas seul. L’histoire des mentalités a produit de beaux livres, mais aussi un impressionnisme historiographique qui rendait quasi impossible la distinction entre hypothèse fondée et spéculation élégante.

À ce stade, on pourrait m’arrêter et dire : n’est-ce pas le destin de toutes les sciences humaines ? L’histoire, s’occupant d’humains et non de particules, ne doit-elle pas vivre avec une marge irréductible d’incertitude ? Bien sûr. Mais il y a une différence énorme entre reconnaître cette incertitude et en faire un programme. Les Annales, génération après génération, ont transformé l’incertitude méthodologique en principe de liberté épistémologique — manière élégante de dire qu’ils ont changé de méthode chaque fois que la précédente s’enrayait, sans jamais avouer qu’elle s’enrayait. C’est cette manœuvre qu’il faut démasquer, parce qu’elle permet à l’école de se présenter comme perpétuellement innovante quand elle est, en réalité, perpétuellement en fuite.

Le tournant critique et la dépendance aux sciences sociales

L’étape suivante le confirme. Dans les années 1980-90 arrive ce que la rédaction même des Annales appellera le « tournant critique », consacré par un numéro spécial en 1989 avec Chartier, Lepetit, Revel. Cette fois la crise est plus profonde. Les mentalités ont montré leurs limites, la microhistoire italienne (Ginzburg, Levi, Grendi) a montré qu’on peut faire des choses extraordinaires en réduisant l’échelle, l’anthropologie de Clifford Geertz a imposé l’idée de la « description dense ». Les Annales répondent comme ils savent : en changeant de paradigme. On passe à l’histoire culturelle, aux « pratiques » et « représentations », à un dialogue plus serré avec la sociologie de Bourdieu et l’herméneutique. Bernard Lepetit, avant sa mort prématurée en 1996, tente une refondation théorique qui prend très au sérieux les objections, mais cette tentative reste inachevée et minoritaire à l’intérieur même de l’école. La revue change de nom en 1994, de Annales. Économies, Sociétés, Civilisations à Annales. Histoire, Sciences sociales, et le changement est symptomatique : on réaffirme le lien avec les sciences sociales au moment où ce lien est le plus problématique.

Jacques Revel, à cette époque, propose la notion de « jeux d’échelles » comme issue à l’impasse. L’idée séduit : plutôt que choisir entre la longue durée et le cas singulier de la microhistoire, savoir passer d’une échelle à l’autre. Mais la suggestion, intelligente, reste programmatique. Personne, en pratique, n’a produit un travail intégrant vraiment les différentes échelles de manière cohérente. On saute, on juxtapose, on accosrte, mais l’intégration reste un désir. Peut-être ne peut-il en être autrement, parce que les différentes échelles ne sont pas de simples zooms sur la même réalité : ce sont des manières différentes de construire l’objet historique, et il n’est pas dit qu’elles soient compatibles.

Soyons honnêtes. Qu’une tradition intellectuelle traverse des crises et se renouvelle, ce n’est pas en soi un problème. Toutes les traditions sérieuses le font. Le problème surgit quand le renouvellement devient un mécanisme de survie institutionnelle plutôt qu’intellectuel, quand le changement de paradigme sert à maintenir des positions académiques, le contrôle de la revue, l’hégémonie des chaires, plus qu’à répondre à de vraies questions. Vue sous cet angle, l’histoire de l’école des Annales est aussi une histoire de pouvoir académique français — et ce n’est pas un hasard si les critiques les plus dures sont venues souvent de l’extérieur : microhistoire italienne, social history britannique, Alltagsgeschichte allemande, historiographie postcoloniale anglo-saxonne. L’accusation, formulée différemment mais avec une cohérence frappante, est toujours la même : les Annales prétendent offrir une méthode universelle, mais ce qu’ils offrent en réalité, c’est une sensibilité française élevée au rang de paradigme global, avec tous les angles morts que cela suppose.

Cela amène à la question plus profonde, le défaut structurel qui était là dès le début. L’histoire totale, le rêve fondateur de Bloch et Febvre, l’horizon vers lequel chaque génération a déclaré marcher, même quand elle marchait dans des directions opposées. L’idée qu’il serait possible et même nécessaire d’écrire une histoire intégrant tous les niveaux de l’expérience humaine, du climat à la prière, du prix du blé aux structures familiales, de la technologie aux émotions. Programme magnifique. Et impossible — pas pour des raisons pratiques mais logiques.

Tout acte historiographique est un acte de sélection. Choisir d’étudier la Méditerranée au XVIᵉ, c’est ne pas étudier la Baltique. Choisir la longue durée, c’est ne pas choisir l’événement. Choisir les mentalités collectives, c’est ne pas choisir les stratégies individuelles. Ces choix ne sont pas accidentels : ils sont constitutifs ; ils définissent ce qui compte comme fait historique et ce qui n’y compte pas, ce qui mérite explication et ce qui peut être ignoré. Une histoire totale exigerait l’absence de tout critère de sélection, ce qui équivaut à l’absence de méthode, ce qui équivaut à ne pas faire d’histoire. Hayden White, avec Metahistory (1973), a montré que même les grandes œuvres historiographiques sont structurées par des tropes narratifs qui en déterminent la forme et, inévitablement, le contenu. Braudel ne décrit pas la Méditerranée : il la raconte, et la raconte selon une logique narrative qui sélectionne, ordonne, hiérarchise. La prétention à la totalité est exactement cela, une prétention, et le fait qu’elle soit gardée comme horizon régulateur ne la rend pas moins incohérente. Elle la rend juste plus difficile à critiquer, parce que celui qui ose dire que le roi est nu se voit répondre que la totalité est un idéal, pas un résultat, et que la valeur réside dans l’effort. Mais un idéal logiquement impossible n’est pas un horizon, c’est un mirage.

Un autre problème, peut-être le plus insidieux, concerne le rapport des Annales aux sciences sociales. L’interdisciplinarité a été le cheval de bataille dès la fondation. Histoire et géographie, économie, sociologie, anthropologie, psychologie collective : chaque génération a ajouté un interlocuteur privilégié et présenté ce dialogue comme la preuve de la modernité scientifique de l’école. Mais que se passe-t-il quand une discipline se définit systématiquement par ce qu’elle importe des autres ? Elle perd son centre. Pas sa « méthode » au sens strict — l’histoire n’a jamais eu de méthode unique. Mais quelque chose de plus subtil et plus important : la conscience de ce qui est spécifiquement historique dans une enquête historique.

Quand Braudel importe la géographie, le résultat est une histoire qui ressemble beaucoup à de la géographie avec une dimension temporelle. Quand Le Goff importe l’anthropologie, le résultat est souvent une anthropologie appliquée au passé. Quand la quatrième génération importe la sociologie de Bourdieu, on obtient une sociologie historicisée. Dans chacun de ces cas, le dialogue n’est pas symétrique : c’est l’histoire qui cède du terrain. Et la raison est simple : les autres disciplines ont des structures théoriques plus fortes. L’économie a des modèles formels, la sociologie des appareils conceptuels consolidés, l’anthropologie sa tradition ethnographique. L’histoire, telle que la conçoivent les Annales, devrait intégrer tout cela sans disposer d’un cadre théorique propre aussi robuste. Le résultat est un éclectisme vendu pour ouverture d’esprit mais qui produit, en pratique, une vulnérabilité structurelle : à chaque mode des sciences sociales, les Annales changent d’interlocuteur et, avec lui, de méthode, de questions, d’objets. Ce n’est pas de l’interdisciplinarité, c’est de la dépendance.

Et la dépendance produit un effet secondaire plus grave : la perte de compétence technique. Quand Braudel dialoguait avec Wallerstein, tous deux maîtrisaient assez de théorie économique pour le dialogue. Mais dès la troisième génération, la relation devient asymétrique. Les historiens des mentalités importent des concepts d’anthropologie (la « mentalité primitive » de Lévy-Bruhl, ensuite corrigée, les structures de parenté de Lévi-Strauss, les rites de Van Gennep) sans toujours posséder la formation technique pour en juger la solidité dans le contexte d’origine. Le résultat est que des concepts nés pour décrire des sociétés contemporaines sont projetés sur des sociétés du passé avec des ajustements minimaux. Quand le Carnaval de Romans de Le Roy Ladurie est lu à travers la grille bakhtinienne du carnaval comme renversement social (la tentation est forte, on parle littéralement d’un carnaval de 1580 fini en massacre), le résultat est brillant mais méthodologiquement fragile : Bakhtine n’était pas anthropologue, son « carnavalesque » est une catégorie littéraire, et l’appliquer à un événement historique précis exige une chaîne de médiations que ni le texte ni ses interprètes n’expliquent jamais entièrement. Pattern qui se répète à chaque changement d’interlocuteur.

Braudel, avec son idée d’« économie-monde », prenait à Wallerstein autant qu’il lui donnait. L’histoire des mentalités naissait à l’ombre du structuralisme de Lévi-Strauss. Le tournant culturel des années 90 était impensable sans Bourdieu et Geertz. L’histoire globale présentée aujourd’hui comme le dernier avatar des Annales doit presque tout à la world history anglo-saxonne de Pomeranz, Subrahmanyam, Bayly. À chaque étape, l’école a joué plus le rôle de récepteur que d’émetteur, plus d’adaptateur de paradigmes d’autrui que de générateur. Pas un problème en soi, si c’était reconnu : ce serait même une qualité — la capacité à médier, traduire, hybrider. Mais l’école se raconte comme le lieu où se produit l’innovation historiographique, narration de moins en moins crédible.

On m’objectera que j’applique un critère impossible, que je demande à l’histoire d’avoir une structure théorique comparable à celle des sciences naturelles. L’objection a un certain poids mais rate la cible. Je ne demande pas de lois universelles. Je demande quelque chose de plus modeste : qu’une école historiographique soit capable de formuler clairement ses critères de validation. Comment distingue-t-on un bon travail annaliste d’un mauvais ? Comment décide-t-on si une interprétation est fondée ? Comment falsifie-t-on, ou met-on à l’épreuve, une thèse sur la mentalité médiévale ? La réponse, en pratique, a été confiée au jugement des pairs — ce qui dans une communauté scientifique saine fonctionne, mais dans une école à forte identité institutionnelle et mécanisme de cooptation devient un cercle vicieux. Karl Popper n’aurait pas eu de mal à reconnaître le pattern.

La microhistoire comme critique radicale

Et ce n’est pas un hasard si la microhistoire italienne est née en partie en réaction à cette fermeture. Quand Carlo Ginzburg reconstitue le cosmos de Menocchio dans Le fromage et les vers, il ne fait pas une histoire totale en miniature — il fait quelque chose de radicalement différent : il démontre qu’un cas unique, étudié avec rigueur philologique et sensibilité interprétative, peut ouvrir des fenêtres sur des structures culturelles profondes sans cadres synthétiques grandioses. L’échelle change tout, parce qu’elle change le rapport à la source, à la preuve, à la vérifiabilité. Là où Braudel pouvait se permettre de généraliser sur des siècles entiers et des bassins maritimes, Ginzburg doit rendre compte de chaque document, de chaque mot prononcé par Menocchio devant l’Inquisition. Cette contrainte n’est pas un limite, c’est une discipline au sens noble. La microhistoire dit : je ne peux pas tout savoir, mais ce que je sais, je le sais vraiment, et je peux montrer comment je le sais. Les Annales, dans leurs versions ambitieuses, disent l’inverse : on peut savoir tout, ou aspirer à le faire, et la méthode pour y arriver est la synthèse interdisciplinaire. L’histoire a donné raison aux premiers, pas aux seconds.

Giovanni Levi, dans Le pouvoir au village, fait pareil : il part d’un village piémontais et arrive à repenser les stratégies familiales de l’Ancien Régime sans jamais prétendre décrire la totalité. La microhistoire n’est pas une variante des Annales, c’est une critique des Annales, et le fait que Le Goff et d’autres aient cherché à l’annexer (« nous aussi, nous attentions aux détails ») est une preuve supplémentaire de la capacité de l’école à phagocyter ce qui la menace.

On peut dire la même chose, mutatis mutandis, de l’Alltagsgeschichte allemande de Lüdtke et Medick, de la history from below britannique d’E.P. Thompson, et de toute la tradition postcoloniale qui, depuis Edward Said, a posé une question à laquelle les Annales n’ont jamais répondu de manière convaincante : votre histoire totale, totale pour qui ? La Méditerranée de Braudel ? L’Europe de Le Goff ? La France profonde de Le Roy Ladurie ? Le provincialisme géographique de l’école a longtemps été masqué par l’universalisme de la méthode, mais quand des historiens comme Dipesh Chakrabarty ont commencé à « provincialiser l’Europe » au sens technique — c’est-à-dire à montrer que les catégories analytiques de l’historiographie européenne ne sont pas universelles mais historiquement situées — le jeu est devenu plus difficile. Histoire mondiale de la France le démontre involontairement : un livre qui se propose de raconter la France à travers ses connexions globales, mais qui, précisément pour cela, finit par réaffirmer la centralité de la France comme point d’observation. La décentration est apparente.

La réponse de l’école, ces deux dernières décennies, a été l’histoire globale et connectée. Patrick Boucheron, Serge Gruzinski, Sanjay Subrahmanyam (qui n’est pas à proprement parler annaliste, et tient à le faire savoir) ont élargi le regard au monde entier, aux connexions entre civilisations, aux flux de personnes, marchandises, idées à travers les continents. L’opération est intellectuellement stimulante. Mais qu’y a-t-il de spécifiquement annaliste ? La world history existait avant, ailleurs, et la version des Annales ne se distingue pas par une méthode propre, mais par une attitude. On fait de l’histoire globale avec une sensibilité annaliste, c’est-à-dire avec attention aux temps longs et aux phénomènes structurels. Contribution ? Peut-être. Suffisante pour justifier la prétention à être encore une école avec un programme reconnaissable ? J’en doute. Le doute devient certitude quand on regarde la production. Annales publie aujourd’hui des articles de qualité variable sur des sujets enormément disparates : droit islamique, économie japonaise Tokugawa, environnement amazonien, émotions dans la première modernité. Variété impressionnante, mais qu’est-ce qui tient ces travaux ensemble sinon le fait d’être publiés dans la même revue ? Quel est le fil méthodologique distinguant un article « annaliste » d’un article publié dans Past and Present ou Quaderni storici ? La réponse honnête est : aucun.

Voilà le point qui me tient le plus à cœur. Le problème des Annales n’est pas une erreur unique, ni la longue durée en soi, ni l’interdisciplinarité en soi, ni l’histoire totale en soi. C’est la combinaison de ces trois éléments en un projet qui n’a jamais été en mesure de rendre compte de sa cohérence interne. La longue durée demandait une épistémologie déterministe que l’histoire des mentalités a abandonnée. L’interdisciplinarité demandait un cadre théorique intégrateur qui n’a jamais été produit. L’histoire totale demandait des critères de sélection que sa propre définition exclut. Pris isolément, chacun de ces éléments contient des intuitions précieuses. Mis ensemble, ils produisent un programme intérieurement contradictoire qui ne survit que grâce à la vague de ses principes et à la force de ses institutions.

Cela ne signifie pas que les historiens des Annales n’ont pas produit d’excellents travaux. Ils en ont produit, et beaucoup restent incontournables. Mais ils les ont produits non grâce au programme de l’école, mais malgré lui, ou plus précisément en en exploitant sélectivement les aspects utiles et en ignorant le reste. Braudel est grand non parce qu’il applique la longue durée de façon cohérente, mais parce qu’il est un narrateur formidable. Le Goff est grand non parce que l’histoire des mentalités est une méthode solide, mais parce que son érudition et son imagination historique sont hors du commun. Ginzburg, que l’école a cherché à coopter, est grand précisément parce qu’il a refusé le programme annaliste et en a proposé un autre.

Reste la question d’ouverture, et il convient de la reprendre pour finir. Les Annales ont-ils échoué ? La réponse dépend de ce qu’on entend par échec. Si l’on entend que l’école n’a pas tenu ses promesses, que le programme d’une histoire totale, interdisciplinaire et scientifiquement fondée s’est révélé irréalisable, alors oui. Mais peut-être l’échec le plus significatif n’est-il pas le leur, c’est celui du rêve qui les a engendrés : l’idée, profondément ancrée dans les Lumières et relancée par le positivisme du XIXᵉ, que l’histoire pouvait devenir une science au sens plein, avec lois générales, méthodes reproductibles et capacité explicative cumulative. Les Annales ont tenté cette entreprise avec plus d’ambition, de talent et de ressources institutionnelles que quiconque au XXᵉ. Le fait qu’ils n’aient pas réussi ne dit rien contre leur intelligence. Cela dit quelque chose, peut-être, sur la nature de la connaissance historique, qui résiste à la systématisation non par défaut surmontable mais par caractéristique constitutive. L’histoire n’est pas physique, ni biologie, ni même économie. Elle ne l’est pas parce que son objet n’est pas un système mais un processus, et un processus dont le sens est rétroactivement construit par celui qui l’observe. L’histoire est le récit que les humains se font d’eux-mêmes, et ce récit est nécessairement partiel, situé, contestable. Vouloir le rendre total, c’est comme vouloir photographier la lumière : l’instrument utilisé fait partie de ce qu’on cherche à capter. Les Annales l’ont découvert à leurs dépens, et le fait qu’ils continuent à ne pas l’admettre est peut-être la critique la plus dure qu’on puisse leur adresser.

Au-delà de la totalité

Ce n’est pas un hasard, peut-être, si les traditions historiographiques les plus vivantes des dernières décennies ont été celles qui ont explicitement renoncé à la totalité. La microhistoire a choisi la petite échelle et la densité analytique. L’histoire orale a choisi la voix individuelle. L’histoire numérique expérimente la quantification sans prétendre que les nombres épuisent le sens. Même l’histoire globale la plus intéressante, celle de Subrahmanyam par exemple, fonctionne parce qu’elle suit des connexions spécifiques au lieu de dessiner des fresques omnicompréhensives. Dans chacune de ces approches, il y a quelque chose que les Annales avaient pressenti (importance des structures, dialogue avec d’autres disciplines, attention aux temps longs) mais débarrassé de l’hubris systématique, de la prétention que tout se tienne, que le cercle se ferme. Le cercle ne se ferme jamais, en histoire. Et c’est précisément cette incomplétude qui rend la discipline intéressante, non pas malgré ses limites épistémologiques mais grâce à elles. Les Annales, dans leurs versions les plus ambitieuses, ne l’ont jamais accepté. Et cette incapacité à accepter la limite est, en fin de compte, leur limite la plus grande.

Pas une critique. Une observation sur un angle mort structurel du marché de l’advisory IT. Les personnes qui conseillent l’achat de techno, dans la grande majorité, n’en ont jamais vendu. Et celles qui en vendent et en livrent n’ont pas voix au chapitre dans la définition des best practices de sourcing. Résultat : un déficit informationnel qui coûte de l’argent réel à ceux qui achètent et à ceux qui vendent.

Je le dis en connaissance de cause. Je gère une petite ICT qui vit de contrats avec des clients mid-market et de la fonction publique. J’ai écrit des devis, négocié des contrats, défini des SLA, géré des escalades, subi des pénalités, livré des projets en retard et en avance. J’ai vu le marché des services IT du côté du tablo où les analystes de sourcing voient rarement. Et ce que je vois ne correspond pas toujours à ce que les frameworks d’advisory décrivent.

Premier angle mort : le pricing

La plupart des frameworks évaluent les prestataires au coût par jour-homme ou point fonction. Métriques compréhensibles, comparables, fondamentalement obsolètes. L’IA rend la relation entre temps de travail et valeur livrée complètement non linéaire. Une équipe de cinq avec coding agentique livre en une semaine ce qu’une équipe de quinze livrait en un mois. Valeur identique pour le client. Coût en jours-homme : un cinquième. Si le client paie au jour-homme, le prestataire a un incitatif pervers à ne pas adopter l’IA — il facture moins. S’il l’adopte et que le client continue à valoriser au jour-homme, il paraît cinq fois plus cher par jour, même si le coût total du projet baisse.

Pas un problème théorique. Je l’affronte chaque mois en présentant des devis. J’ai cessé de chiffrer au jour-homme il y a plus d’un an. Je chiffre au livrable : voilà le résultat, voilà le prix, voilà les conditions. Certains clients apprécient. D’autres — surtout dans la PA, où les appels d’offres sont structurés autour des jours-homme — ne savent pas le gérer. Le cadre d’achat ne prévoit pas un prestataire qui livre plus de valeur en moins de temps.

Deuxième angle mort : la compliance comme critère de sourcing

Les frameworks commencent à l’ajouter. Mais comme case à cocher : « le prestataire est-il conforme RGPD ? oui/non ». Radicalement insuffisant. La compliance n’est pas binaire. Un prestataire peut avoir une politique privée sur le site et aucun mécanisme technique de data minimization dans le code. Déclarer être AI Act compliant sans avoir idée de ce qu’est une évaluation de risque pour des systèmes IA à haut risque. Cocher « SBOM » sans avoir une pipeline qui génère le SBOM automatiquement à chaque build.

Un framework sérieux, dans le contexte EU d’aujourd’hui, devrait évaluer la compliance non comme déclaration mais comme capacité technique. Le prestataire a-t-il un processus documenté de vulnerability handling ? Sa pipeline CI/CD inclut-elle un scan des dépendances ? Ses SBOM sont-ils générés automatiquement ou compilés à la main ? Son software a-t-il des tests automatiques vérifiant des propriétés de privacy ? Ces questions sont plus révélatrices que toute certification. Et seules les personnes ayant l’expérience opérationnelle savent les formuler.

Troisième angle mort : les PME IT

Le marché de l’advisory est structuré autour des grands SI. Les matrices, les Magic Quadrant, les Wave, les Provider Lens : tous calibrés sur des entreprises facturant des centaines de millions. Les PME IT — qui en Europe représentent la grande majorité des prestataires de software — sont invisibles. Pas parce qu’elles ne livrent pas de la valeur, mais parce qu’elles n’ont pas l’échelle pour participer aux processus d’évaluation des analystes.

Paradoxe. Le client mid-market — la boîte de 200-500 personnes, l’ARS, la mairie, la chambre de commerce — lit les rapports et n’y voit que les grands noms. Mais les grands noms ne servent pas le mid-market italien, ou le servent avec des juniors supervisés par un partner qu’on ne voit jamais. Le prestataire qui livre vraiment — la PME locale de dix personnes, un senior par projet, relation directe avec le décideur — n’apparaît dans aucun framework. Gap informationnel total.

Quatrième angle mort : la gouvernance des contrats

Les frameworks sont bons à évaluer la phase de sélection : choisir, comparer, négocier. Bien moins bons sur la phase d’exécution : surveiller, intervenir quand ça va mal, gérer le changement de scope. Or, dans mon expérience, 90 % des problèmes ne viennent pas du choix du prestataire mais de la gestion du contrat ensuite.

J’ai vu des projets échouer non par incompétence du prestataire mais parce que le client n’avait pas de gouvernance interne pour décider des changements d’exigences. Vu des SLA négociés au centime que personne ne surveillait. Vu des pénalités contractuelles jamais appliquées parce que le client dépendait trop du prestataire pour le sanctionner. Patterns récurrents que tout prestataire connaît intimement et que les frameworks d’advisory traitent comme des exceptions.

Cinquième angle mort : qualité technique et business

Peut-être le plus profond : la relation entre qualité technique et résultat business. Les frameworks évaluent prix, track record, taille d’équipe, certifications. Rarement la qualité technique du logiciel produit. Combien de tests automatiques dans le codebase ? Quelle couverture ? Comment l’archi est-elle structurée ? Le code est-il maintenable ? La doc est-elle à jour ? Ce sont les dimensions qui déterminent le TCO réel — pas le déclaré — et les analystes de sourcing ne sont pas équipés pour les évaluer.

Résultat : le marché récompense la capacité à vendre — présentations convaincantes, références solides, équipes nombreuses — plutôt que la capacité à construire. Et c’est ce qui explique pourquoi tant de projets IT coûtent le double du prévu et livrent la moitié de la promesse : la sélection se fait sur des critères qui ne prédisent pas la qualité de l’exécution.

J’écris ces choses non pour le plaisir de critiquer un secteur que je respecte et qui, franchement, m’intéresse. Je les écris parce que je crois que le marché de l’advisory IT est à un point d’inflexion. L’IA change l’économie de la livraison. La compliance européenne change les critères d’achat. Le mid-market européen a besoin de frameworks qui ne soient pas des versions simplifiées de ceux de l’enterprise. Et les prestataires IT — ceux qui construisent et livrent vraiment le software — ont un savoir opérationnel qui, intégré dans les frameworks d’advisory, les rendrait beaucoup plus utiles.

Je ne prétends pas avoir la solution. Mais après quinze ans de l’autre côté du tablo, je sais quelles questions devraient être posées et ne le sont pas. Je sais quelles métriques prédisent le succès d’un projet et lesquelles prédisent seulement la qualité de la présentation initiale. Je sais ce qui change dans le pricing quand l’IA entre dans le cycle de livraison. Je sais ce que veut dire compliance dans un codebase de production, pas dans un document de policy.

C’est un savoir que le marché de l’advisory n’a pas — non par incompétence, mais par séparation structurelle d’avec la livraison. Et c’est peut-être le moment de bâtir un pont.

Pendant la majorité de l’histoire de la technique, il était possible de trouver au moins une personne qui comprenait un artefact dans son ensemble. L’aqueduc romain, le métier mécanique, la locomotive à vapeur, même un avion de la Seconde Guerre mondiale : systèmes compliqués, certes, mais en fin de compte ramenables à un savoir unitaire. Un ingénieur suffisamment formé pouvait tracer la chaîne causale d’un bout à l’autre. Il pouvait dire : je sais comment ça marche, pourquoi ça marche, ce qui se passe si ça casse. Cette possibilité n’était pas un détail. C’était le fondement de l’idée même de compétence technique — et avec elle, de responsabilité.

Ce fondement n’est plus là.

Le seuil

Le point de rupture ne fut pas soudain. Il s’est accumulé sur des décennies, invisible comme tous les changements par stratification plutôt que fracture. Chaque niveau d’abstraction ajouté au-dessus du précédent résolvait un problème et en créait un autre : rendre opaque le niveau inférieur. Le développeur applicatif d’aujourd’hui ne connaît pas vraiment le framework qu’il utilise. Qui connaît le framework ne connaît pas le runtime. Qui connaît le runtime ne connaît pas l’OS, pas vraiment. Qui connaît l’OS ne connaît pas le microcode du processeur. Et personne, vraiment personne, ne connaît la chaîne entière de dépendances qu’une seule commande d’installation télécharge depuis le réseau et intègre à son logiciel.

Pas une exagération polémique. Une description factuelle. Un projet logiciel moyen, en 2026, comprend des centaines de dépendances directes et des milliers de dépendances transitives. Chacune écrite par quelqu’un d’autre, avec ses propres dépendances, ses propres vulnérabilités, ses propres décisions d’archi prises dans un contexte que personne en aval ne reconstruira jamais. Exécuter du logiciel aujourd’hui, c’est faire confiance. Pas au sens noble de la confiance entre personnes, mais au sens épistémologique de qui renonce à vérifier parce que la vérification est matériellement impossible.

Il y a eu une époque où le mot « ingénieur » impliquait la possibilité d’un contrôle total sur son objet de travail. Cette époque est finie. Elle ne reviendra pas.

Le savoir comme illusion d’échelle

Le problème n’est pas qu’on en sait peu. C’est que le type de savoir qu’on possède n’est pas commensurable à la complexité de ce qu’on opère. On sait des choses. On en sait même beaucoup. Mais le savoir nécessaire pour comprendre un système distribué moderne n’est pas la somme des savoirs individuels : c’est un savoir qui demanderait un esprit capable de tenir simultanément des couches conçues pour être séparées.

L’abstraction, mécanisme fondamental de la pensée computationnelle, fonctionne précisément parce qu’elle cache. C’est son mérite et son piège. Une interface bien conçue te libère du besoin de savoir ce qui se passe dessous. Mais quand quelque chose tourne mal, tu découvres que « dessous » il y a un monde que personne dans la pièce ne connaît, et que personne au monde ne connaît peut-être dans son ensemble. Pas parce que le savoir n’existe pas, mais parce qu’il est distribué de manière irrécupérable entre des milliers de personnes qui ne se sont jamais parlé.

Une condition épistémologique nouvelle. Sans précédent dans l’histoire de la technique, et avec peu d’analogues dans l’histoire de la pensée. Le plus proche serait peut-être le problème de la division du travail chez Adam Smith, mais avec une différence essentielle : Smith parlait d’un processus productif où chaque ouvrier comprenait son morceau. Ici, personne ne comprend vraiment même son propre morceau, parce qu’il repose sur d’autres morceaux qui échappent par définition.

La chaîne brisée de la responsabilité

Si personne ne comprend le système dans son ensemble, la question de qui est responsable n’a pas de réponse satisfaisante. Pas faute de candidats, mais parce que le concept même de responsabilité présuppose ce qui manque ici : la possibilité de savoir.

Responsabilité, à la racine, signifie capacité à répondre. À rendre compte de ses choix. Mais comment rendre compte d’un choix fait dans un contexte qu’on ne pouvait comprendre entièrement ? Comment répondre d’un système dont le comportement émerge d’interactions entre composants qu’aucun acteur n’a conçus ni prévus ?

Le droit, qui a réfléchi à cela bien plus que l’informatique, a développé l’idée de diligence : pas besoin de tout comprendre, il suffit d’agir avec le soin raisonnablement attendu de qui exerce ce rôle. Compromis pragmatique, qui a marché des siècles. Il marchait parce que l’écart entre le savoir possible et la décision nécessaire était comblé par l’étude et l’expérience. Aujourd’hui cet écart n’est plus comblable. Pas un défaut d’engagement : un écart structurel, produit par la complexité de l’objet, pas par l’inadéquation du sujet.

La législation européenne récente l’intuitionne, sans le déclarer. CRA, PLD, AI Act : tous tentent de reconstruire des chaînes de responsabilité dans un contexte où ces chaînes sont physiquement brisées. Avec des outils classiques : obligations de doc, évaluations de conformité, registres de risque. Tentatives sérieuses, souvent bienvenues. Mais elles reposent sur un présupposé silencieux : qu’il y a quelque part quelqu’un qui sait.

Le producteur doit documenter les risques de son produit. Mais il ne connaît pas les dépendances transitives de son code. L’importateur doit vérifier la conformité. Mais la conformité est définie par rapport à des standards décrivant des propriétés que personne ne peut vérifier en pratique. L’utilisateur doit donner un consentement éclairé. Mais l’information nécessaire à un consentement véritable demanderait des compétences que même l’auteur du logiciel ne possède pas.

Pas du cynisme. La description précise d’une situation qu’on a créée pas à pas, en bonne foi, en résolvant chaque problème immédiat et en ajoutant à chaque fois un gramme d’opacité au système global.

Le mythe de la spécialisation

Une réponse fréquente : la spécialisation résout le problème. Personne n’a besoin de tout comprendre, il suffit que chacun comprenne son morceau, et l’ensemble marchera. C’est la division du travail appliquée au savoir, et c’est attractif parce que ça permet d’éviter la question de fond.

Mais ça ne marche pas. Parce que les frontières entre « morceaux » sont arbitraires et perméables. Un problème de sécurité traverse toutes les couches. Une exigence normative coupe transversalement frontend, backend, infra, fournisseurs tiers. Une décision d’archi prise il y a cinq ans dans un contexte qui n’existe plus contraint aujourd’hui des choix que celui qui la prit n’aurait pu imaginer.

La spécialisation marche quand les composants sont vraiment indépendants. Le software ne l’est pas. Il est fait de dépendances, au sens littéral : chaque partie dépend d’autres parties, et le comportement de l’ensemble n’est pas déductible de celui des parties. C’est ce que la théorie des systèmes appelle émergence, et l’émergence est précisément l’adversaire de la spécialisation. Le bug le plus tordu vit toujours dans l’espace entre les spécialisations, là où personne ne regarde parce que personne ne pense que c’est son territoire.

L’incompétence du législateur

Un cas particulier mérite attention, pas par esprit accusatoire mais parce qu’il est structurellement éclairant : l’incompétence de qui écrit les normes.

Un législateur qui rédige des règles sur le software est dans la même position épistémologique que tout le monde : il ne peut pas comprendre le système dans son ensemble. Mais à la différence d’un dev ou d’un architecte, il n’a même pas la connaissance partielle de l’usage quotidien. Il opère sur des descriptions de descriptions, sur des abstractions d’abstractions, médiées par des consultants qui à leur tour médient le savoir de spécialistes.

Pas un argument contre la régulation. Au contraire : un argument sur la nature de la régulation possible. Encadrer ce qu’on ne comprend pas entièrement n’est pas un échec, c’est la condition de départ. La question n’est pas si le législateur est compétent — il ne peut pas l’être au sens plein, et pas par sa faute. La question est si les normes qu’il produit sont assez robustes pour fonctionner malgré l’incompétence structurelle de qui les a écrites, de qui doit les appliquer, de qui doit les vérifier.

Parfois la réponse est oui. Le RGPD, avec ses limites, a introduit un principe de précaution qui marche précisément parce qu’il n’exige pas une compréhension technique : il traite les données personnelles comme dangereuses, indépendamment du fait qu’on saisisse les mécanismes spécifiques du danger. Une norme conçue pour l’incompétence — et qui marche mieux que beaucoup de normes qui présupposent la compétence.

Socrate dans le cycle de dev

Une phrase est attribuée à Socrate avec la fréquence et l’imprécision réservées à toutes les phrases trop utiles : « je sais que je ne sais rien ». Citée comme geste d’humilité, parfois comme coquetterie. Mais dans sa version la plus radicale, celle de l’Apologie platonicienne, le point est plus inconfortable : Socrate ne dit pas simplement que sa connaissance est limitée. Il dit que celui qui croit savoir est dans une condition pire que celui qui sait qu’il ne sait pas, parce qu’à l’ignorance il ajoute l’illusion.

Appliquée au présent technologique, la thèse socratique prend un poids que Platon n’aurait pu imaginer. L’industrie du software est bâtie sur une double illusion de savoir : celle de qui construit (qui croit contrôler) et celle de qui utilise (qui croit comprendre). Toutes deux fonctionnelles. Sans la première, personne n’écrirait de code, parce que l’honnêteté intégrale serait paralysante. Sans la seconde, personne n’utiliserait de software, parce que le consentement éclairé authentique produirait un refus de masse.

Nous fonctionnons grâce à une suspension volontaire de l’incrédulité épistémologique. Pas autrement que la finance, ou la politique, ou tout autre système complexe où la confiance remplace la compréhension.

Différence quand même. Finance et politique ont développé une conscience institutionnelle de leur fragilité épistémologique. Les banques centrales existent parce qu’on sait que le système financier ne s’autorégule pas. Les constitutions existent parce qu’on sait que le pouvoir ne s’autolimite pas. L’informatique n’a rien d’équivalent. Pas d’institutions conçues pour gérer le fait que personne ne sait. Standards, best practices, frameworks de certification : tous outils qui présupposent la possibilité du savoir au lieu d’affronter son impossibilité.

Décider sans savoir

La condition quotidienne de qui travaille dans la techno : décider sans savoir. Pas au sens dramatique d’un pari aveugle, mais au sens ordinaire et un peu usant de qui prend chaque jour des décisions aux conséquences pluriannuelles, basées sur des informations qu’on sait incomplètes, dans des contextes qu’on sait destinés à changer, pour des exigences qu’on sait provisoires.

Une estimation est une déclaration de probabilité subjective vendue comme prévision. Un choix d’archi est un acte de foi dans la stabilité de conditions qui ne le sont pas. Un refactoring est un pari sur le fait que le coût présent sera payé par des bénéfices futurs que personne ne peut garantir. Chaque sprint est un exercice d’épistémologie appliquée sous contrainte temporelle, mené par des gens qui n’ont pas étudié l’épistémologie et qui ne sont pas payés pour réfléchir aux conditions de possibilité de leur savoir, mais pour produire.

Pas une dénonciation. Une description. Et le point n’est pas que les choses devraient aller autrement : c’est qu’elles ne peuvent pas aller autrement. L’incompétence structurelle n’est pas un problème à résoudre. C’est la condition dans laquelle nous opérons, et qui durera tant qu’on construira des systèmes dont la complexité excède la capacité de compréhension de qui les construit.

La question n’est pas comment éliminer l’incompétence. C’est comment l’habiter.

Habiter l’incompétence

Si la compétence, au sens classique de maîtrise complète, n’est plus atteignable, alors ce qu’on appelle de ce nom est devenu autre chose. Pas un savoir, mais un savoir-faire en l’absence de savoir. Une forme de sagesse pratique plus proche de la phronésis aristotélicienne que de l’épistémè : non la connaissance des causes premières, mais la capacité à bien agir dans des situations particulières et incertaines.

Le bon technicien aujourd’hui n’est pas celui qui sait le plus. C’est celui qui gère le mieux son ignorance. Qui sait où sont les limites de ce qu’il comprend, qui sait demander, quand s’arrêter, comment construire des systèmes qui échouent de façon prévisible plutôt que catastrophique. Ce sont des compétences, mais sur sa propre incompétence. Des méta-compétences, si on accepte un mot moche pour une idée importante.

Et là, un paradoxe à regarder en face. La culture pro du software récompense le savoir et punit le non-savoir. Qui admet ne pas comprendre perd en crédibilité. Qui dit « je ne sais pas » en réunion est perçu comme faible. Qui estime honnêtement est puni dans la comparaison avec qui estime avec optimisme. Tout le système d’incitations est conçu pour masquer l’incompétence plutôt que la gérer, ce qui produit le résultat inverse : incompétence non reconnue, non gérée, non métabolisée. Incompétence dangereuse.

Une culture pro mature ferait l’inverse. Elle partirait du fait que personne ne comprend le système entier, et bâtirait processus, outils, institutions conçus pour fonctionner dans cette condition. Pas une utopie : c’est de l’ingénierie de l’ignorance, et c’est exactement ce qu’on fait quand on écrit des tests automatisés (on vérifie parce qu’on ne se fie pas à sa compréhension), quand on fait des code reviews (on cherche les erreurs que notre angle mort nous cache), quand on adopte le principe de moindre privilège (on limite le dommage que notre ignorance peut causer).

Pas des palliatifs. Les pratiques les plus sophistiquées que l’industrie ait produites, et toutes, à la racine, des techniques de gestion de l’incompétence. Personne ne les nomme ainsi parce que le nom serait gênant. Mais elles le sont.

L’honnêteté comme méthode

Peut-être la seule réponse disponible à l’incompétence structurelle n’est pas une solution mais une attitude : l’honnêteté épistémologique comme pratique quotidienne. Savoir qu’on ne sait pas, non comme formule creuse, mais comme point de départ opératoire de chaque décision.

Pas la paralysie. Décider en sachant qu’on décide à l’aveugle, et bâtir des filets de sécurité proportionnés à cette conscience. Documenter non seulement ce qu’on a fait, mais pourquoi et sur quels présupposés — parce que ces présupposés se révéleront faux et que les suivants auront besoin de comprendre non la solution, mais le raisonnement qui l’a produite. Cesser de traiter les estimations comme des promesses et les architectures comme des monuments.

Pas une proposition révolutionnaire. La description de ce que les meilleurs font déjà, souvent en silence, souvent à contre-courant de la culture qui les entoure. L’incompétence structurelle n’est pas un ennemi à vaincre. C’est le terrain sur lequel nous marchons, et le seul choix disponible est entre marcher les yeux ouverts ou les yeux fermés.

Nous, comme espèce, avons construit un monde que nous ne sommes pas capables de comprendre. Pas une tragédie. Peut-être la chose la plus humaine que nous ayons jamais faite.

Et c’est de cette position, pas de celle du critique externe ou du commentateur du lundi matin, que je vous dis ce que notre industrie refuse d’entendre : la plupart du logiciel qui existe ne devrait pas exister.

Pas parce qu’il est mal fait. Une partie l’est, oui, mais ce n’est pas le sujet. Il ne devrait pas exister parce qu’il ne résout aucun problème. Ou en résout un que personne n’a. Ou en résout un déjà résolu, et plus mal. Ou, cas le plus fréquent et le plus insidieux, il crée le problème qu’il prétend ensuite résoudre.

Le cimetière des problèmes inventés

Ouvre ton téléphone. Compte les apps. Combien utilises-tu vraiment ? Combien résolvent un problème réel dans ta vie ? Et combien existent parce que quelqu’un a monté un pitch deck convaincant, levé un round, construit ce que personne n’avait demandé ?

Phénomène pas marginal. Modèle dominant des quinze dernières années.

Le cycle : on identifie un « pain point » (presque toujours une gêne mineure élevée en tragédie existentielle), on construit un MVP, on lève des fonds, on recrute des devs, on scale. À un moment le logiciel existe, a des utilisateurs, génère du revenu. Mais personne ne s’est arrêté pour se demander si le monde en avait besoin. La question était hors-sujet. La question pertinente : ça croît ?

J’ai vu des apps pour partager des listes de courses entre colocs. Des plateformes de prise de RDV chez le coiffeur avec IA. Du SaaS pour gérer ses plantes d’appartement. Des marketplaces pour échanger des vêtements usagés pour chien. Je n’invente pas. Chacun a reçu des financements, eu une équipe de devs, consommé des serveurs, de l’énergie, du temps humain.

Le problème n’était pas qu’ils étaient laids. Certains étaient techniquement impeccables. Le problème : ils n’avaient pas de raison d’exister. Et personne ne le disait, parce que dire ça, c’était être celui qui « ne comprend pas l’innovation ».

L’impôt caché

Le logiciel n’est jamais gratuit. Même quand il ne coûte rien à l’utilisateur, il coûte au monde.

Énergie. Chaque app inutile tourne sur des serveurs qui consomment de l’électricité. Chaque SaaS inutile a une base répliquée sur trois zones, du monitoring, un CDN global. Le cloud n’est pas un nuage : un hangar plein de machines qui chauffent, en Irlande ou en Virginie, sur un réseau électrique aux limites physiques.

Attention. Chaque logiciel inutile installé sur un téléphone rivalise avec tout le reste pour cette attention : le travail, les relations, le sommeil, l’ennui productif, la pensée non structurée. Et l’attention est finie. Chaque app inutile la vole à plus important.

Complexité. Chaque logiciel ajoute une interface, un login, un mot de passe, encore des notifications, encore des CGU que personne ne lit, encore un flux de données personnelles parti on ne sait où. La complexité de notre environnement numérique grossit chaque année — pas parce que les problèmes se multiplient, mais parce que les solutions se multiplient plus vite que les problèmes.

Talent. Le coût qui me met le plus en colère. Il y a dans le monde des devs au talent extraordinaire qui passent leurs journées à optimiser le funnel d’une app pour commander du café avec trois taps en moins. Des gens qui pourraient construire du logiciel qui sauve des vies, rend l’éducation accessible, améliore la santé publique. Ils optimisent la couleur d’un bouton « Acheter ».

Pas leur faute. Le marché paie mieux le bouton. Mais c’est un gaspillage si obscène qu’il faudrait avoir la décence de le nommer.

« Mais le marché décide »

L’objection. Si un logiciel existe et a des utilisateurs, le marché a décidé qu’il sert. La main invisible, l’offre, la demande, etc.

Sauf que faux. Le marché du logiciel ne fonctionne pas comme celui des pommes.

Premier : le coût marginal de distribution est près de zéro. Un logiciel touche des millions d’utilisateurs sans que la qualité ou la nécessité ne soient testées par un vrai feedback. Un primeur qui vend des pommes pourries fait faillite en une semaine. Une app qui ne résout rien peut survivre des années, financée par le VC, jusqu’au prochain round ou à l’acquéreur.

Deuxième : le modèle pub a découplé valeur et prix. Quand l’utilisateur ne paie pas, le produit n’a pas besoin d’être utile pour lui. Il doit être utile à l’annonceur. Et pour l’annonceur, c’est l’attention qui compte, pas la satisfaction. Des logiciels qui rendent les gens malheureux mais collés à l’écran sont d’énormes succès commerciaux. Le marché « a décidé » qu’ils servent. Mais ce marché-là est malade.

Troisième : les network effects créent des monopoles naturels. Une fois que tout le monde utilise une plateforme, tu ne peux pas ne pas l’utiliser. Pas parce qu’elle est bonne, parce que tout le monde y est. Le marché n’a pas « décidé » que WhatsApp est le meilleur moyen de communiquer. Il a décidé que c’est le moyen par lequel tout le monde communique — chose toute différente.

L’acte radical de ne pas construire

Dans la culture tech, construire est toujours positif. « Makers gonna make. » « Ship it. » « Build in public. » Le verbe construire a une aura sacrée, et qui construit est par définition du bon côté de l’histoire.

Mais il y a un acte plus courageux : décider de ne pas construire.

Décider que le monde n’a pas besoin d’un nouveau task manager. Qu’un Excel fait mieux que ton app. Que le problème n’est pas un problème. Que ton talent et ton temps sont mieux ailleurs.

Les meilleurs techs que j’ai connus étaient ceux capables de dire « pas besoin ». Pas par paresse, pas par cynisme. Par respect. Pour le problème, l’utilisateur, la complexité du réel. Ils savaient qu’ajouter du logiciel à un contexte ajoute de la complexité, des dépendances, de la maintenance, de la dette technique. Et que le faire sans raison forte est un acte d’irresponsabilité déguisé en productivité.

La philosophie Unix le disait il y a quarante ans : fais une seule chose, et fais-la bien. Pas « fais tout ». Pas « fais des trucs nouveaux parce que tu peux ». Une seule chose. Le reste, laisse-le.

Le logiciel qui devrait exister

Je ne dis pas que le logiciel est l’ennemi. Ce serait dire que l’écriture est l’ennemi parce qu’il existe de mauvais livres.

Le logiciel qui devrait exister est celui qui élargit les capacités humaines sans créer de dépendance. Qui résout un problème réel et vérifiable. Qui marche pour qui l’utilise, pas pour qui le vend. Qu’on peut arrêter d’utiliser sans conséquence. Qui n’a pas besoin de te capturer pour justifier son existence.

Le logiciel qui devrait exister est celui dont on remarquerait l’absence s’il disparaissait demain. Pas l’absence compulsive du toxico, mais l’absence concrète de qui a perdu un outil utile. Comme perdre un bon couteau de cuisine. Comme perdre un vélo fiable.

C’est la métrique à utiliser : s’il disparaît, le sentirais-tu ? Si la réponse est « probablement non », il ne devrait pas exister. Si la réponse est « je ne saurais même pas qu’il est parti », ce logiciel gaspille les ressources de la planète et le temps de qui l’a construit.

La responsabilité de qui construit

À chaque décision de construire, on prend une décision sur des ressources réelles. Temps de devs. Énergie des serveurs. Attention des utilisateurs. Complexité de l’écosystème numérique. Dans un monde aux ressources finies et aux problèmes énormes, construire de l’inutile n’est pas neutre. C’est du gaspillage actif. Une mauvaise allocation d’intelligence humaine.

L’ingénieur civil doit justifier l’utilité d’un pont. L’architecte doit prouver qu’un bâtiment répond à un besoin. Le médecin ne prescrit pas un médicament parce qu’il existe. Pourquoi le logiciel devrait-il être différent ? Pourquoi accepterions-nous que 90 % de ce que nous construisons finisse oublié dans un App Store, ignoré par ses créateurs après six mois, abandonné avec les données des utilisateurs dedans et les serveurs encore allumés ?

La vraie innovation, en 2026, n’est pas de construire plus. C’est de construire moins, mieux, pour de meilleures raisons.

Et avoir le courage de dire, parfois, « non, ça on ne le fait pas ». Pas parce qu’on ne peut pas. Parce que ça ne sert pas.

Le luxe de la soustraction

Il y a un concept en architecture que le monde du software n’a jamais appris : la valeur du vide.

Un bon architecte ne remplit pas chaque mètre carré. Il sait que l’espace vide n’est pas une absence. C’est de la respiration. De la possibilité. La place qu’il faut à qui habite pour bouger, penser, vivre. Un bâtiment plein jusqu’au dernier centimètre n’est pas un chef-d’œuvre d’efficacité. C’est une prison.

Notre paysage numérique est un bâtiment plein jusqu’au dernier centimètre. Chaque espace est occupé par une app, un service, une plateforme, une notification. Pas de respiration. Pas de vide. Pas de silence.

Et au milieu de tout ce bruit, le logiciel vraiment utile, celui qui résout les vrais problèmes, se perd. Devient invisible. Pas parce qu’il est moins bon, mais parce qu’il est submergé sous des tonnes de logiciel qui ne devrait pas exister.

La soustraction est un acte créatif. Choisir de ne pas construire est une décision de design. Et dans une industrie qui ne sait pas dire non à rien, c’est peut-être la compétence la plus rare et la plus précieuse.

Le meilleur logiciel que j’aie jamais écrit est celui que j’ai décidé de ne pas écrire.

Puis tu rentres. Et ton enfant est devant un écran. Et cet écran fait exactement ce que toi, tu sais faire : capter l’attention, générer de l’engagement, maximiser le temps de présence.

Sauf que cette fois l’utilisateur n’est pas un utilisateur. C’est ton enfant.

La dissonance

Si tu bosses dans la tech et que tu as des enfants, tu vis une dissonance que presque personne ne nomme. Le jour tu conçois des systèmes pensés pour retenir les gens. Le soir tu essaies de détacher ton enfant de systèmes identiques. Le jour tu parles de « user retention » comme d’un succès. Le soir, la « rétention » de ton enfant devant la tablette te fait peur.

Tu sais comment marche le pull-to-refresh. Tu l’as implémenté, ou au moins tu en as discuté l’implémentation. Tu sais qu’il reproduit le geste de la leva d’une machine à sous. Tu sais que le délai avant le chargement n’est pas une limite technique mais un design pattern : la pause calculée qui maximise la libération de dopamine. Tu le sais parce que c’est ton métier de le savoir.

Et tu sais que ton enfant, à huit, dix, douze ans, n’a aucun outil pour se défendre de ce que toi tu sais construire.

Ce n’est pas une contradiction personnelle. C’est une contradiction de système. Elle concerne quiconque travaille dans la tech et a des enfants — soit des millions de gens à ce stade.

Ce qu’on sait et qu’on ne peut plus prétendre ignorer

Mettre les choses en face aide.

On sait que les schémas de renforcement à ratio variable — base des feeds sociaux — sont le mécanisme psychologique le plus puissant jamais documenté pour induire et maintenir un comportement compulsif. On le sait depuis les années 50. Skinner l’a démontré sur les pigeons. Nous l’appliquons aux enfants.

On sait que le cerveau d’un adolescent est en plein développement. Le cortex préfrontal — jugement, contrôle des impulsions, évaluation des conséquences — n’achève sa maturation qu’avant 25 ans. On conçoit des systèmes qui le contournent délibérément pour parler au système limbique. Métier.

On sait que l’usage habituel des réseaux est associé à une réduction mesurable de l’épaisseur corticale dans les régions liées au contrôle cognitif. Pas des opinions : de la données IRM sur des milliers d’ados.

On sait que les taux de dépression, anxiété, automutilation et suicide chez les ados ont doublé ou triplé depuis 2010, parallèlement à la diffusion des smartphones, dans tout le monde occidental.

On sait que les plateformes le savent. Les documents internes Meta publiés par Frances Haugen montraient qu’Instagram aggravait les problèmes d’image corporelle pour une fille sur trois. L’entreprise le savait. Elle a continué.

On sait tout ça. Et on continue à construire.

« Mais je ne bosse pas dans le social »

Je sais. Moi non plus. Je construis des outils de gestion, des plateformes pour le secteur public, du logiciel B2B. Je ne conçois pas des feeds algorithmiques ni n’optimise des systèmes de reco pour ados.

Mais le point n’est pas ce qu’on construit aujourd’hui. C’est la culture dans laquelle on le construit.

Nous travaillons dans une industrie qui a normalisé l’idée que l’attention humaine est une ressource à extraire. Que la « UX » est synonyme de « temps que l’utilisateur passe sur la plateforme ». Que le succès se mesure en sessions, clics, conversion rate, daily active users. On parle d’êtres humains avec le vocabulaire de l’industrie minière, et ça ne nous semble pas étrange.

Cette culture nous traverse tous. Même qui ne bosse pas dans le social en respire les métriques, les valeurs, les priorités. Quand on rentre, cette culture rentre avec nous. Elle s’insinue dans la façon dont on regarde l’écran de notre enfant. Avec inquiétude, oui, mais aussi avec une subtile, inavouable familiarité. On reconnaît ces mécanismes. On sait qu’ils marchent. Et une part de nous, la part professionnelle, ne peut s’empêcher de les admirer.

C’est cette familiarité qu’il faut briser.

Le privilège de la conscience

Qui travaille dans la tech et a des enfants possède quelque chose que la plupart des parents n’ont pas : la connaissance de l’architecture.

On sait comment fonctionnent ces systèmes, pas seulement qu’ils fonctionnent. On sait que les notifications n’arrivent pas au hasard mais sont optimisées pour le moment de vulnérabilité psychologique maximale. On sait que le scroll infini n’est pas un choix esthétique mais un dispositif de capture. On sait que « l’algorithme » n’est pas une entité mystérieuse : c’est du code écrit par des gens comme nous, avec des objectifs précis, optimisé sur des métriques précises.

Cette conscience est un énorme privilège. Et le privilège crée la responsabilité. Si tu vois le feu et pas les autres, tu ne peux pas faire semblant et dire « ce n’est pas mon incendie ».

Pourtant c’est exactement ce qu’on fait, comme industrie. On sait. Et on se tait. Parce que parler reviendrait à admettre que le problème n’est pas « là-dehors » — chez les ados, l’incompétence des parents, le manque d’« éducation numérique ». Le problème est aussi dedans. Dans la façon dont on pense le software. Dans les métriques qu’on choisit d’optimiser. Dans les questions qu’on ne se pose pas.

Les questions qu’on ne se pose pas

En vingt ans de carrière dans la tech, je n’ai jamais entendu personne, en réunion projet, poser ces questions :

Ce système peut-il créer de la dépendance ? Si oui, avons-nous la responsabilité d’en prévenir les effets ?

Concevons-nous pour le bien-être de l’utilisateur ou pour la maximisation de son temps d’usage ? Est-ce la même chose ?

Si un mineur utilisait ce produit, serait-il sûr ? Pas « conforme à la norme ». Sûr.

Mesurons-nous le succès avec des métriques alignant nos intérêts avec ceux de l’utilisateur ? Ou avec ce qui nous arrange à mesurer ?

Construirions-nous ce système exactement ainsi si on savait que le premier utilisateur sera notre enfant ?

La dernière question est la plus importante. C’est celle qu’on ne pose jamais.

Le test de l’enfant

Je propose une règle. Pas une loi, pas un framework, pas un processus. Une règle personnelle, pour quiconque construit du logiciel et a des enfants.

Avant d’implémenter un système, demande-toi : ça va si le premier utilisateur est mon enfant ?

Pas « mon enfant à vingt ans, adulte, conscient, formé ». Mon enfant maintenant. Avec l’âge qu’il a. Avec le cortex préfrontal qu’il a. Avec la capacité de résistance aux stimuli qu’il a. Avec la confiance aveugle dans la technologie qu’il a.

Si oui, construis. Si « ça dépend », arrête-toi et demande-toi de quoi. Si non, tu as un problème. Et le problème n’est pas ton enfant.

Pas un test sentimental. Un test de conception. Le principe de précaution traduit dans la langue du dev. La version appliquée de l’impératif de Hans Jonas : agis pour que les conséquences de ton action soient compatibles avec la permanence d’une vie humaine authentique.

Sauf que Jonas parlait de bombes atomiques et de génie génétique. Nous parlons de feeds algorithmiques et de notifications push. Le fait qu’ils paraissent inoffensifs est exactement ce qui les rend dangereux.

On n’est pas impuissants

Je sais ce que tu penses. « Je suis salarié. Freelance. Tech lead dans une boîte de dix. Je ne décide pas des politiques de Meta. » C’est vrai. Tu ne les décides pas.

Mais tu décides comment tu construis ton logiciel. Quelles métriques optimiser. Si tu implémentes un dark pattern ou si tu refuses. Si tu mets un timer ou un scroll infini. Si tu conçois un système qui respecte l’attention de l’utilisateur ou un qui la pille.

Surtout, tu décides quel type de pro tu veux être.

Tu peux être celui qui dit « le marché le demande » et qui implémente ce qu’on lui paye. Ou celui qui dit « ça, je ne le construis pas ainsi » et propose une alternative. Pas de l’idéalisme, de l’artisanat. Un menuisier sérieux n’utilise pas du bois pourri. Un cuisinier sérieux ne sert pas de la nourriture avariée. Un ingénieur sérieux ne signe pas un projet structurellement non sûr.

Pourtant dans le software, où les conséquences peuvent toucher des millions de gens et le cerveau d’une génération, on accepte des standards qu’on n’accepterait dans aucun autre métier.

Le manifeste

Je travaille dans la tech. J’ai un fils. Je ne peux plus tenir les deux séparés.

Mon fils n’est pas un utilisateur. Pas une métrique, pas une session, pas un daily active user. C’est un être humain avec un cerveau en développement, une capacité de jugement en construction, une confiance dans le monde qui dépend aussi de la façon dont moi, et les gens comme moi, construisons ce monde.

Mon métier a des conséquences. Pas les conséquences abstraites de la philosophie morale. Les concrètes d’un système qui tourne 24h/24 et interagit avec des millions de cerveaux. Si je n’en prends pas la responsabilité, qui ?

La compliance ne suffit pas. Respecter le RGPD, l’AI Act, l’EAA est le minimum, pas la cible. La question n’est pas « est-ce légal ? ». La question est « est-ce juste ? ». Deux questions différentes, et la seconde est plus importante.

La vitesse n’est pas une valeur. « Ship fast » n’est pas une vertu quand ce que tu lances peut nuire. La hâte est le refuge de qui ne veut pas penser aux conséquences. La pensée critique est lente par nature. Le code est rapide. La sagesse est de ne pas confondre les deux temps.

La formation technique ne suffit pas. Savoir écrire du code sans savoir lire ses implications n’est pas une compétence — c’est une cécité spécialisée. On a besoin d’ingénieurs qui ont lu Jonas, de devs qui connaissent Mill, de designers qui ont étudié la psychologie du développement. Pas comme culture générale. Comme outils de travail.

Mon fils me jugera. Pas pour le CA généré, pas pour les projets livrés, pas pour les techno maîtrisées. Pour le monde que j’ai contribué à construire. Et dans ce jugement, « je faisais juste mon boulot » ne sera pas une défense recevable. Ça ne l’a jamais été.

À ceux qui construisent

Si tu bosses dans la tech et que tu as des enfants, tu sais de quoi je parle. Tu sais qu’il y a une conversation que notre industrie refuse d’avoir. Tu sais que le malaise quand ton enfant disparaît dans un écran n’est pas de la paranoïa parentale. C’est de la compétence professionnelle qui te dit quelque chose.

Écoute-la.

Je ne dis pas d’arrêter de construire. Je dis : construis comme si le premier utilisateur était ton enfant. Parce qu’à toutes fins utiles, il pourrait l’être.

Et si ce n’est pas le tien, c’est celui de quelqu’un d’autre.

C’est la même chose, au fond.

« Nous n’avons pas hérité du monde de nos parents. Nous l’avons emprunté à nos enfants. » — proverbe attribué à Antoine de Saint-Exupéry.

Une chose à dire avant tout, parce que c’est la raison d’être de ce billet.

J’ai fait un lycée scientifique. Je suis diplômé en philosophie à Urbin, l’une de ces universités où la philosophie n’est pas un accessoire mais une manière d’être au monde, où l’on t’apprend que les questions comptent plus que les réponses et que « à quoi ça sert ? » est elle-même une question philosophique. Puis j’ai choisi la technologie. J’ai écrit du code, géré des infrastructures, construit des produits numériques pendant vingt ans. Et pendant vingt ans, on m’a répété, avec des nuances allant du bienveillant au sarcastique, que la philosophie « ne sert à rien ». Que dans le tech ce qui compte ce sont les langages, les frameworks, les déploiements. Que Kant et Popper sont des luxes décoratifs.

J’ai toujours su que c’était faux. Je le sentais chaque fois qu’en réunion je captais une implication éthique que les autres ne voyaient pas. Je le sentais en lisant une norme européenne et en y reconnaissant la traduction juridique d’un principe philosophique précis. Je le sentais en discutant d’architecture logicielle : les décisions vraiment importantes n’étaient pas techniques mais portaient sur le genre de monde que ce logiciel contribuerait à créer.

Aujourd’hui ce sentiment est une certitude. La formation humaniste n’est pas un complément de la pensée technique. Elle en est le fondement éthique indispensable. Sans elle, la technologie est aveugle. Puissante, rapide, efficace, et aveugle.

Nous vivons un moment où les systèmes que nous bâtissons peuvent altérer le développement neurologique d’une génération, peser sur des élections, décider qui obtient un crédit, déterminer ce que des millions de gens croiront vrai demain. Dans ce contexte, savoir configurer un cluster Kubernetes ne suffit pas. Il faut aussi savoir ce que Hans Jonas pensait de la responsabilité envers le futur. Avoir lu Mill sur la frontière entre liberté et dommage. Connaître le « décalage prométhéen » d’Anders et le reconnaître quand il est implémenté dans un algorithme de recommandation.

Ce n’est plus académique. Ce n’est pas un luxe. C’est existentiel. Pour nous comme espèce — les décisions techno de cette décennie définiront les conditions cognitives et sociales de nos enfants. Et pour les business — bâtir de la techno sans boussole éthique n’est pas qu’un risque moral : c’est un risque de marché. L’Europe l’a compris. AI Act, RGPD, CRA, PLD : signal que le temps de la techno sans pensée critique est fini. Qui ne sait pas le lire restera derrière. Pas par punition, par inadéquation.

Donc oui : après vingt ans dans le tech, je peux dire avec une confiance raisonnable que la licence de philosophie a été la décision professionnelle la plus importante de ma vie. Plus que toute certif, tout langage, tout projet. Parce qu’elle m’a donné la seule chose que la techno ne peut pas donner : la capacité de se demander si ce qu’on construit, on devrait le construire.

Ce qui suit tente d’expliquer pourquoi.

L’arme rhétorique la plus puissante de notre temps

Il y a un mot qui, dans le débat public contemporain, fonctionne comme un passe-partout argumentatif. Un mot qui ferme les discussions au lieu de les ouvrir, qui transforme celui qui l’invoque en défenseur de la civilisation et celui qui le questionne en obscurantiste. Ce mot est progrès.

« L’Europe freine le progrès. » « La bureaucratie tue l’innovation. » « Les régulations enchaînent l’avenir. » On entend ces phrases tous les jours — talk-shows, threads sur X, keynotes de conférences tech, posts de VC de la Bay Area. Présentées comme des évidences, elles cachent une prémisse jamais explicitée : que le progrès serait une force naturelle, unidirectionnelle, intrinsèquement bénéfique, et que tout obstacle sur sa route serait par définition un dommage à l’humanité.

Mais est-ce vraiment le cas ? Ou confondons-nous le progrès avec quelque chose de bien plus banal et bien moins noble ?

Qu’est-ce que le progrès, et qu’a-t-il été

Pour répondre, il faut comprendre d’où vient l’idée même de progrès. Ce n’est pas un concept éternel : c’est une invention historique, et pas si ancienne.

Les Lumières et la naissance d’une idée

L’idée que l’histoire humaine a une direction, que demain sera meilleur qu’aujourd’hui, est un produit des Lumières européennes du XVIIIᵉ. Avant Condorcet, Voltaire et Kant, le temps était cyclique (chez Grecs et Romains) ou pensé comme décadence depuis un âge d’or perdu. Les Lumières ont changé cette perception : la raison humaine, appliquée systématiquement, pouvait améliorer les conditions matérielles, morales et politiques de l’espèce.

Condorcet, dans son Esquisse d’un tableau historique des progrès de l’esprit humain (1795), imaginait une humanité progressant par stades vers la perfection grâce à l’éducation, à la science, à l’abolition des préjugés. Vision puissante, à beaucoup d’égards généreuse. Mais elle contenait déjà un germe problématique : l’idée que le progrès serait inévitable, presque une loi naturelle.

Kant, plus subtil, distinguait progrès technique et progrès moral. Dans son Idée d’une histoire universelle au point de vue cosmopolitique (1784) il suggérait que l’humanité pouvait avancer vers une société civile universelle, mais seulement par le conflit, la peine, et surtout par des institutions capables de canaliser « l’insociable sociabilité » humaine. Pour Kant, le progrès n’était pas automatique : il exigeait des structures, des lois, des contraintes réciproques. De la politique.

Le positivisme et l’équivoque fondatrice

C’est avec Auguste Comte et le positivisme du XIXᵉ que l’idée de progrès se soude définitivement à celle de progrès technico-scientifique. Comte théorisait une « loi des trois états » (théologique, métaphysique, positif) où la science remplacerait progressivement toute autre forme de connaissance, guidant l’humanité vers un ordre rationnel.

Là naît l’équivoque qu’on traîne encore : l’identification entre avancée technologique et amélioration de la condition humaine. Une équivoque que le XXᵉ aurait dû détruire pour toujours, et qui pourtant, avec une obstination presque inexplicable, continue de prospérer.

Le siècle qui aurait dû tout nous apprendre

Le XXᵉ a été le laboratoire définitif de l’équation « plus de techno = plus de progrès ». Les résultats ont été sans appel.

La même science qui a produit la pénicilline a produit le gaz innervant. La même ingénierie qui a bâti des ponts a bâti les chambres à gaz, avec efficacité industrielle, précision technique, progrès dans les méthodes. La fission nucléaire a donné une source d’énergie extraordinaire et la capacité d’auto-anéantissement.

Günther Anders, dans L’obsolescence de l’homme (1956), a saisi cette fracture avec une lucidité qui coupe le souffle. Il a forgé le « décalage prométhéen » : notre capacité technique de produire dépasse radicalement notre capacité d’imaginer les conséquences. On peut construire une bombe qui tue cent mille personnes ; on ne peut pas ressentir ce que cela veut dire. Nous sommes devenus, écrivait-il, plus petits que nos produits.

Hannah Arendt, à propos d’Eichmann, a montré quelque chose d’encore plus dérangeant : le mal le plus radical du XXᵉ n’a pas été commis par des monstres mais par des bureaucrates efficaces. La « banalité du mal », c’est, en un sens, le progrès organisationnel appliqué à la destruction. Eichmann ne haïssait pas les juifs : il optimisait des processus logistiques. À sa manière, c’était un innovateur.

La pensée qui tue : une expérience mentale

Allons plus loin. Sérieusement.

Imaginons que demain, par convergence de neuroscience, de nanotechnologies et d’interfaces cerveau-machine, il devienne possible de tuer un autre humain par la seule force de la pensée. Pas d’arme physique. Pas d’intermédiaire. Une intention mentale assez focalisée, et l’autre meurt.

Serait-ce du progrès technologique ?

Réponse de surface : oui. Avancée dans la compréhension du cerveau, dans les interfaces neurales, dans la miniaturisation. Tous les critères du progrès technique : nouveau, plus puissant, frontière de la connaissance.

Mais quelque chose en nous, profond et préargumentatif, se révolte. C’est exactement ce qu’il faut examiner — c’est là que se cache la vraie nature du progrès.

L’éthique de la responsabilité de Hans Jonas

Hans Jonas, dans Le principe responsabilité (1979), a anticipé ce dilemme. Son raisonnement s’applique avec une pertinence frappante.

L’éthique classique présupposait une nature invulnérable et des conséquences circonscrites. La technologie moderne a rendu ces prémisses fausses : on peut altérer le climat, modifier le génome, abolir toute barrière entre intention et meurtre.

D’où son impératif catégorique technologique : « Agis de telle sorte que les conséquences de ton action soient compatibles avec la permanence d’une vie humaine authentique sur la terre. » Pas conservateur — un impératif de responsabilité envers le futur. La question n’est pas « peut-on le faire ? » mais « quel monde crée-t-on en le faisant ? ».

Pour la pensée qui tue, la réponse est nette : on créerait un monde où la convivialité humaine, fondement de toute civilisation, deviendrait impossible. Plus aucun lieu sûr, parce que la menace résiderait dans l’esprit. Toute interaction empoisonnée par la terreur. Pas la fin de la techno : la fin de la société.

Le filtre de Mill : le dommage comme limite de la liberté

John Stuart Mill, dans De la liberté (1859), a formulé le « harm principle » : la liberté individuelle est sacrée, mais s’arrête là où commence le dommage à autrui.

Appliqué : la capacité de tuer par la pensée n’est pas une expansion de la liberté humaine, c’est sa négation. Si chacun peut tuer chacun, plus aucune liberté n’existe — la liberté présuppose la sécurité d’exister.

Mill nous enseigne ce qu’on devrait se tatouer : toute expansion du pouvoir individuel n’est pas un progrès. Certaines capacités, distribuées universellement, n’émancipent pas : elles détruisent. Le progrès authentique, c’est l’augmentation de la puissance dans les limites qui rendent la convivialité possible.

Popper : la société ouverte et ses ennemis (technologiques aussi)

Karl Popper, dans La société ouverte et ses ennemis (1945), se méfiait des grands récits du progrès inévitable. Pour lui, le progrès était une suite de conjectures et de réfutations : on essaie, on se trompe, on corrige. Et on ne peut corriger que si des institutions le permettent sans violence. La société ouverte est celle qui s’autocorrige : parlements, tribunaux, presse libre, lois modifiables.

Quand on dit que les régulations « enchaînent le progrès », on dit, consciemment ou non, que les mécanismes d’autocorrection sont un obstacle. Mais un obstacle à quoi ? Si le « progrès » ne survit pas au crible démocratique, peut-être n’est-ce pas du progrès. Peut-être n’est-ce que de la hâte déguisée en vision.

Qui crie au progrès enchaîné : une taxonomie

Quand quelqu’un déplore que les États ou les organisations supranationales « freinent le progrès », il vaut la peine de demander : qui parle, et quels intérêts représente-t-il ?

Le techno-optimiste de bonne foi

Il existe sincèrement des gens qui croient que la techno résout tout. Position compréhensible : la techno a résolu d’énormes problèmes — mortalité infantile, famines, épidémies. Mais le techno-optimisme devient dangereux en techno-déterminisme : l’idée que la techno laissée à elle-même produit toujours du positif. L’histoire dit le contraire.

L’entrepreneur qui confond son intérêt avec l’intérêt général

Quand un PDG de la Silicon Valley dénonce la régulation européenne sur l’IA comme « obstacle au progrès », défend-il l’avenir de l’humanité ou son modèle d’affaires ? La confusion entre intérêt privé et bien commun a, à l’ère tech, pris une forme particulièrement insidieuse : habillée d’avenir, d’innovation, de vision.

Le Techno-Optimist Manifesto de Marc Andreessen (2023) en est la version logique : le marché est le mécanisme du progrès, la régulation est un frein, qui la défend est un « décélérateur ». Cynisme aveugle : les marchés sans règles ne produisent pas du progrès mais de la concentration de pouvoir. Adam Smith le savait dans La Richesse des nations.

Le libertarien idéologique

Pour le libertarien radical, toute régulation est coercition, toute coercition est mal. Position cohérente sur ses prémisses fragiles : individus dans le vide social, sans asymétrie de pouvoir, sans externalités.

Robert Nozick, dans Anarchy, State, and Utopia (1974), en a la version la plus sophistiquée. Mais même Nozick admettait un « État minimal » pour protéger les droits fondamentaux. Quand la techno peut altérer le climat, manipuler le comportement de milliards de gens, abolir toute barrière entre intention et meurtre — l’État minimal suffit-il ?

Le populiste anti-élites

Enfin, qui utilise « le progrès freiné » en mode populiste : les élites de Bruxelles imposent ce que le « peuple » n’a pas demandé. Position qui exploite la frustration démocratique sans proposer d’alternative crédible. Si pas les institutions démocratiques, qui doit décider des limites de la techno ? Le marché ? Les programmeurs ? Les actionnaires ?

L’arme atomique qui a déjà explosé : les réseaux et le cerveau de nos enfants

Jusqu’ici, on a raisonné en abstrait. Inutile. L’arme qui détruit sans tirer existe déjà. Elle est dans les poches de nos enfants. Elle a une interface colorée, des notifications joyeuses, un modèle d’affaires qui monétise l’attention humaine en données vendables.

Parlons des réseaux sociaux. Et de ce qu’ils font, avec la brutalité que le sujet mérite, au cerveau, à la psyché et au tissu social d’une génération entière.

L’iceberg sous l’eau

Jonathan Haidt, dans The Anxious Generation (2024), a documenté ce que les données épidémiologiques montrent : après plus d’une décennie de stabilité, la santé mentale des ados s’est effondrée au début des années 2010. Dépression, anxiété, automutilation, suicide ont explosé, plus que doublé sur de nombreux indicateurs. La courbe coïncide avec la diffusion des smartphones. Pas avec la crise de 2008, ni le terrorisme, ni le climat. Les smartphones.

Et ce qu’on voit n’est que la pointe. Le CDC américain rapporte qu’en 2023, plus de 40 % des lycéens disaient ressentir une tristesse persistante. Chez les filles, 57 % avaient des symptômes dépressifs. Près d’une sur trois avait « sérieusement envisagé » le suicide, +60 % en dix ans. Au Royaume-Uni, l’enquête NHS Mental Health 2025 : 25,8 % des jeunes 16-24 ans souffrent d’un trouble mental commun, contre 18,9 % en 2014. Chez les jeunes femmes : 36,1 %.

Ce sont les chiffres émergés. L’iceberg sous l’eau, ce sont les ados qui souffrent en silence. 70-80 % des mineurs touchés par un trouble mental ne reçoivent jamais de traitement.

Le cerveau comme champ de bataille

Plus inquiétant : le neurologique. Une étude publiée dans JAMA Pediatrics (équipe Eva Telzer, UNC) a suivi 169 collégiens trois ans en IRMf : ceux qui consultent habituellement les réseaux montrent des trajectoires de développement cérébral significativement différentes. Régions touchées : amygdale (peur, réactivité émotionnelle) et cortex préfrontal dorsolatéral (jugement, raisonnement, valeur des récompenses).

Une étude récente (mars 2026, NeuroImage) sur 7 000+ adolescents (ABCD Study) : un usage quotidien plus élevé des réseaux est associé à une réduction de l’épaisseur corticale dans de nombreuses régions. Pas « se sentir un peu triste ». Altérations structurelles du cerveau en développement.

La Gen Z, née après 1995, a été la première à avoir des smartphones pendant la puberté. Leur cerveau s’est développé pendant que des algorithmes à maximisation de l’engagement se disputaient leur attention en permanence. Haidt identifie quatre dommages : privation sociale, privation de sommeil, fragmentation de l’attention, dépendance.

La consommation répétée de vidéos courtes active le circuit de la récompense, induit dérégulation dopaminergique, baisse de l’attention soutenue, hausse de l’impulsivité, altération du sommeil. Le cerveau de ces jeunes est reconfiguré d’une façon qui compromet le contrôle cognitif.

La machine à sous dans la poche

Soyons explicites : les réseaux ne sont pas devenus nocifs par hasard. Ils ont été conçus pour l’être.

Les mécanismes psychologiques qui les rendent compulsifs sont identiques à ceux des machines à sous : « renforcement à ratio variable », récompenses imprévisibles, intermittentes. B.F. Skinner l’a documenté dans les années 50 chez les pigeons : c’est le schéma le plus puissant pour maintenir un comportement.

Chaque scroll TikTok ou Instagram est une tirette de slot machine. Tu ne sais pas quel scroll t’apportera quelque chose d’intéressant. Cette incertitude génère plus d’activité dopaminergique qu’une récompense prévisible. L’attente, le ne-pas-savoir, est elle-même la drogue.

Sauf que les casinos sont régulés. Doivent déclarer les probabilités. Pas de mineurs. Pas d’opération sans licence. Les plateformes sociales n’ont aucune de ces contraintes. Natasha Schüll (Addiction by Design) : les réseaux utilisent les méthodes de l’industrie du jeu parce que dans l’économie de l’attention, le revenu est fonction du temps passé.

Le pull-to-refresh qui mime la leva de la slot. Les notifications rouges et l’effet Zeigarnik. Les streaks Snapchat qui transforment l’amitié en métrique gamifiée. L’algo TikTok qui apprend en heures ce qui te tient collé.

Chamath Palihapitiya, ex-VP croissance Facebook, l’a admis : les boucles de feedback dopaminergique court-termistes qu’on a créées détruisent le fonctionnement de la société. Sean Parker, premier président de Facebook : l’objectif était « consommer le maximum de votre temps et de votre attention consciente », exploitant « une vulnérabilité de la psychologie humaine ». Pas des accusations externes : des aveux.

Les recherches internes confirmaient : les documents Frances Haugen ont montré qu’Instagram savait empirer les problèmes d’image corporelle pour une fille sur trois. Ils savaient. Et ont choisi le profit.

La différence avec les armes traditionnelles

Une arme conventionnelle tue le corps. Le dommage est visible, immédiat, documenté. Le monde s’en aperçoit, dresse des mémoriaux, signe des traités.

Les réseaux opèrent sur un autre registre. Le dommage est invisible, graduel, cumulatif, normalisé. Personne ne voit un neurone se reconfigurer. Personne n’entend un cortex préfrontal s’amincir. Personne ne perçoit la privation de sommeil comme une urgence quand elle touche cent millions d’ados simultanément. Le dommage se cache dans la quotidienneté : « c’est juste le téléphone », « tous les jeunes sont comme ça », « nous, on regardait la télé ».

Mais la télé n’était pas conçue pour créer une dépendance par renforcement à ratio variable. Elle ne te suivait pas dans ta chambre à 3 h du matin. Elle n’avait pas un algo qui apprenait quelles insécurités exploiter. Elle ne te donnait pas une métrique numérique de ta valeur sociale en temps réel.

Et l’échelle. Une bombe détruit une ville. Les réseaux altèrent le développement cérébral d’une génération entière à l’échelle planétaire. Pas un groupe, pas une zone : quiconque, n’importe où, entre 3 et 20 ans avec un appareil. L’OMS a interrogé près de 280 000 jeunes ados dans 44 pays : 11 % présentaient un usage problématique des réseaux.

Une bombe explose une fois. Les réseaux opèrent 24/7, 365. Pas de cessez-le-feu. Pas de traité. Exposition chronique, ininterrompue, et de plus en plus précoce : tablettes à 3-4 ans, premier smartphone à 8-9, immersion sociale à 11-12. 64 % des enfants américains de 11-12 ans utilisent déjà les réseaux.

La destruction des familles

Les chiffres ne capturent pas un aspect : la famille.

Si tu as des enfants en âge scolaire, tu sais. Le smartphone est devenu le principal champ de bataille domestique. Pas une question de « règles » : structurelle. L’appareil est conçu pour être plus attirant que toute interaction familiale. Un parent qui lit une histoire à son enfant rivalise avec un algorithme qui a analysé des milliards d’interactions pour savoir exactement ce qui capte son attention.

Guerre asymétrique, et la famille la perd. Les parents se sentent impuissants, en retard sur une techno qui évolue plus vite que leur compréhension. Les enfants se sentent contrôlés, incompris, isolés des pairs s’ils n’ont pas accès. Résultat : érosion quotidienne de la confiance, du dialogue, du lien. Précisément ce qui fait une famille.

Anders et son décalage prométhéen : les parents d’aujourd’hui sont la première génération à devoir protéger leurs enfants d’une menace qu’ils ne peuvent ni voir ni comprendre pleinement. Pas comme l’alcool ou la circulation : ici, une architecture invisible de persuasion algorithmique opérant directement sur les circuits de récompense neurologiques. Comme demander à un parent de 1945 de protéger son enfant des radiations sans savoir ce qu’elles sont.

Le monde réagit, lentement

Le Surgeon General américain Vivek Murthy a comparé la dépendance aux réseaux à celle au tabac et a demandé un avertissement sanitaire. En 2023 il a alerté que plus de trois heures par jour double le risque de troubles mentaux chez les enfants.

L’Australie, en décembre 2025, est devenue le premier pays à interdire les réseaux aux moins de 16 ans, avec sanctions jusqu’à 49,5 M AUD. Plus de 4,7 millions de comptes désactivés à ce jour.

France, Norvège, Danemark, Malaisie, Espagne, Indonésie et l’Italie elle-même envisagent des mesures similaires. Mouvement global, et résistance là où l’on s’y attendait : les plateformes (Reddit a saisi la High Court australienne) et les groupes libertariens dénonçant la liberté d’expression des mineurs.

Même dynamique que tabac, amiante, plomb dans l’essence : l’industrie qui cause le dommage combat la régulation au nom de la liberté individuelle et du progrès, pendant que le dommage s’accumule silencieusement.

La question à se poser

Si le progrès est l’expansion de la capacité humaine collective de vivre librement, dignement et durablement, alors les réseaux dans leur forme actuelle sont-ils du progrès ?

Non. Pas parce que la connexion numérique est intrinsèquement mauvaise, mais parce que la manière dont elle a été implémentée — algos d’engagement exploitant les vulnérabilités neurologiques, modèles d’affaires basés sur la dépendance, absence totale de responsabilité — est l’antithèse du progrès. C’est l’utilisation des neurosciences les plus avancées pour réduire la capacité humaine au lieu de l’étendre.

Si on pouvait voir le dommage, si chaque amincissement de cortex préfrontal produisait un bruit, si chaque automutilation adolescente était une explosion visible, on aurait réagi avec l’urgence d’une bombe. Mais le dommage est silencieux. Et le silence est le meilleur allié de qui le cause et le monétise.

L’expérience mentale de la pensée qui tue, à bien y voir, n’est pas si hypothétique. Nous avons déjà donné à des entreprises le pouvoir d’altérer le développement cérébral de milliards de jeunes. Que ce soit pour vendre de la pub plutôt que par méchanceté ne rend pas le dommage moins réel. Juste plus difficile à nommer.

L’Europe et le choix humaniste

C’est ici qu’il faut parler de l’Europe. Pas celle des plaintes, des formulaires en triple, des règlements sur la taille des courgettes. L’Europe comme projet philosophique.

Le cadre régulatoire européen comme choix de civilisation

L’UE a produit un corpus normatif tech sans équivalent : RGPD, DSA, DMA, AI Act, CRA, PLD mise à jour pour le software et l’IA.

Vu de la Silicon Valley : « bureaucratie qui freine l’innovation ». Vu de la philosophie morale : la tentative la plus ambitieuse d’appliquer l’humanisme européen à la révolution technologique.

Prenons l’AI Act. Sa structure par risque, avec interdictions pour les usages les plus dangereux (scoring social, manipulation subliminale, surveillance biométrique de masse) et exigences croissantes pour les hauts risques, est une traduction législative du principe de Jonas. Pas « n’innovez pas » : « innovez, mais pas aux dépens de la dignité humaine ». Pas un frein : un gouvernail.

La PLD étendue au software : pour la première fois, qui produit du logiciel sera responsable des dommages, comme les automobiles, les médicaments, l’électroménager. Pour qui croyait le software immatériel et hors du monde physique, c’est un scandale. Pour qui croit que le pouvoir va avec la responsabilité, c’est une avancée.

DSA et DMA répondent directement à la catastrophe neurologique. Le DSA impose transparence des algos de reco, interdit la profilation des mineurs à des fins publicitaires, permet de désactiver la reco perso. Le DMA brise le pouvoir monopolistique des « gatekeepers ». Imparfaits ? Oui. Mais les seuls outils qu’une démocratie a pour répondre à un pouvoir qui, sans frein, reconfigure littéralement le cerveau de ses jeunes citoyens.

L’accessibilité comme paradigme du progrès authentique

L’EAA mérite une mention. Une innovation qui exclut une partie de l’humanité est-elle vraiment du progrès ?

Si le progrès est l’expansion des possibilités humaines (pas de quelques humains, mais de l’humanité), alors l’accessibilité n’est pas une contrainte. Elle est le progrès. Un produit numérique inutilisable par 15 % de la population mondiale n’est pas innovant : il est incomplet.

Martha Nussbaum (avec Amartya Sen), avec le capabilities approach, mesure le progrès non au PIB ni aux brevets ni à la vitesse des processeurs, mais à la capacité effective des individus de mener une vie digne d’être vécue. Si une techno augmente cette capacité pour tous, c’est du progrès. Si elle l’augmente pour certains aux dépens d’autres, c’est du pouvoir. Pas du progrès.

La confusion entre vitesse et direction

Il y a une erreur catégorielle qui imprègne tout : la confusion entre vitesse et direction.

« Move fast and break things », devise originale de Facebook, en est l’épitomé. Aller vite n’a de valeur que si la direction est juste. Sinon c’est juste courir vers un précipice plus efficacement.

Quand Sam Altman dit que « la régulation risque de ralentir l’IA », personne ne lui demande : ralentir vers où ? Si la direction est concentration du pouvoir, renforcement des biais, surveillance déguisée en personnalisation — alors ralentir n’est pas un dommage. C’est de la sagesse.

Épicure, le plus matérialiste des anciens, enseignait que la fin de la vie est l’ataraxie : tranquillité de l’âme. Pas l’accumulation de pouvoir, pas la conquête de la nature, pas la vitesse. La civilisation tech semble l’avoir oublié : tout ce qui est possible n’est pas désirable.

Simone de Beauvoir, dans Pour une morale de l’ambiguïté (1947), offre un autre outil : la liberté n’est jamais absolue, elle est toujours située. On n’est libre qu’avec d’autres libres. Ma liberté n’a de sens que si je préserve celle d’autrui. Transposé : ma liberté d’innover n’a de sens que si elle ne détruit pas la liberté, la sécurité, la dignité, l’autonomie de qui sera touché.

Le progrès comme construction collective

Définition alternative. Si le progrès n’est pas l’innovation technique, ni la vitesse, ni l’accumulation de capacités, qu’est-il ?

Voici : le progrès est l’expansion de la capacité humaine collective de vivre librement, dignement et durablement.

Chaque mot compte. Expansion, parce qu’on amplifie sans détruire. Capacité humaine, pas des machines ni des marchés mais des personnes réelles. Collective, parce que si ce n’est pas pour tout le monde, c’est du privilège. Libre, au sens millien. Digne, au sens kantien : chaque personne comme fin, jamais seulement comme moyen. Durable, qui ne sacrifie pas l’avenir au présent.

Avec cette définition, beaucoup change. La pénicilline est du progrès. Le suffrage universel est du progrès. L’eau potable pour tous, l’accessibilité numérique, le RGPD : du progrès.

La bombe atomique non. La surveillance de masse non. Un algorithme qui maximise l’engagement par la dépendance non. Une plateforme qui amincit le cortex préfrontal de millions d’ados pour vendre de la pub non. Et la pensée qui tue, notre hypothèse initiale, non. C’est la fin du progrès. La fin de tout.

L’humanisme comme boussole, pas comme chaîne

Quand quelqu’un dit que l’État, l’Europe ou l’ONU « enchaînent le progrès », que dit-il vraiment ?

Il dit, presque toujours, que sa manière d’innover, son modèle, sa vision est soumise à des contraintes qu’il n’apprécie pas. Il confond sa liberté d’action avec la liberté de l’humanité. Il prend l’absence de limites pour l’absence d’oppression.

Mais l’absence de limites n’est pas la liberté : c’est la loi du plus fort. C’est l’état de nature hobbesien, bellum omnium contra omnes, où la vie est « solitaire, pauvre, méchante, brutale et brève ». Les institutions, les lois, les contraintes réciproques ne sont pas des chaînes : ce sont les fondations de la convivialité.

L’humanisme, le vrai, de Pic de la Mirandole à Nussbaum en passant par Montaigne, Hume, Voltaire, Mill, Arendt, de Beauvoir, n’a jamais été contre la connaissance ou la technique. Il a été contre l’usage de la connaissance et de la technique contre l’humain. L’humanisme est la boussole qui nous permet de distinguer le progrès authentique de la simple accumulation de pouvoir.

Qui construit de la techno aujourd’hui a une responsabilité immense. Pas parce que la techno est mauvaise, mais parce qu’elle est puissante. Et le pouvoir sans responsabilité, sans limites, sans capacité d’autocorrection, n’est pas du progrès.

C’est juste un danger qui va vite.

Post-scriptum : une note personnelle

Je travaille dans la techno depuis vingt ans. Je fais du software. Je gère de l’infra. Je configure des pipelines CI/CD, j’écris des spécifications, je planifie des sprints. La techno est mon métier et, à beaucoup d’égards, ma passion.

Précisément parce que je la connais intimement, ses merveilles et ses misères, son pouvoir et sa fragilité, je rejette de toutes mes fibres l’idée que la réguler soit un acte hostile. Quand j’implémente le RGPD dans un projet, je ne « freine pas l’innovation » : je protège les personnes pour qui ce projet existe. Quand l’AI Act me demande de documenter les risques, je ne « perds pas du temps » : je fais mon métier avec le sérieux qu’il mérite. Quand l’EAA m’oblige à rendre une interface accessible, je n’« ajoute pas un coût » : j’inclus des humains que sinon j’exclurais.

Mais il y a une autre raison, plus personnelle et plus urgente, pour laquelle ce sujet me brûle. Je suis aussi père. Et comme père, je vis chaque jour la conscience que le monde numérique où grandira mon fils a été conçu par des gens qui font le même métier que moi, des gens qui savent exactement ce qu’ils font aux circuits de récompense d’un cerveau en développement. Je connais les design patterns, les métriques, le langage des stratégies de « rétention » et d’« engagement ». Je sais que derrière des mots neutres se cachent des mécanismes de dépendance délibérément ingénierés. Et je sais que ma compétence technique ne suffit pas à protéger un enfant d’une industrie qui a investi des milliards pour apprendre à capter son attention.

C’est pourquoi je crois que la régulation n’est pas seulement légitime : c’est un acte de civilisation. Qui construit de la techno a l’obligation morale de la construire pour les humains, pas contre eux. Et quand il ne le fait pas, il est juste et nécessaire que la société, par ses institutions imparfaites, lentes, exaspérantes, intervienne.

Le progrès authentique n’a jamais été rapide. Il a été pénible, conflictuel, plein de retours en arrière. Il a été, pour reprendre la métaphore poppérienne, une suite de conjectures et de réfutations, pas une marche triomphale. Et les institutions qui le gouvernent, imparfaites, lentes, parfois exaspérantes, sont le prix qu’on paie pour ne pas confier le destin de l’humanité à qui court le plus vite.

Ce n’est pas un prix élevé. C’est une affaire.

« Le degré de civilisation d’une société se mesure à la quantité de pouvoir à laquelle elle est disposée à renoncer. » — librement inspiré de Norbert Elias, Le procès de civilisation (1939).

Ce n’est pas un récit « motivationnel ». C’est plutôt une note de carnet, presque une anatomie. Parce qu’a posteriori je me rends compte que chaque phase m’a laissé une lentille différente. Et aujourd’hui, comme Head of Tech & partner dans une petite ICT, ces lentilles commencent vraiment à se superposer.

La chose étrange des carrières non linéaires

Les carrières linéaires n’ont peut-être jamais existé vraiment, mais on y a cru un temps. Moi en tout cas. Puis je suis passé d’Interface Developer dans l’un des plus grands groupes e-commerce de luxe européens (avant son entrée dans l’orbite Richemont) à CTO d’une startup deep-tech sur l’oil & gas, jusqu’à gérer aujourd’hui un portefeuille de projets très divers dans une boîte d’environ dix personnes.

Si je devais dire ce qui relie ces étapes, ce ne serait pas la techno. Elle change, et plus vite qu’on n’aime l’admettre. Le fil rouge est ailleurs : chaque rôle m’a fait voir comment on achète et vend des services IT. Et surtout, pourquoi les décisions qui paraissent techniques ne le sont souvent pas.

Phase 1 : dans un grand groupe, côté code

Quand tu es dans une grande organisation et pas dans le management, tu peux croire que certaines dynamiques ne te concernent pas. En réalité, elles te traversent quand même, vues « par reflet ». Moi j’étais dans le code, mais bosser dans un groupe de cette taille te fait voir des choses invisibles depuis l’extérieur.

Par exemple, comment on gère vraiment la relation avec les fournisseurs technologiques. Pas en théorie, pas dans le deck, mais au quotidien. J’ai vu que derrière un choix d’architecture il y a souvent un choix organisationnel, budgétaire, parfois même politique. Et j’ai vu une différence qui m’agaçait au début, puis j’ai compris qu’elle était simplement réelle : un vendor choisi pour ses compétences et un vendor choisi par inertie contractuelle ne sont pas la même chose, mais sur le papier ils paraissent identiques.

La première règle que je garde de cette phase est, peut-être un peu cynique, mais elle me semble vraie.

Le meilleur fournisseur n’est pas celui qui fait la meilleure proposition, c’est celui qui comprend comment fonctionne l’organisation du client.

Une règle difficile à mettre dans un framework. Qualitative, contextuelle. Et qui demande une compréhension des dynamiques internes qu’on n’acquiert souvent qu’en étant là, par osmose. Je me demande encore aujourd’hui combien d’appels d’offres et de sélections échouent, non parce que le prestataire est incapable, mais parce qu’il n’a pas lu le « système nerveux » du client.

Phase 2 : la startup, c’est-à-dire le coût réel des choix

Le saut vers la startup a été, sans exagérer, ce qui m’a le plus changé. Comme CTO d’une deep-tech verticale oil & gas, je me suis retrouvé à tout faire. Stack, recrutement, processus, budget, clients, livraison. Tout ensemble, souvent le même jour.

Et là tu apprends quelque chose qui reste plus diffus dans les grandes boîtes : le coût des décisions n’est pas un concept abstrait. Il est immédiat. Chaque choix a un impact direct sur le compte d’exploitation, sur le time-to-market, sur la soutenabilité de l’équipe.

Dans cette phase, j’ai appris à pricer les services IT non pas « selon le marché » mais selon la structure des coûts réels. Évidence apparente — jusqu’à ce que tu te cognes contre. J’ai appris aussi qu’un service pricé trop bas est plus dangereux qu’un trop cher : tôt ou tard quelqu’un paiera la différence. Et c’est souvent le client, en dette technique, retards, turnover, patches en panique.

Autre morceau important : les contrats. Pas ceux écrits pour gagner une négociation, mais ceux qui permettent de travailler. J’ai compris qu’il existe des contrats qui « protègent » et des contrats qui « marchent ». Les premiers sont pleins de pénalités que personne ne veut appliquer. Les seconds définissent des incitations alignées, une zone de coopération où les deux parties ont intérêt à bien faire.

La deuxième règle, ici, est devenue presque une conviction.

La qualité d’un service IT se joue avant le début du projet, dans les choix d’architecture et les processus que le prestataire met en place.

Quand le code commence à couler, beaucoup de manches sont déjà jouées. Pas toutes. Mais beaucoup.

Phase 3 : le portefeuille multi-client, où les frontières s’estompent

Aujourd’hui je travaille dans une petite ICT, environ dix personnes, comme partenaire technologique B2B. Les clients vont de grandes corporates aux administrations publiques. Mon rôle est un croisement permanent entre leadership technique, sprint planning, DevOps, compliance et architecture. Et c’est un travail « à portefeuille », donc avec des contextes très différents en cohabitation.

Dans la même période, on peut être impliqués sur un système d’information de santé régional, sur une plateforme SaaS de people analytics, sur une infrastructure IoT industrielle, sur des services de cybersécurité comme partenaire certifié d’un éditeur leader, sur des projets de compliance et sur du dev sur mesure pour le secteur public.

Cette phase est celle où les deux précédentes s’emboîtent. D’un côté, la mémoire du grand groupe : je comprends comment raisonnent les clients enterprise, ce qui les inquiète vraiment, leurs contraintes implicites. De l’autre, la sensibilité startup : je sais ce que veut dire faire de l’efficacité avec des ressources limitées, et combien comptent l’automatisation et la discipline opérationnelle.

Mais la leçon nouvelle, inattendue, est ailleurs.

Le marché des services IT est fragmenté de façon que beaucoup de frameworks d’advisory ne capturent pas.

Nous ne sommes pas un system integrator généraliste, mais pas non plus une boutique ultra-spécialisée. Nous sommes cette chose un peu inconfortable à étiqueter : un partenaire technologique agile, à compétences transverses. Et dans certains contextes, nous concourons avec des acteurs dix fois plus gros — non parce que nous sommes « meilleurs » dans l’absolu, mais parce que les processus sont plus légers et, de plus en plus, parce que l’AI-assisted development modifie le rapport entre capacité de production et taille d’équipe.

C’est peut-être là que j’ai mesuré combien la carte ne coïncide pas avec le territoire. Dans les quadrants et les rapports, certaines catégories sont nettes. Dans la vie, beaucoup moins.

Ce que ces phases m’ont appris sur le sourcing IT

Si j’essaie de traduire tout ça en implications concrètes pour le sourcing, trois idées émergent — qui sont aussi trois « défauts » récurrents dans la façon d’évaluer les prestataires.

La première vient du grand groupe : les décisions de sourcing sont souvent des décisions organisationnelles déguisées en décisions techniques. Donc qui fait de l’advisory devrait comprendre les dynamiques internes du client autant que les capabilities du prestataire. Sinon il risque de conseiller le « meilleur sur le papier » et d’obtenir le pire en pratique.

La deuxième vient de la startup : l’économie des services IT est bien plus granulaire que ce qu’en montrent les rapports de marché. La marge d’un prestataire sur un projet peut osciller énormément selon les choix d’architecture, l’automatisation, la maturité des processus. Sans lire ces dynamiques, on ne protège pas vraiment le client. Seulement formellement.

La troisième vient du portefeuille : le marché réel est plus diversifié que ce que suggèrent les frameworks. Les PME tech qui servent le tissu économique européen ne sont souvent pas dans les quadrants, et pourtant elles livrent une part importante des services IT. Ne pas connaître ce segment, c’est offrir au client un set d’options incomplet. Et parfois sans même s’en apercevoir.

La valeur cumulative, et pourquoi elle compte maintenant

Il y a un pattern dans les carrières qui produisent une valeur « non conventionnelle ». Ce n’est pas l’expérience seule qui fait la différence, c’est l’intersection.

Un analyste qui n’a fait que du conseil connaît les frameworks, mais peut n’avoir jamais vécu la livraison quand ça tourne mal. Un technicien qui n’a fait que du dev connaît le code, mais ne voit pas toujours le business. Un manager qui n’a fait que du corporate connaît les jeux politiques, mais risque de perdre le contact avec les coûts réels et avec la fatigue opérationnelle.

Le sens de ma trajectoire, s’il y en a un, est de traverser ces mondes. Et il me semble qu’aujourd’hui, cette capacité de connexion n’est plus un « plus ». Avec l’IA qui entre dans les processus, la compliance européenne qui se durcit, des modèles de pricing qui changent, le reshoring et de nouvelles attentes sur la sécurité et la souveraineté des données — la complexité ne diminue pas. Elle augmente.

Et quand la complexité augmente, les réponses simples deviennent suspectes.

L’étape suivante, avec un peu d’honnêteté

Ces derniers temps, j’ai le sentiment que l’évolution naturelle de ce parcours est d’apporter cette perspective intégrée à ceux qui doivent prendre des décisions de sourcing à fort impact.

Pas comme consultant opérationnel — ça je le fais déjà. Plutôt comme analyste de marché, chercheur, advisor stratégique. Dans un contexte où la profondeur de l’expérience opérationnelle et la capacité à produire des insights actionnables soient le cœur de la proposition.

Le type de rôle que certaines entreprises, avec beaucoup d’efforts et d’investissements, essaient d’incarner correctement.

Pas parce que j’aurais les bonnes réponses. Sur beaucoup de choses, sincèrement, je ne suis même pas sûr d’avoir une réponse unique. Mais je crois avoir les bonnes questions, celles qui viennent d’avoir vu le marché des services IT sous des angles différents. Et c’est peut-être ce qui manque le plus aujourd’hui.

Prochain dans la série : comment la tempête réglementaire européenne redessine les critères d’évaluation des prestataires IT, et pourquoi le marché de l’advisory n’est pas encore prêt.

Ce n’est pas une critique. C’est une observation structurelle. Et elle a des conséquences réelles sur la façon dont les décisions de sourcing sont prises, et sur le nombre de ces décisions qui se révèlent fausses.

Le métier vu de l’intérieur

J’ai passé plus de quinze ans de l’autre côté de la table. Pas comme celui qui évalue les services IT, mais comme celui qui les conçoit, les vend, les livre et en répond quand quelque chose ne marche pas.

Chez YNAP (Yoox pour les plus anciens), j’ai vu comment l’une des plus grandes plateformes e-commerce européennes gérait la relation avec ses fournisseurs technologiques. Pas en théorie : dans la pratique quotidienne des choix d’architecture, des négociations sur les livrables, des décisions qui déterminent si un projet livre de la valeur ou seulement du code.

Comme CTO d’Anthis, j’ai bâti depuis zéro l’infrastructure technique et les processus de livraison d’une entreprise. C’est l’expérience qui apprend que la différence entre un service IT qui marche et un qui non n’est presque jamais dans la techno choisie, mais dans la qualité du processus décisionnel qui mène à cette techno.

Et aujourd’hui, comme Head of Tech & Partner d’Oltrematica (oui, ce rôle n’existe pas formellement, on y reviendra), je gouverne un portefeuille de projets pour des clients allant de TIM à Randstad, de la Région Abruzzes aux Chambres de Commerce. J’écris des RFP et j’y réponds. Je définis des SLA et je dois les respecter. Je price des services managés en sachant exactement combien coûte chaque maillon de la chaîne de livraison.

Cette expérience m’a donné accès à un type de connaissance difficile — peut-être impossible — à acquérir de l’extérieur.

Les choses qu’on voit seulement de l’intérieur

Quand je lis les frameworks d’évaluation des prestataires IT (Magic Quadrant, PEAK Matrix, ISG Provider Lens), je reconnais la qualité de l’analyse et la rigueur méthodologique. Mais je vois aussi les angles morts. Et ce sont toujours les mêmes.

Le coût réel d’un service IT n’est pas dans le prix

Le prix coté dans une offre de services managés est un nombre. Le coût réel est un système complexe qui inclut le prix, plus le coût des inefficacités de communication, plus le coût de la dette technique qui s’accumule quand le prestataire coupe les coins pour rester dans le budget, plus le coût d’opportunité des fonctionnalités non livrées parce que le contrat ne les prévoit pas.

Un analyste qui évalue les prestataires en comparant les tarifs journaliers mesure la mauvaise variable. Un prestataire qui cote 400 € / jour et livre en 20 jours coûte moins qu’un autre qui cote 300 € / jour et y met 40. Mais pour savoir lequel des deux livrera en 20 et lequel en 40, il faut savoir lire l’architecture proposée, la composition de l’équipe, le niveau d’automatisation des processus de livraison.

C’est une compétence qui vient d’avoir bâti ces processus, pas de les avoir observés.

Les SLA sont un langage, pas seulement un contrat

D’expérience, la majorité des problèmes dans les contrats d’outsourcing IT ne naît pas de SLA mauvais. Elle naît de SLA ambigus.

Un SLA qui dit « disponibilité 99,9 % » est techniquement précis mais opérationnellement vide s’il ne précise pas : comment mesure-t-on la disponibilité ? Inclut-on la maintenance programmée ? Quelle fenêtre temporelle pour le calcul ? Que se passe-t-il quand le downtime est causé par un tiers (cloud, CDN, DNS) ?

J’ai écrit des SLA pendant des années. J’ai appris qu’un bon SLA n’est pas celui qui promet le plus, mais celui qui définit avec précision chirurgicale ce qui arrive quand les choses tournent mal. Parce que dans les services IT, les choses tournent toujours mal tôt ou tard. La qualité du prestataire se mesure dans la réponse, pas dans la promesse.

La composition de l’équipe est plus importante que sa taille

Les frameworks d’évaluation tendent à récompenser les prestataires aux grandes équipes et delivery centers multiples. Métrique rassurante pour qui achète : plus de monde = plus de capacité. Mais quiconque a géré des équipes de dev sait que non.

Une équipe de cinq seniors bien coordonnés produit plus d’output de qualité qu’une équipe de quinze avec trois couches de management et rotation continue. Surtout quand cette équipe de cinq utilise des méthodologies AI-native qui multiplient la productivité individuelle.

Chez Oltrematica, nous gérons simultanément 8 à 10 projets actifs avec une équipe d’environ 10 personnes. Pas parce que nous sommes des héros, mais parce que nous avons investi dans l’automatisation, dans des processus de livraison efficaces, dans des outils qui éliminent le travail à faible valeur. C’est l’efficacité qui n’apparaît dans aucun quadrant.

La valeur de la perspective opérationnelle dans l’advisory

Je ne suggère pas que tous les analystes doivent avoir travaillé comme prestataires IT. Je suggère que la perspective opérationnelle est un asset stratégique de l’advisory aujourd’hui dramatiquement sous-représenté.

Quand un CISO me demande si un prestataire de managed security est fiable, je ne dois pas me baser que sur les certifications et les références. Je peux lire l’architecture proposée et savoir si elle a été conçue pour être opérée ou seulement pour gagner l’appel d’offres. Je peux regarder le Statement of Work et repérer les zones grises qui deviendront des litiges contractuels dans 18 mois. Je peux juger si le modèle de staffing proposé est soutenable ou si le prestataire promet une équipe qu’il n’a pas et qu’il devra constituer after-the-fact.

Ce type d’insight ne vient pas de la rigueur analytique. Il vient d’avoir vécu les mêmes dynamiques de l’autre côté. Et il a une valeur énorme pour les clients enterprise sur le point de prendre des décisions de sourcing à plusieurs millions.

La convergence nécessaire

Le marché de l’IT services advisory entre dans une phase où la complexité des décisions de sourcing croît exponentiellement. IA, compliance européenne, reshoring, nouveaux modèles de pricing, cybersecurity by design : autant de dimensions qui exigent une compréhension technique profonde pour être bien évaluées.

Les frameworks génériques ne suffisent plus. Les clients demandent — et ont le droit d’obtenir — des advisors qui parlent la langue des prestataires avec la même aisance que la langue du business.

C’est une convergence que le marché n’a pas encore produite de façon systématique. Mais elle est inévitable. Et qui l’anticipera aura un avantage concurrentiel énorme.

Cet article est le premier d’une série sur ma vision du marché IT services sourcing. Dans le prochain billet, j’explorerai mon parcours personnel — du dev au partner — et comment chaque étape a contribué à construire une perspective intégrée sur le marché des services IT.

Astral est la startup derrière uv, Ruff et ty, trois outils qui en quelques années sont devenus l’infrastructure quotidienne de millions de développeurs Python. uv a résolu le problème de la gestion d’environnements et de dépendances avec une élégance et une vitesse que pip n’a jamais eues. Ruff a rendu le linting et le formatting si rapides qu’ils en deviennent invisibles, et ty fait la même chose pour le type checking. Des outils écrits en Rust, tous open source, tous sous licence permissive. Et depuis hier, tous propriété d’OpenAI, qui les intégrera à l’équipe Codex, son agent de coding qui a déjà dépassé les deux millions d’utilisateurs actifs hebdomadaires.

Il y a trois mois, en décembre, Anthropic avait fait un coup similaire en rachetant Bun, le runtime JavaScript créé par Jarred Sumner. Claude Code, leur outil de coding agentique qui a atteint un milliard de dollars de revenu annualisé en six mois, tourne comme exécutable Bun. Sumner l’a dit avec une clarté presque brutale dans son post d’annonce : « If Bun breaks, Claude Code breaks. » Anthropic a donc racheté l’infrastructure sur laquelle repose son produit à un milliard.

Deux acquisitions en trois mois, par les deux entreprises qui se disputent le marché des outils de coding assisté par IA. Prises isolément, chacune a sa logique. Prises ensemble, le pattern est inéquivoque.

Et le pattern est le suivant : les entreprises qui construisent des modèles de langage rachètent, pièce par pièce, la toolchain sur laquelle ces modèles opèrent. Pas le cloud, pas les puces, pas les datacenters. Les outils qui se trouvent entre le modèle et le code. Le package manager. Le linter. Le runtime. Le type checker. Tout ce dont un agent IA a besoin pour ne pas se contenter de générer du code, mais pour l’exécuter, le tester, le valider, et le remettre en production.

Ce n’est pas de la philanthropie envers l’open source. C’est de la stratégie infrastructurelle.

Quatre-vingt-quinze pour cent de contexte

Pour comprendre ce qui se passe, il faut partir d’un fait souvent sous-estimé : les modèles de langage, à eux seuls, génèrent du code. Mais générer du code, ce n’est pas faire du logiciel. Le sait quiconque a essayé de faire écrire un projet entier à un agent et s’est retrouvé avec quelque chose qui compile mais ne fonctionne pas, ou qui fonctionne mais ne respecte pas les conventions du repo, ou qui les respecte mais casse trois tests imprévus. La génération est cinq pour cent du travail. Les quatre-vingt-quinze restants sont du contexte : résoudre les dépendances, faire passer le linter, gérer les types, exécuter les tests, intégrer dans la CI/CD, maintenir le code dans le temps quand les libs s’updatent et les exigences changent.

Et c’est là le point. Un agent IA qui veut faire ces 95 % a besoin de posséder, ou au moins de contrôler, les outils qui les composent. Pas suffisant de savoir que uv existe. Il faut que uv réponde aux besoins de l’agent, qu’il soit optimisé pour ses workflows, qu’il évolue dans la direction qui rend l’agent plus efficace. Idem pour Ruff, ty, Bun. Quand OpenAI écrit dans son annonce que l’objectif est « move beyond AI that simply generates code and toward systems that can participate in the entire development workflow », ce n’est pas du marketing. C’est exactement pourquoi il a racheté Astral.

Je le vois tous les jours dans mon travail. J’utilise Claude Code sur des projets Laravel, je gère des pipelines CI/CD avec GitHub Actions, et la différence entre un agent qui génère un fichier et un agent qui comprend le contexte dans lequel ce fichier doit vivre, c’est la différence entre un outil utile et un jouet. Quand l’agent connaît les règles de mon linter, sait comment sont structurées mes dépendances, comprend mon flux de déploiement, alors il devient vraiment un collaborateur. Et pour être ce type de collaborateur, il doit parler la langue des outils que j’utilise. Si celui qui construit l’agent possède aussi ces outils, l’avantage concurrentiel est énorme.

Un lock-in d’un nouveau genre

Mais c’est précisément là que ça devient intéressant, et un peu inquiétant. Parce que ce qui émerge est un nouveau type de vendor lock-in, différent de tout ce qu’on a vu avant.

L’ancien lock-in était explicite : tu choisissais un cloud, tu choisissais une base de données propriétaire, et un jour migrer coûtait trop cher. Tu le savais, tu faisais tes comptes, tu décidais. Le nouveau lock-in est différent. Il est implicite. Tu ne te rends pas compte qu’il advient parce que chaque pièce paraît open source, libre, neutre. uv est encore sous MIT. Bun est encore sous MIT. Tu peux forker, tu peux les utiliser sans Codex ni Claude Code, tu peux faire ce que tu veux. Mais la question est ailleurs : dans deux ans, quand 80 % de l’évolution d’uv sera guidée par les besoins de Codex, quand les features prioritaires seront celles qui servent à l’agent d’OpenAI et pas à toi qui utilises uv en terminal, le fork sera-t-il vraiment une option praticable ? Simon Willison, l’un des esprits les plus lucides de l’écosystème, a écrit hier que le pire scénario a la forme de « fork and move on ». Mais il a ajouté, honnêtement, qu’OpenAI n’a pas encore de track record dans le maintien de projets open source acquis. Et qu’une acquisition produit + talent peut se transformer, avec le temps, en acquisition de seul talent.

C’est un point sur lequel je reviens. Le code reste ouvert, mais la direction devient fermée. C’est une forme de contrôle qui ne viole aucune licence, ne trahit aucune promesse explicite, et qui pourtant concentre du pouvoir de manière significative. Quelqu’un sur Hacker News a bien décrit la dynamique : « As they gobble up previously open software stacks, how viable is it that these stacks remain open ? » La viabilité technique reste, la viabilité pratique s’érode.

Je l’écris et j’entends déjà les objections, celles que je me suis faites moi-même. « Mais les incitations sont alignées », disent beaucoup. « Anthropic a besoin que Bun marche bien pour tous, pas seulement pour Claude Code, parce que l’adoption massive crée des effets de réseau. » Et c’est vrai, du moins aujourd’hui. « La licence MIT protège la communauté », disent d’autres. C’est vrai aussi, du moins en théorie. Mais j’ai vu assez d’acquisitions dans ma carrière pour savoir que les promesses du jour de l’annonce ont une date d’expiration non écrite. Le post de Jarred Sumner a été honnête : « No one can guarantee how motives, incentives, and decisions might change years down the line. » Et j’ajouterais que les incitations d’une startup à zéro revenu et quatre ans de runway devant elle sont très différentes de celles d’une division dans une boîte qui brûle deux dollars cinquante pour chaque dollar facturé et doit justifier chaque acquisition devant des investisseurs qui attendent une IPO.

La bataille pour le workflow

Il y a aussi un autre aspect qui me frappe, et qui concerne la façon dont ces acquisitions redéfinissent la concurrence. Jusqu’à hier, la bataille entre OpenAI et Anthropic se jouait sur la qualité des modèles. Qui raisonne mieux, qui génère du code plus propre, qui a le contexte le plus long. Aujourd’hui elle se déplace sur un autre plan : qui contrôle le plus de surface du workflow du développeur. Ce n’est plus seulement « mon modèle est meilleur ». C’est « mon modèle vit dans un écosystème que je possède et qui optimise chaque étape ». La génération de code devient une commodity, et la valeur se déplace vers l’orchestration de tout le cycle. Qui possède le linter, le package manager, le runtime et l’agent de coding a un avantage structurel qu’aucun benchmark ne capture.

La question que je me pose, et qui n’a pas encore de réponse claire, est ce que tout cela signifie pour qui travaille avec des stacks autres que Python et JavaScript. Beaucoup d’équipes — pensez à d’autres écosystèmes — n’ont pas (encore) subi cette concentration. Mais le pattern est clair, et il s’étendra. Aujourd’hui c’est Python et JavaScript parce que ce sont les langages de l’IA et du web. Demain ça pourra être tout écosystème dans lequel les agents de coding ont besoin d’outils fiables pour opérer en autonomie. La course à racheter les briques de l’infrastructure de développement vient de commencer.

Une analogie un peu forcée mais qui m’aide à penser. Pendant des décennies, le pétrole a été le carburant de l’économie industrielle, et qui contrôlait les raffineries et les pipelines avait plus de pouvoir que qui extrayait le brut. Dans le logiciel, les modèles de langage sont le brut. Ils génèrent de l’output. Mais la vraie valeur est dans la raffinerie : les outils qui prennent cet output et le transforment en logiciel fonctionnel, testé, conforme, déployé. Les AI companies l’ont compris et achètent les raffineries.

Un choix politique

Et nous sommes au centre de cette transition sans l’avoir choisie. On utilise uv parce que c’est le meilleur outil disponible. On utilise Bun parce qu’il est rapide et résout des problèmes réels. Nos choix sont rationnels et individuels. Mais l’effet agrégé de millions de choix rationnels et individuels, c’est la concentration du pouvoir infrastructurel dans les mains de quelques entreprises qui n’ont pas construit ces outils, elles les ont achetés.

Je ne sais pas où mène tout cela. Peut-être que les incitations resteront alignées assez longtemps pour ne pas poser problème. Peut-être que la licence MIT se révélera une protection suffisante. Peut-être que le marché restera assez concurrentiel pour empêcher les abus. Mais peut-être pas. Peut-être qu’on construit une dépendance qu’on reconnaîtra comme telle seulement quand il sera trop tard pour en sortir avec grâce.

Ce que je sais, c’est que le choix de ton package manager, de ton runtime, de ton linter n’a jamais été un choix uniquement technique. Aujourd’hui, que tu le veuilles ou non, c’est aussi un choix politique. Et comme tous les choix politiques, il mérite d’être fait les yeux ouverts.

Il y a un moment étrange, silencieux, où l’on s’aperçoit qu’une règle non écrite ne vaut plus. Pas parce que quelqu’un l’a contestée courageusement, mais parce que la réalité a cessé de coopérer.

Dans le conseil IT, ce moment, à mon avis, est maintenant.

Pendant des années, on a vécu dans un pacte confortable : tu me payes le temps, j’essaie. On l’appelait time & materials, staff augmentation, body rental. Différents noms, même idée. Tu achetais des heures humaines et tu espérais qu’elles deviennent quelque chose d’utile. Parfois ça arrivait, parfois non. Dans les deux cas, tu payais.

Et ce n’était pas que ça marchait parce que c’était juste. Ça marchait parce que ça semblait la seule façon possible. Le logiciel est complexe, estimer est dur, les exigences changent, la technologie aussi. Alors on s’est raconté que le temps était une bonne approximation de la valeur.

Puis l’IA est arrivée et, sans demander la permission, elle a rendu cette fiction beaucoup plus dure à tenir.

Le mensonge confortable du time & materials

Le time & materials, dépouillé de ses mots élégants, est surtout une chose : un mécanisme de transfert du risque.

Le risque de mal estimer, de découvrir des soucis techniques, de gérer un scope qui s’élargit, de réaliser tard que l’idée initiale ne tient pas. Dans le modèle à l’heure, ce risque finit presque toujours sur le client. Le prestataire « met les gens », le client paie l’exploration, même quand l’exploration mène à une impasse.

Décrit ainsi dans d’autres secteurs, ça paraît absurde. Imagine un plombier qui facture les heures sans promettre que l’eau coulera. Ou un chirurgien payé à la minute, indépendamment du résultat.

Et pourtant, en IT, c’était normal. Mieux : attendu. Si un client demandait des garanties, il était souvent étiqueté « compliqué ». Si un prestataire proposait un prix fixe, il paraissait naïf ou dangereux.

La justification était toujours la même : « le logiciel, c’est différent ». C’est vrai en partie. Mais conclure que le seul modèle honnête est de facturer le temps a toujours été un saut logique.

La vérité un peu triste, c’est que ça arrangeait tout le monde, à court terme. Beaucoup de clients n’avaient pas la compétence interne pour distinguer qualité et inefficacité. Et beaucoup de prestataires, soyons honnêtes, ont appris à bien vivre dans ce monde. Parce que le temps est mesurable, la valeur non. Et quand tu ne sais pas mesurer la valeur, tu finis par acheter ce que tu sais compter.

Le problème, c’est que les incitations deviennent étranges. Parfois inversées. Si tu es plus lent, tu factures plus. Si tu résous en deux heures au lieu de vingt, tu « laisses sur la table » dix-huit heures. Personne ne le dit aussi ouvertement, mais le système poussait dans cette direction.

L’IA entre en scène et raccourcit les heures

Puis, en très peu de temps, certaines activités quotidiennes ont commencé à s’effondrer.

Boilerplate, intégrations répétitives, scaffolding de migrations, tests générés, doc initiale, transformations de données. Pas tout, pas toujours, pas parfaitement. Mais assez pour changer l’arithmétique.

Et arrive le point qui met le modèle en crise : si hier une intégration « valait » 80 heures et aujourd’hui demande 15 avec assistance IA, qu’est-ce que tu factures ?

Si tu factures 15 heures, ton chiffre baisse drastiquement à résultat égal.

Si tu factures 80 heures quand même, tu fais quelque chose qui ressemble beaucoup à une fraude, même appelée « buffer », « contingence », « gestion du risque ». Tout le monde ne le vit pas comme ça, mais le sentiment est dur à ignorer.

D’où trois réactions, toutes fragiles :

Certains cachent l’usage de l’IA.

D’autres l’interdisent, moins pour la qualité que pour protéger le modèle.

D’autres l’utilisent et gardent les prix à l’heure, retenant le gain de productivité.

Le point, c’est que cette fenêtre se referme. L’arbitrage entre « combien il fallait à un humain » et « combien il faut à une personne avec IA » s’élargit trop. Tôt ou tard, côté client, quelqu’un fera ses comptes. Ou comparera des prestataires. Ou se demandera pourquoi la même chose, aujourd’hui, coûte autant qu’il y a deux ans.

Si le code coûte moins, que reste-t-il à vendre ?

Voilà la question qui, à mon avis, sépare ceux qui survivent de ceux qui se figent.

Parce que si l’IA t’aide à écrire code, tests et doc plus vite, on pense naturellement : « ok, mon travail vaut moins ».

Je n’en suis pas du tout convaincu. Peut-être qu’une partie du travail vaut moins, la plus mécanique. Mais cette réduction fait émerger le reste, ce qui a toujours été de la valeur et qu’on emballait dans les heures.

Ce que les clients cherchent vraiment, ce n’est pas le code. C’est un résultat.

Un produit qui marche.

Un risque réduit.

Une capacité nouvelle.

Une décision bien prise.

Et il y a des zones où l’IA, du moins pour l’instant, ne remplace pas vraiment le conseil. Elle l’amplifie.

Comprendre le problème, pas seulement les exigences

Les exigences techniques sont souvent des symptômes. Le vrai problème est plus dessous : processus, contraintes, gens, politique interne, incitations. Parfois aussi des peurs non dites.

Comprendre cela demande de l’écoute, du contexte, et un brin de courage à dire des choses inconfortables.

Prendre des décisions difficiles et irréversibles

Architecture, build vs buy, modèle de données, posture sécurité. Des décisions qu’on paye pendant des années.

L’IA peut proposer des options, mais bien choisir, en assumant, c’est autre chose.

Prendre la responsabilité

C’est le plus central, à mon avis.

L’IA ne peut pas être appelée à 3 h du matin quand quelque chose tombe. Elle ne peut pas mettre son visage devant le board. Elle ne peut pas porter la responsabilité juridique ou réputationnelle.

Un prestataire, oui. Et cette responsabilité devient aujourd’hui une composante explicite de la valeur.

Naviguer la compliance et les contraintes réelles

Pas seulement « ce qu’on peut construire », mais « ce qu’on peut construire sans s’attirer d’ennuis ».

RGPD, NIS 2, Accessibility Act, Cyber Resilience Act, AI Act. En Europe, il devient de plus en plus clair que le logiciel n’est pas qu’un projet, c’est un produit avec des obligations.

Le pricing à la valeur : tout le monde en parle, peu le pratiquent

Le pricing à la valeur n’est pas une nouveauté. Pourtant, dans le conseil IT, il est resté souvent un idéal lointain.

Pourquoi ? Parce qu’il exige une chose que le T&M te permet d’éviter : prendre le risque.

Vendre à la valeur, c’est vendre des résultats. Et si tu vends des résultats, tu dois être prêt à dire « si on n’y arrive pas, on en répond ».

Ce n’est pas qu’un changement de tarif. C’est un changement d’identité.

Cela veut dire arrêter de vendre des « jours-homme » et commencer à vendre, par exemple, « une intégration fonctionnelle entre CRM et ERP, avec monitoring, logging, tests et critères d’acceptation clairs ».

Cela veut dire bâtir des méthodes pour estimer et gouverner l’incertitude, plutôt que la transférer.

Cela veut dire investir dans des processus, de la qualité, des spécifications, et oui, dans l’IA aussi, mais de façon transparente.

Et un doute me reste : peut-être beaucoup d’entreprises n’ont-elles pas peur de l’IA. Elles ont peur de ne plus pouvoir cacher l’inefficacité derrière un timesheet.

Le vrai obstacle : la peur de la responsabilité

J’ai parlé à beaucoup de monde du secteur cette dernière année. Presque tout le monde dit que le modèle à la valeur est « le futur ». Peu l’appliquent vraiment.

Et je ne crois pas que ce soit seulement par complexité commerciale. Je crois que c’est par peur.

Le T&M est confortable parce qu’il te protège. Si ça tourne mal, tu peux toujours dire « vous avez demandé ça », « on a suivi les exigences », « on a mis les heures ». La responsabilité du résultat se dissout.

Quand tu vends un outcome, cette protection disparaît. Si ça ne marche pas, c’est ton problème. Si ce n’est pas conforme, tu corriges. Si l’impact business n’arrive pas, tu dois l’expliquer.

C’est inconfortable. Mais c’est aussi, enfin, honnête.

Une note pour ceux qui achètent du conseil

Ce n’est pas que la faute des prestataires. Les acheteurs aussi ont contribué au système.

Si tu choisis tes partenaires en regardant surtout le tarif journalier, tu dis au marché que ce qui t’intéresse est le coût unitaire, pas le résultat. Et tu ne devrais pas être surpris de recevoir de la conformité, pas du courage. De la présence, pas de la responsabilité.

Dans le monde post-IA, à mon avis, bien acheter, c’est faire un saut :

Demander des outcomes mesurables, même s’ils ne sont pas parfaits.

Payer plus celui qui prend du risque et y met de la transparence.

Cesser d’exiger des spécifications kilométriques comme forme de contrôle, et commencer à décrire problème, contraintes, critères de succès.

Bâtir un minimum de compétence interne pour évaluer la qualité, sinon tu reviendras toujours à acheter des heures, la seule chose que tu sais compter.

On entre dans une économie de la confiance

Un effet collatéral de l’IA me paraît énorme : produire est devenu moins cher, vérifier est devenu plus cher.

Aujourd’hui, n’importe qui peut générer du code, de la doc, des diagrammes, des rapports « crédibles ». Le problème n’est pas d’obtenir un output. C’est de savoir si cet output est fiable, sûr, maintenable, conforme.

La question change donc.

Ce n’est plus « tu sais faire ? ». C’est « puis-je faire confiance à ce que tu me livres ? »

Et la confiance, ça ne s’automatise pas. Ça se construit avec un track record, de la transparence, de la responsabilité, la capacité d’admettre une erreur et de la corriger.

En ce sens, le pricing à la valeur est aussi un signal : quand un prestataire accepte d’être payé pour un résultat, il dit qu’il croit assez en son travail pour y mettre sa peau.

Une confession, parce que je suis dedans aussi

Ici, on a facturé à l’heure pendant des années. C’était normal. C’était simple. C’était, d’une certaine manière, rassurant.

Puis l’IA a vraiment commencé à accélérer le travail. Et on s’est trouvé devant un choix que beaucoup vivent maintenant : faire semblant de rien, ou changer.

Changer fatigue. Ça t’oblige à repenser offres, contrats, processus, et la culture interne. Ça t’oblige à te demander dans quoi tu es bon et dans quoi tu ne l’es pas. Ça t’oblige à dire des non.

Je ne sais pas si on fera tout parfaitement. Probablement pas.

Mais une chose me semble claire : le time & materials n’est pas « mort » parce que l’IA écrit du code. Il est mort parce que l’IA a rendu impossible de continuer à faire semblant que le temps est une mesure honnête de la valeur.

Et peut-être, à dire vrai, c’est une bonne nouvelle. Pas parce que ce sera facile, mais parce que ça oblige tout le monde à revenir à ce qu’on aurait dû vendre depuis toujours : résultats, responsabilité et confiance.

« Le juridique s’en occupe. »

Je ne le dis pas pour le cynisme. C’est juste que cette phrase, en 2026, risque d’être l’une des plus coûteuses qu’une entreprise logicielle européenne puisse prononcer.

Parce que ce qui arrive ne ressemble pas à une mise à jour de policy ou à un round d’informations. Ça ressemble plus à un changement de fondations. Et, plus inconfortable encore, avec des échéances très rapprochées.

La tempête parfaite : cinq échéances dans une fenêtre trop courte

Si tu fais du logiciel pour le marché européen, le calendrier n’est plus un détail dans un fichier partagé. C’est une timeline qui entre dans ton architecture.

Entre fin 2024 et 2026, des normes s’empilent. Prises seules, tu pourrais peut-être les gérer péniblement. Ensemble, en revanche, elles s’emboîtent exprès.

NIS2 est en vigueur depuis octobre 2024 et a élargi le périmètre de qui doit prendre la cybersécurité au sérieux, supply chain incluse. Première surprise fréquente : pas besoin d’être « critique » pour en sentir les effets. Il suffit d’être fournisseur de quelqu’un qui l’est.

L’European Accessibility Act est opérationnel depuis juin 2025 et déplace l’accessibilité du monde des « améliorations » à celui des « exigences ».

Puis vient 2026, l’année où le nœud se serre.

En août 2026, l’AI Act entre en pleine application pour les systèmes à haut risque. Ce n’est pas qu’éthique ou transparence. On parle d’évaluations de conformité, de documentation technique, de gouvernance des données, de supervision humaine. Et oui, de sanctions réelles, jusqu’à 3 % du CA mondial ou 15 millions.

En septembre 2026, le Cyber Resilience Act amène des obligations qu’on ne peut pas « ajouter après ». Notamment la signalisation d’une vulnérabilité activement exploitée sous 24h et d’incidents graves sous 72h. Et ce que beaucoup sous-estiment : ça ne vaut pas que pour les produits futurs. Ça vaut aussi pour ce qui est déjà sur le marché. Legacy compris.

En décembre 2026, la Product Liability Directive redéfinit ce qu’est un « produit » à l’ère numérique. Le logiciel, même standalone ou en SaaS, devient produit à part entière, avec responsabilité objective. Les bugs cessent d’être un simple ennui opérationnel et deviennent un défaut potentiel, avec conséquences juridiques directes. La responsabilité ne s’arrête pas à la livraison, elle s’arrête quand tu n’as plus la capacité de fournir des mises à jour.

Et en arrière-plan, le RGPD, qui n’est jamais parti, avec un enforcement de moins en moins timide.

Ce qui déstabilise le plus, c’est peut-être que ces normes ne s’additionnent pas linéairement. Elles se renforcent.

L’erreur fondamentale : traiter la compliance comme une couche externe

La réaction la plus courante est compréhensible : « on appelle le consultant, on met à jour les policies, on rédige la doc, on coche les listes ». L’approche compliance-as-paperwork.

Avec le RGPD, même mal fait, ça tenait parfois. On pouvait coller au-dessus d’un système existant des process, informations, registres, rôles.

Avec le pacte 2026, ça ne tient plus. Pas par manque de bonne volonté. Parce que certaines exigences, sans le support de ton archi et de ton processus de release, tout simplement n’existent pas.

Cas concret : pour respecter le CRA, quand émerge une vulnérabilité activement exploitée, tu dois pouvoir réagir et signaler dans les délais. Pour ça, il faut savoir précisément ce qu’il y a dans ton produit. Pas « à peu près ». Exactement.

Dépendances directes, transitives, composants, versions, builds. Tout.

Cela t’amène droit à un objet ni juridique ni bureaucratique : le SBOM, software bill of materials. Et pas un SBOM en PDF généré une fois pour faire plaisir. Un SBOM vivant, régénéré à chaque build, en format machine-readable, intégré à la pipeline.

Si ton processus de build ne produit pas un SBOM comme sortie naturelle, ce n’est pas que tu es « un peu en retard ». C’est que tu ne peux pas l’être, point.

Et là se cristallise la phrase la plus importante de tout ça : la compliance n’est pas une exigence que tu ajoutes. C’est une propriété émergente de ton architecture.

La compliance comme contrainte d’architecture

En architecture logicielle, on est habitués aux contraintes. Latence, disponibilité, scalabilité, compatibilité, coûts. Elles restreignent l’espace des solutions.

La compliance EU 2026 est une contrainte d’architecture. Pas un ticket à assigner « en fin de projet », pas un document à produire « avant l’appel d’offres ». Une contrainte qui traverse le système.

Quand tu la regardes ainsi, des conséquences deviennent presque évidentes.

L’observabilité n’est plus un extra

L’AI Act, pour certains systèmes, exige logs et traçabilité. Le CRA pousse vers la détection et la réponse. La PLD te place en position de devoir démontrer l’état du logiciel au moment de l’incident.

Sans audit trails suffisants, ce n’est pas que tu « monitores peu ». C’est que ton système ne peut pas soutenir les questions que le marché et les normes te poseront.

La gestion des dépendances devient un processus critique

Pendant des années, on a normalisé l’idée que mettre à jour des libs est un travail « quand on a le temps ». Un npm install à la va-vite, un lockfile que personne ne regarde, une mise à jour reportée parce que « ça marche ».

Avec CRA et NIS2, cette légèreté devient un risque de supply chain. Et le risque supply chain, en 2026, ne reste pas confiné à la tech. Il se propage aux contrats, aux appels d’offres, aux partenariats.

La question à laquelle tu dois savoir répondre est simple et dure : « ce CVE qui vient de sortir impacte-t-il nos produits en prod ? ». La réponse doit arriver en minutes ou heures, pas en semaines.

Le concept de « produit fini » s’effrite

PLD et CRA, ensemble, rendent moins crédible l’idée qu’une release ferme un chapitre. Releaser devient le début d’une relation de longue durée avec un système à entretenir, surveiller, soigner.

Cela change aussi la façon d’estimer, planifier, vendre. Parce qu’une partie de la valeur — et de la responsabilité — vit après la livraison.

L’accessibilité est une propriété du design system

L’EAA n’est pas tendre avec les retrofits. Si tu as un design system accessible by default, tu as un avantage structurel. S’il faut « rendre accessible » un frontend grandi pendant des années sans règles, le volume de findings revient ingérable.

Je me demande souvent si on ne sous-estime pas combien l’accessibilité est, en réalité, une forme de standardisation interne. Pas qu’une exigence externe.

La human oversight n’est pas un bouton

Une des incompréhensions les plus courantes de l’AI Act est de penser que « supervision humaine » signifie ajouter une étape d’approbation à la fin.

En pratique, c’est une question de flux : où l’humain peut intervenir, avec quelles informations, avec quelle possibilité d’override, avec quelle traçabilité. C’est de l’architecture du processus de décision, avant même de l’architecture logicielle.

L’intersection que beaucoup ne regardent pas

Le point le plus intéressant, et peut-être le plus dangereux, ce n’est pas chaque obligation. C’est leur emboîtement.

La PLD dit qu’un produit logiciel est défectueux s’il ne satisfait pas aux exigences de cybersécurité applicables. Le CRA définit une part importante de ces exigences. L’AI Act ajoute des exigences spécifiques quand il y a de l’IA.

Donc la non-conformité au CRA peut devenir un défaut de produit au sens de la PLD.

On ne parle plus seulement d’amende administrative ou de non-conformité « à corriger ». On parle de responsabilité civile pour dommages, avec des dynamiques comme l’inversion de la charge de la preuve.

Pour te défendre, tu dois pouvoir démontrer que le produit était conforme au moment de l’incident. Ce qui te ramène, encore, à SBOM, audit trails, logging, doc technique. Pas comme théâtre de la compliance, mais comme architecture défensive.

Le paradoxe italien : fragiles, mais rapides

Ici, un morceau que je sens proche, parce que c’est la réalité quotidienne de beaucoup de boîtes avec qui je discute.

Le tissu logiciel italien est en grande partie fait de PME : équipes de 5 à 20, produits verticaux, croissance par stratification, roadmap dictée par les clients, dette technique accumulée selon la logique feature-first.

Beaucoup sont impréparées. Pas par incapacité, par structure.

Et pourtant un paradoxe : la même structure qui les rend vulnérables peut devenir un avantage.

Une boîte de dix personnes, si elle décide vraiment, peut redessiner des pans importants de son archi en 12 mois. Une grande organisation met souvent des mois rien que pour comprendre ce qu’elle a en prod.

Une petite équipe connaît son domaine et son produit intimement. Elle peut faire une gap analysis réaliste en quelques semaines.

Et un founder-CTO qui investit aujourd’hui en compliance-by-design peut bouger dans une fenêtre qui, dans 18 mois, sera déjà fermée. Pas parce que ce sera impossible, mais parce qu’il sera trop tard pour le faire avec calme.

Compliance-by-design : décisions d’archi, pas slogans

Quand je dis compliance-by-design, je n’entends pas « bien faire les choses » en général. J’entends des choix concrets que tu peux commencer maintenant, sans tout révolutionner.

Le SBOM comme artefact de première classe, par exemple. Chaque build produit un SBOM en CycloneDX ou SPDX. La pipeline le génère, le conserve, le confronte aux bases de vulnérabilités, et au besoin bloque un déploiement. Des outils comme syft, grype ou trivy rendent cela bien plus accessible qu’il ne semble.

Puis l’audit trail, mais pas celui des logs système. Un audit trail de domaine : qui a fait quoi, quand, pourquoi, avec quel rôle, dans quel contexte. Event sourcing ou append-only log, l’idée est qu’il soit citoyen de première classe du modèle de données.

La doc technique comme code, autre point clé. Si la doc vit dans un wiki mis à jour à la main, tôt ou tard elle cesse de représenter la réalité. Avec des ADR versionnés, des spécifications déclaratives, et de la doc générée depuis le code, elle devient un sous-produit inévitable du travail.

Et le vulnerability management ne peut pas être un événement annuel. Ça doit être un processus continu : scan automatique, triage, remédiation à délais définis. Quand la signalisation d’une vulnérabilité exploitée arrive, le système doit t’aider à réagir en heures.

Sur l’accessibilité, ce qui marche est de la traiter comme design tokens et règles du design system. Si les composants naissent accessibles, le produit le reste. S’il faut corriger après, chaque nouvel écran ajoute de la dette.

Le développement AI-native comme accélérateur, pas que comme risque

Petite ironie : l’AI Act arrive pendant que l’IA change la façon dont on écrit du logiciel.

Beaucoup voient le développement AI-native comme un risque pour la compliance : plus de code généré, moins de contrôle. Je soupçonne que, dans bien des cas, c’est l’inverse.

Une approche spec-driven, où le logiciel naît de spécifications déclaratives lisibles et vérifiables, est intrinsèquement plus favorable à la conformité. Parce que les spécifications sont de la doc. Parce qu’elles sont versionnées. Parce qu’elles rendent explicites des hypothèses qui restent sinon dans la tête de qui a écrit ce bout de code il y a deux ans.

Des outils comme un fichier projet claude.md, speckit, des pipelines qui génèrent des artefacts de compliance dans le flux, ne sont pas de la science-fiction. C’est une autre manière de travailler, qui peut faciliter la production d’évidences, de traçabilité, de reconstructibilité.

Le futur n’est peut-être pas « écrire plus de doc ». C’est construire le logiciel pour que la doc soit inévitable.

Le vrai coût de la non-conformité est bien plus proche qu’une amende

Les sanctions impressionnent, mais pour beaucoup de PME elles restent abstraites. Ce n’est pas la peur de l’amende qui change les priorités.

Le coût réel est plus quotidien.

C’est l’appel d’offres public auquel tu ne peux pas répondre faute de répondre aux exigences de sécurité du cahier.

C’est le client enterprise qui te demande le SBOM et tu ne sais pas par où commencer.

C’est le partenaire qui fait du supply chain risk management et t’écarte de la shortlist.

C’est l’incident que tu ne peux pas gérer dans les délais du CRA et qui s’imbrique dans un cadre de responsabilité plus dur.

Pour beaucoup d’entreprises italiennes, ce ne sont pas des scénarios théoriques. Ça ressemble beaucoup à 2027.

La fenêtre, c’est maintenant — et c’est de la bonne ingénierie

Architecte logiciel, la tête souvent partagée entre roadmap, budget, dette technique et demandes du marché, je comprends que tout cela puisse paraître écrasant.

Mais un aspect mérite d’être en avant : beaucoup des pratiques exigées par ces normes sont simplement de la bonne ingénierie.

Générer un SBOM, c’est de la bonne ingénierie. Avoir un audit trail, idem. Gérer les vulnérabilités des dépendances, idem. Documenter les décisions d’architecture, idem. Construire des interfaces accessibles, idem.

Ce que la compliance EU 2026 fait, peut-être, c’est rendre obligatoire ce qu’on aurait dû faire de toute façon. Elle transforme les best practices en baseline.

Et elle crée un marché où qui traite la compliance comme un problème d’architecture, et pas comme un truc à déléguer au juridique, se retrouve avec un logiciel plus robuste, plus maintenable, et plus vendable.

La fenêtre pour bâtir cet avantage est ouverte maintenant. Dans dix-huit mois, qui n’a pas commencé courra. Qui commence maintenant, vraisemblablement, sera de l’autre côté.

Ce sont les choses qu’il faut désapprendre.

Et le bizarre, c’est qu’en les désapprenant, on a l’impression de perdre quelque chose. Du statut, du contrôle, de l’identité. Puis, si ça va bien, on se rend compte qu’on lâchait juste une habitude qui nous tenait immobile.

Voici quelques notes éparses sur des choses que j’ai cessé de faire. Il m’a fallu quinze ans, plus ou moins. Et sur certaines, pour être honnête, je n’ai pas fini.

J’ai cessé d’écrire du code pour prouver que je suis encore tech

Il y a eu une période, juste après une étape importante de ma carrière, où ma façon de me légitimer devant l’équipe était toujours la même : j’ouvrais l’IDE et j’allais prendre le bug le plus laid de la semaine.

Je le faisais souvent le soir, seul. Le lendemain matin le commit était là, avec mon nom dessus. Au-dedans, j’appelais ça leadership. C’était de l’insécurité.

Parce que le message implicite était dévastateur, même sans le dire à voix haute. Le message était : je ne vous fais pas confiance. Et il y en avait un autre, encore plus toxique : les problèmes se résolvent la nuit, en solo, sans demander d’aide.

Sans le vouloir, j’enseignais que le geste héroïque vaut plus que le processus. Que la compétence est une performance individuelle. Que la fatigue est une médaille.

Puis j’ai fait un autre tour de manège. J’ai remplacé le code par les spécifications. Des documents si précis que l’équipe — ou un agent IA — pouvait les implémenter avec une supervision minimale. Pendant un temps, ça m’a paru la solution « adulte ». Mais cette phase aussi est passée.

Aujourd’hui, mon travail, quand je le fais bien, est ailleurs. C’est décider quoi on construit, pour qui, pourquoi maintenant. C’est de l’architecture de portefeuille, pas de code. C’est partenariats, hiring, positionnement. C’est comprendre où l’entreprise doit viser dans dix-huit mois, et quels choix d’aujourd’hui rendent cette direction plus probable.

Cette distance avec le code, parfois, fait mal. Pas parce que je veux retourner programmer chaque jour. C’est plus subtil. C’est la sensation que la légitimité d’un tech qui ne touche plus le code au quotidien est fragile, à reconstruire sur d’autres bases.

Plus sur la qualité de ce que tu écris, mais sur la qualité des décisions que tu prends et des personnes que tu choisis.

Et puis il y a une phrase qui me revient souvent et qui m’aide à ne pas retomber dans le vieux réflexe : chaque ligne que j’écris est une ligne que quelqu’un d’autre n’écrira pas. Chaque heure passée dans l’IDE est une heure où personne ne regarde où on va.

J’ai cessé de courir après le bon stack

Pendant des années, j’ai eu ce réflexe pavlovien de développeur. Un nouveau framework sort, il faut l’évaluer. Un nouveau langage sort, il faut au moins l’essayer.

Au fond, je crois que le sous-texte était : il existe un choix techno « juste » qui te place du côté des gagnants. Des cool kids. Des bonnes conférences. Des articles sur Hacker News.

Puis j’ai fait quelque chose d’impopulaire — du moins selon ma manière de penser : j’ai choisi un framework. Un. Et j’y suis resté.

Pas parce qu’il est le meilleur dans l’absolu. Mais parce qu’il me permet de livrer de la valeur avec peu de personnes sur plusieurs projets, sans devenir fou. Parce qu’il a une philosophie qui tient les contraintes réelles d’une boîte italienne. Convention sur configuration, batteries incluses, doc maniaque. Pas les contraintes imaginaires d’une startup de la Bay Area qui vit de slides et de runway.

La vérité inconfortable est que beaucoup de choix « courageux » dans les PME ne relèvent pas du courage. C’est de la vanité. Choisir Rust pour un outil de gestion qu’utiliseront quarante personnes n’est pas de l’ingénierie. C’est du narcissisme avec un compilateur.

À un moment, j’ai cessé de chercher le bon stack et j’ai commencé à chercher le stack honnête. Celui qui ne ment pas sur la complexité qu’il introduit. Celui que tu peux maintenir quand les seniors partent, quand le budget se serre, quand le client change d’avis trois fois.

J’ai cessé de protéger l’équipe du business

Le passage le plus difficile.

Pendant des années, j’ai fait bouclier. Le client demande une modif folle ? Je filtre. Le commercial vend quelque chose qui n’existe pas ? Je gère. Un document incompréhensible arrive ? Je traduis et je passe à l’équipe seulement la partie technique, propre, digérée.

Je me croyais bon leader. En réalité, je créais probablement des invalides.

D’excellents devs, oui, mais déconnectés. Ils ne savaient pas vraiment pourquoi ils construisaient ce qu’ils construisaient. Ils ne savaient pas lire une exigence métier. Ils n’avaient jamais parlé à un client. Et quand ils tombaient sur une ambiguïté, plutôt que d’appeler, ils ouvraient un ticket et attendaient.

Le changement, pour nous, a été de bâtir un parcours interne qu’on a appelé « du dev au product owner ». Pas pour transformer tout le monde en PM. Plutôt pour ôter le filtre.

Pour dire une chose simple, un peu inconfortable : le bordel est aussi le vôtre. Le client confus est aussi le vôtre. L’exigence ambiguë est aussi la vôtre.

Et surtout, la satisfaction de livrer quelque chose qui marche pour quelqu’un est aussi la vôtre.

Je pensais que ce serait impopulaire. Je me trompais. Ils m’ont surpris. Peut-être qu’ils attendaient juste qu’on leur donne la permission de sortir de la bulle.

J’ai cessé de dire « de toute façon c’est public » sur la compliance

Pendant des années, ma posture sur la compliance a été celle, typique, du secteur IT italien. Le minimum strict, fait au dernier moment, traité comme un coût et jamais comme un investissement.

RGPD ? Un bandeau cookies et une politique privée copiée. Accessibilité ? « On verra plus tard. » Sécurité ? « On n’est pas une cible. »

Puis j’ai commencé à lire vraiment certaines normes européennes. Pas les articles sur ces normes, les textes eux-mêmes. Et là, deux choses se sont éclaircies.

La première : le législateur européen, pour une fois, ne plaisante pas. Les sanctions sont réelles, les calendriers sont serrés, et la chaîne de responsabilité va jusqu’au fournisseur du composant logiciel. C’est-à-dire nous.

La seconde, plus importante : sur un marché où tout le monde attend la dernière minute, qui bouge en premier a un avantage concurrentiel énorme. Pas parce qu’il est meilleur. Parce qu’il est le seul à pouvoir dire au client « oui, on est prêts » quand le client, en panique, commencera à le demander.

À un moment, j’ai cessé de traiter la compliance comme une obligation. J’ai commencé à la traiter comme un produit.

Et je me demande souvent pourquoi on a mis si longtemps à le comprendre. Peut-être parce qu’il est plus confortable de croire que ce sont des paperasses, jusqu’à ce que ça devienne soudain un problème avec une échéance.

J’ai cessé d’embaucher pour des compétences techniques

Récente, et un peu douloureuse.

J’ai passé des semaines à chercher une figure importante. Des CV excellents. Des années d’expérience. Stacks solides. Bonnes références. J’en ai écarté plusieurs, non parce qu’ils n’étaient pas bons, mais parce qu’ils utilisaient l’IA comme ils utilisaient Stack Overflow il y a dix ans. Comme un oracle.

Ce que je cherchais, et que j’ai du mal à expliquer aux recruteurs, est différent. Je cherchais quelqu’un capable d’écrire une spécification déclarative si précise qu’un agent IA puisse l’implémenter avec une supervision minimale.

Pas un prompt engineer. Un penseur de systèmes qui utilise l’IA comme runtime, pas comme béquille.

La différence semble subtile, elle ne l’est pas. C’est la différence entre « j’ai demandé à ChatGPT de m’écrire le code » et qui maintient un fichier claude.md dans le repo avec conventions architecturales, patterns, contraintes de domaine. La différence entre conversation et spécification. Entre artisanat et ingénierie.

J’ai cessé d’embaucher des devs qui savent programmer. J’ai commencé à chercher des devs qui savent spécifier et qui ensuite vérifient ce que l’IA a produit avec la même rigueur qu’ils mettraient à reviewer le code d’un junior.

Le marché italien ne semble pas encore prêt à cette distinction, malheureusement. Mais j’ai l’intuition qu’il le sera vite. Et qui n’arrive pas à temps risque de se retrouver avec des équipes qui « produisent » beaucoup mais comprennent peu.

J’ai cessé de parler italien au travail

Cela paraît mince. Ça ne l’est pas.

Quand un nouveau junior non italien, excellent, est arrivé, on s’est trouvé devant un choix. Continuer à travailler en italien entre nous et utiliser l’anglais avec lui, en créant de fait une équipe à deux vitesses. Ou faire le switch complet.

On a choisi le switch complet. Tout en anglais. Jira en anglais. Chat en anglais. Daily en anglais. Rétro en anglais. Pour tout le monde.

Je ne l’ai pas fait que pour lui. Je l’ai fait pour nous.

Parce qu’une boîte de quelques personnes dans une ville italienne qui travaille uniquement en italien est une boîte qui restera probablement de quelques personnes dans cette ville. Il n’y a rien de mal à ça. Mais ce n’est pas ce qu’on voulait.

L’anglais, au final, n’est pas une langue. C’est une infrastructure. Comme Git, comme la CI/CD, comme la documentation. Soit tu l’as, soit tu es coupé.

C’était inconfortable. Certains ont peiné. Mais aujourd’hui, en lisant les descriptions des pull requests, les messages, les mails, je trouve que ça en valait la peine.

J’ai cessé de croire que le bon code parle de lui-même

C’est peut-être le plus dangereux mensonge de l’ingénierie logicielle. L’idée romantique selon laquelle, si le code est propre, testé, bien structuré, sa valeur est évidente. Que le mérite technique se défend tout seul.

Ça ne marche pas comme ça.

Le bon code que personne ne comprend est indissociable du code médiocre. Le refactoring que personne ne raconte devient un coût, pas un investissement. La migration architecturale sans business case écrit ressemble à un caprice de la tech.

J’ai appris, tard, que la moitié du boulot d’un tech leader, c’est raconter.

Expliquer au board pourquoi une migration n’est pas une lubie mais une réduction du risque. Expliquer au client pourquoi les tests automatisés qu’il a payés sont la raison pour laquelle il dort tranquille. Expliquer à l’équipe pourquoi la CI/CD n’est pas de la bureaucratie mais de la liberté et du confort.

Si tu ne sais pas raconter la valeur de ce que tu construis, quelqu’un d’autre la racontera à ta place. Et il la racontera mal.

Ce que je n’ai pas encore cessé de faire

Pour être honnête jusqu’au bout, il y a une chose que je devrais cesser de faire et que je n’arrive pas encore à lâcher.

Travailler comme si j’étais le seul à tenir les pièces ensemble.

Trop de choses passent encore par moi. Pas parce que l’équipe n’est pas capable, au contraire, mais parce que je n’ai pas encore bâti les systèmes qui me rendraient superflu dans chacun des domaines où on opère.

Et c’est ça qui me fait le plus peur.

Parce que chaque transition précédente avait un substitut clair. Cesser d’écrire du code ? Les spécifications. Cesser d’écrire des spécifications ? La stratégie. Cesser de faire les code reviews ? Un tech lead. Mais cesser d’être le point de convergence de tout, c’est différent.

Le substitut, c’est la confiance dans les systèmes. Et les systèmes, à dire vrai, je dois encore finir de les construire.

On en reparlera.

Il m’arrive parfois de parler à des dirigeants qui ont dix, trente, quatre-vingts personnes. Pas de Chief AI Officer, pas de roadmap à dix-huit mois, et souvent pas envie qu’on leur dise qu’ils « doivent se transformer ». Ils ont une autre urgence, beaucoup plus concrète : faire tourner la boîte.

Et pourtant la question arrive, même si elle est rarement formulée telle quelle : concrètement, qu’est-ce qu’on fait avec l’IA ?

Les grands groupes se la posent déjà officiellement, avec budgets, équipes dédiées et programmes aux acronymes ronflants. Les PME, elles, sont sur un autre terrain, fait de confusion et de signaux contradictoires. Ce n’est pas leur faute. La conversation publique sur l’IA semble pensée pour qui dispose de temps, de ressources et de structures qu’une PME n’aura jamais.

Alors je vais le dire simplement, presque brutalement.

Combien de personnes dans ton équipe savent obtenir d’un agent IA un résultat meilleur que celui qu’elles produiraient seules ?

Pas combien « l’utilisent ». Pas combien ont ChatGPT ouvert dans un onglet. Combien savent donner des instructions précises, juger l’output de façon critique, itérer avec méthode jusqu’à ce qu’il en sorte quelque chose qui tient. En vente, marketing, ops, finance, juridique, produit, RH.

Si la réponse honnête est « peu » ou « je ne sais pas », tu as probablement un problème. Et dans les PME ce problème pèse plus, parce qu’il n’y a pas le luxe de remettre à plus tard.

Le malentendu le plus coûteux de 2026

Le malentendu, à mon avis, est unique : penser que l’IA est une question tech.

Elle ne l’est plus. Elle ne l’est plus depuis au moins un an.

L’IA est devenue un multiplicateur de capacités individuelles, transversal à chaque rôle. Un commercial qui sait se construire une analyse compétitive en dix minutes joue une autre partie qu’un autre qui y met deux jours. La personne en charge de l’administration qui se fait générer un tableau de bord sensé sur les coûts en une heure compete dans une catégorie différente que celle qui assemble tout en une semaine en repêchant des données dans des Excel vieux et à moitié cassés.

Et on ne parle pas seulement du mot « efficacité ». L’efficacité, c’est faire les mêmes choses plus vite. Ici on parle de personnes qui commencent à faire des choses qu’elles ne faisaient pas avant, parce que le coût cognitif était trop élevé.

Une offre vraiment personnalisée pour chaque prospect, plutôt que le PDF recyclé avec le nom changé en couverture. Une analyse du cash-flow des trois dernières années qui te révèle des patterns que personne ne t’avait jamais signalés. Des rapports d’avancement de projet qui n’existaient pas avant parce que « pas le temps ».

Cela peut arriver.

Mais seulement si quelqu’un sait gouverner l’outil. S’il le traite comme un collaborateur à diriger, pas comme un jouet à ignorer ou un oracle à interroger au hasard.

« Gouverner » n’est pas « utiliser »

Cette distinction est le cœur de tout, et il est frappant de voir à quel point elle n’est souvent pas faite.

Utiliser l’IA, c’est demander quelque chose et accepter ce qui arrive. C’est le prompt-and-pray. Tu écris une requête, tu copies la réponse, tu colles dans un mail et tu espères que ça passe. C’est compréhensible, au début tout le monde fait ça. Mais ça ne vaut rien, et c’est parfois dangereux.

Gouverner l’IA, c’est autre chose. C’est savoir quoi demander, comment le demander, et surtout comprendre quand la réponse est fausse même si elle paraît parfaite.

C’est donner du contexte, des contraintes, des critères de succès. C’est itérer pour de vrai. Pas « réécris mieux », mais « réécris en tenant compte que notre client est un acteur public, avec des contraintes de procurement et des cycles de décision de six mois ».

Qui gouverne l’IA a un modèle mental de l’outil. Il sait ce qu’elle fait bien, où elle a tendance à inventer, où elle peut devenir un risque. Il sait quand faire confiance et quand vérifier. Il sait quand l’output est un point de départ et quand il peut être considéré comme fini.

Et non, ce n’est pas un talent inné. C’est une compétence qui se développe. Mais voici la partie un peu inconfortable : tout le monde ne la développe pas. Pas par manque d’intelligence, mais parce qu’il faut une mentalité spécifique, et elle n’est pas aussi répandue qu’on aime le croire.

La mentalité que tu ignores en entretien

Quand tu recrutes, tu regardes en général expérience, compétences verticales, culture d’entreprise, peut-être leadership. Tout va bien.

Mais tu risques de négliger une variable qui, dans les deux ans qui viennent, séparera ceux qui performent de ceux qui rament.

La variable est la suivante : la personne en face de toi sait-elle travailler à un niveau d’abstraction supérieur à celui de l’exécution ?

Qui travaille au niveau de l’exécution accomplit des tâches. Mails, rapports, analyses, documents. Bien fait, avec métier. Mais une chose à la fois, et son temps est la seule ressource.

Qui travaille au niveau de la spécification et du gouvernement définit ce qui doit être fait, avec quelle qualité, sous quelles contraintes, puis dirige un agent (IA ou humain — à ce niveau la distinction commence à s’estomper) pour l’exécuter. Il supervise, corrige, affine. Et passe à autre chose.

Cela ne veut pas dire que l’exécution ne compte pas. Cela veut dire que la valeur de l’exécution pure se comprime rapidement, tandis que la capacité de gouvernement s’étend.

Si tu n’évalues pas cette capacité au moment du hiring, tu recrutes des exécutants dans un monde qui récompense les directeurs.

Trois questions qui changent un entretien

Peu importe que tu recrutes un marketing manager, un contrôleur de gestion, un office manager ou un CTO. Trois questions, à mon avis, fonctionnent presque toujours.

« Raconte-moi la dernière fois que tu as utilisé un agent IA pour un livrable réel »

Pas une expérimentation. Pas un jeu. Un livrable terminé devant un client, un patron, un comité.

Écoute comment elle en parle. A-t-elle donné des instructions précises ou des prompts génériques ? A-t-elle itéré ? A-t-elle vérifié l’output ? A-t-elle intégré son jugement, ou tout pris tel quel ?

Si la réponse est « jamais », en 2026, c’est une donnée. Pas forcément éliminatoire, mais une donnée à peser sérieusement.

« Comment saurais-tu que l’output est faux ? »

Voilà la question clé.

L’IA produit des résultats convaincants même quand ils sont totalement inventés. Un nombre plausible mais faux. Un raisonnement logique partant d’une prémisse inexistante. Un texte parfaitement rédigé mais qui dit le contraire de ce qu’il faut.

Qui sait gouverner l’IA a développé des anticorps. Une méthode, même rudimentaire, pour distinguer un output fiable d’un output toxique.

Qui ne l’a pas est plus dangereux que qui n’utilise pas l’IA du tout, parce qu’il produit des erreurs avec l’assurance de qui croit avoir raison.

« Si tu avais un assistant IA dédié huit heures par jour, comment réorganiserais-tu ton travail ? »

Cette question sépare ceux qui pensent en tâches de ceux qui pensent en système.

La réponse médiocre : « je ferais les mêmes choses plus vite ».

La réponse intéressante : « je ferais des choses différentes », suivie d’une vision concrète. Quelles priorités changeraient ? Quels livrables existeraient enfin ? Quelles activités seraient supprimées ou réduites ?

Qui répond bien a déjà compris que l’IA n’est pas qu’un outil d’efficacité. C’est un outil de levier. Et il sait où placer le levier.

L’éléphant dans la pièce : les personnes clés que tu as déjà

Le plus gros problème, souvent, ce n’est pas qui tu recrutes. C’est qui tu as déjà.

Dans une PME, l’organigramme est court. Pas de couches de middle management. Tu as trois, cinq, huit personnes clés qui tiennent la boîte debout.

Le responsable commercial qui connaît tous les clients par cœur. La gestionnaire administrative qui fait tourner la machine depuis quinze ans. Le chef de projet sur qui tu déposes tout ce que tu ne sais pas où poser.

Si ces personnes ne touchent pas à l’IA parce que « ce n’est pas mon job » ou « j’ai toujours fait comme ça et ça a marché », tu as un goulot d’étranglement qu’aucun nouveau recrutement ne compensera.

Dans un grand groupe, tu peux contourner avec une équipe dédiée. Dans une PME, non. Les personnes clés sont l’entreprise. Si elles ne changent pas, rien ne change.

Et là vient la partie vraiment inconfortable, celle qui crée généralement un peu d’agacement.

Dans beaucoup de PME, la première personne qui n’a pas reçu le message est très haut placée.

Si c’est toi, et que tu lis avec un mélange d’intérêt et d’agacement, ça vaut peut-être la peine de t’arrêter une seconde sur cet agacement. Je me demande souvent si ce n’est pas l’un des signaux les plus utiles dont on dispose, quand quelque chose nous concerne plus qu’on ne le voudrait.

Le choix, au final, est net : poser que la capacité à gouverner des agents IA est une compétence attendue pour chaque rôle, en commençant par le tien. Pas optionnelle. Pas « nice to have ». Attendue, évaluée, mesurée.

Ce n’est pas une question de génération

Il y a un autre raccourci mental qui semble pratique mais ne tient pas : « les jeunes sont natifs numériques, donc ils comprennent l’IA ».

Ce n’est pas vrai.

J’ai vu des vingtenaires utiliser l’IA comme un moteur de recherche un peu plus brillant. Et j’ai vu des cinquantenaires l’intégrer au flux de travail d’une manière que, sincèrement, je n’aurais pas imaginée.

La variable n’est pas l’âge. C’est la disposition à repenser sa façon de travailler. À dire : « peut-être que la manière dont j’ai toujours fait cette chose n’est plus la meilleure ».

Il faut de l’humilité, de la curiosité et un peu d’inconfort. Trois choses sans âge.

Donc non, recruter des jeunes en espérant que l’IA entre dans la boîte par osmose ne suffit pas. Il faut un choix délibéré sur les compétences que tu valorises, que tu récompenses et, disons-le, que tu exiges.

Le coût de l’inertie, en chiffres (à peu près)

Ce ne sont pas des comptes parfaits, mais l’ordre de grandeur est là.

Un knowledge worker qui gouverne bien l’IA a souvent un output équivalent à 1,5 ou 2 fois celui de qui ne l’utilise pas. Pas parce qu’il travaille plus, mais parce qu’il élimine le travail à faible valeur : recherches manuelles, premières moutures, analyses exploratoires, structuration de données, préparation de slides.

Dans une équipe de dix, si cinq gouvernent l’IA et cinq non, c’est comme si tu avais douze ou treize personnes. Sans en recruter aucune.

Inverse maintenant le raisonnement.

Si l’équipe de ton concurrent est alignée sur cette compétence et la tienne non, ton équipe de dix reste une équipe de dix. La sienne devient une équipe de quinze ou vingt, au moins pour certaines activités.

Et l’écart se creuse chaque mois, parce que les outils s’améliorent et que ceux qui les gouvernent captent la valeur incrémentale. Ceux qui ne les gouvernent pas restent immobiles.

Ce n’est pas du futurisme. C’est de l’arithmétique.

Que faire lundi matin

La bonne nouvelle : pas besoin de task force, de consultants ou de programmes de transformation à douze mois et six cent mille euros.

Trois choix pratiques, et un peu de cohérence.

Le premier : intégrer la capacité de gouvernement IA aux critères d’évaluation pour chaque poste ouvert. Pas comme exigence technique, mais comme compétence transversale, au même niveau que la communication ou le travail en équipe. Pose ces trois questions. Écoute vraiment les réponses.

Le deuxième : demander à tes reports directs comment ils utilisent l’IA au quotidien. Pas par sondage anonyme, mais en one-to-one. Tu découvriras des choses surprenantes dans les deux sens. Qui l’utilise bien le fait souvent en silence. Qui l’utilise mal ne se rend parfois pas compte de la fragilité de sa méthode.

Le troisième : montrer l’exemple.

Si tu es un dirigeant qui n’a jamais utilisé un agent IA pour préparer une offre, analyser un bilan ou rédiger une communication importante, le message envoyé est limpide : ce n’est pas important.

Et ton organisation te croira.

Dans une PME, tu ne peux pas déléguer le changement. Ou il part de toi, ou il ne part pas.

Ce n’est pas une morale

Dans cinq ans, on regardera probablement les processus de hiring de 2025 comme on regarde aujourd’hui ceux de 2010, avec un mélange de tendresse et d’incrédulité. « Vraiment, vous recrutiez des gens sans vérifier s’ils savaient travailler avec l’IA ? »

Vraiment.

Et qui arrête le plus tôt, sans attendre que ça devienne « standard », aura un avantage que les autres mettront des années à combler.

La bonne question, au fond, n’est peut-être pas si la prochaine personne que tu recrutes sait utiliser l’IA.

C’est si elle saura la gouverner. Et si toi, tu seras prêt à l’exiger, même quand c’est inconfortable.

Je travaille dans une PME tech à Pescara. On est une douzaine, pas cinquante, pas deux cents. On fait du logiciel pour des clients variés, du secteur public à des plateformes SaaS, et ce qui nous tient debout depuis toujours, c’est une sorte d’obsession pour la solidité. Architectures pensées, code qui tient, systèmes qui ne s’effritent pas quand on y met de vraies données, de vrai argent, de vraies décisions.

Et pourtant, ces derniers mois, je me suis retrouvé à penser une chose un peu amère : c’est un moment brutal pour avoir des idées. Pas par manque de créativité — au contraire. Le problème, c’est que la créativité arrive souvent avec un sentiment d’impuissance.

Le syndrome du « ils l’ont déjà fait »

Ça se passe comme ça, avec une régularité presque comique.

Lundi matin, brainstorming. Quelqu’un lance une idée. On s’enflamme, on imagine comment la faire bien, quelle serait la bonne architecture, où sont les risques, comment la vendre sans se raconter d’histoires.

Puis arrive mercredi soir. Scroll sur LinkedIn ou sur Hacker News, et là, l’annonce : Google, Microsoft, OpenAI, ou une startup tout juste financée à des montants qu’on ne voit que dans les podcasts, vient de présenter la même chose. Ou quelque chose d’assez proche pour que notre idée passe, aux yeux du marché, pour un clone en retard.

Ce n’est même pas une question de « ils nous ont copiés ». C’est plus banal et plus déprimant : ils ont l’échelle. Et dans cette phase historique, l’échelle semble compter plus que tout.

Je me demande souvent si on n’entre pas dans une époque où l’innovation, la vraie, devient presque un luxe réservé à ceux qui peuvent se permettre de se tromper vite et en public.

Quand on ne te bat pas parce qu’ils sont meilleurs, mais parce qu’ils sont plus rapides

Jusque-là, ce serait déjà frustrant. Mais il y a un niveau de plus, plus difficile à digérer.

Parce qu’on ne te bat pas toujours sur le temps avec un meilleur produit. Parfois, on te bat avec quelque chose de médiocre, expédié à la va-vite, avec des tests minimes et une confiance presque arrogante dans le fait que la marque tiendra de toute façon.

Le « vibe coding », qui semblait jusqu’il y a peu un truc d’indie hacker, est entré dans l’enterprise. Et je ne parle pas du junior qui utilise Copilot pour écrire un composant. Je parle d’équipes entières qui génèrent des pans entiers d’application avec des prompts, font deux essais à la volée, et mettent ensuite tout en production.

Ces derniers mois, j’ai vu des plateformes avec des failles à donner des frissons. Du XSS qu’on chope en cinq minutes, des API sans rate limiting, des flux de paiement sans idempotence, une gestion des données personnelles qui ferait pâlir n’importe quel DPO sérieux.

Et pourtant, elles sont là. Sur le marché. Avec des utilisateurs. Avec du chiffre.

Le message implicite, qui te tombe dessus même si tu ne veux pas l’entendre, est : la qualité ne compte pas, c’est la vitesse qui compte.

Et si la qualité ne compte pas, alors nous les petits, qui bâtissons sur la qualité notre réputation et souvent notre survie, quelle place avons-nous ?

L’épiphanie de Bruxelles (que je n’attendais pas)

Voici la partie que, il y a deux ans, je n’aurais jamais cru écrire.

Pendant longtemps, j’ai regardé la régulation européenne avec agacement. Le RGPD en 2018 m’avait paru un bloc : beaucoup de peine pour ceux qui travaillaient déjà bien, tandis que les grands continuaient à faire leurs affaires et, au pire, payaient des amendes qui n’étaient pour eux que de la petite monnaie.

Puis j’ai commencé à regarder le tableau qui se forme aujourd’hui. Et j’ai eu une sensation étrange, presque contre-intuitive : Bruxelles est peut-être l’une des rares armes qui nous restent.

Pas parce que « la bureaucratie, c’est beau », loin de là. Mais parce que ce qui prend forme n’est pas un règlement isolé. C’est un écosystème normatif intégré qui change l’aune de la concurrence.

Si l’Europe est faite à 80 % de PME et qu’elle veut que ces PME survivent à l’ère de l’IA, elle doit faire une chose simple et très difficile : éviter que la taille soit le seul avantage concurrentiel.

Et, en bien ou en mal, c’est exactement ce qu’elle essaie de faire.

Sept normes, une seule direction

Je les énumère, oui, mais avec une idée précise : ne les lis pas comme « sept obligations ». Lis-les comme une stratégie industrielle.

AI Act, le grand niveleur vers le haut

L’AI Act est en vigueur depuis le 1er août 2024, avec application progressive. Interdictions à partir de février 2025, obligations pour les systèmes à haut risque à partir d’août 2026.

Ce qui est intéressant, c’est qu’il ne dit pas « ne faites pas d’IA ». Il dit « faites-la bien ». Il classe les systèmes par risque, et là où le risque est haut, il demande des choses qui devraient être normales : gestion du risque, qualité des données, supervision humaine, documentation, transparence.

Pour une PME qui travaille déjà proprement, la compliance est souvent un delta gérable. Pas gratuit, certes. Mais gérable.

Pour qui a mis en production un système critique construit en trois semaines sans vraiment savoir ce qu’il fait, ça devient un gouffre. Il faut repenser processus, gouvernance, architecture. Il faut ralentir.

Et c’est là que l’AI Act devient, paradoxalement, pro-PME. Pas parce qu’il protège les petits en tant que petits, mais parce qu’il récompense ceux qui ont déjà la culture du « faisons-le bien ».

Il y a aussi un point qui m’intéresse beaucoup pour les modèles à usage général : obligations de transparence et de documentation pour les fournisseurs, surtout pour les modèles à risque systémique. Traduit : si je construis un produit sur un modèle de fondation, j’ai plus de droit à connaître ses limites, ses risques, ses contours. Aujourd’hui, on ne le comprend souvent qu’en lisant des papers et des billets corporate.

Cyber Resilience Act, la fin du « ça marche, n’y touche pas »

Le CRA est en vigueur depuis le 10 décembre 2024. Obligations de signalement à partir de septembre 2026, application pleine à partir de décembre 2027.

Ici, la musique change vraiment : si tu mets sur le marché européen un produit avec des éléments numériques, tu es responsable de la sécurité tout au long du cycle de vie. Mises à jour de sécurité pendant au moins cinq ans, gestion documentée des vulnérabilités, signalements rapides, et surtout SBOM.

Le SBOM, sans romantisme, c’est un inventaire : savoir ce qu’il y a dans ton logiciel, dépendances comprises. Quand sort une CVE critique, tu n’as pas à faire de l’archéologie. Tu sais.

Et tu sais qui est souvent déjà structuré comme ça ? Les PME avec des stacks modernes, des pipelines décentes, des dépendances tracées.

Qui souffre, en revanche ? Les organisations énormes avec des années de dette technique, des applications legacy intouchables, des composants figés en 2016, et personne qui ait vraiment la carte du territoire.

Le CRA fait passer la maintenance d’une chose « si on a le temps » à un devoir. Et soudain, l’attention maniaque aux mises à jour cesse d’être une fixation personnelle pour devenir une posture concurrentielle.

Product Liability Directive, le logiciel n’est plus intouchable

La nouvelle PLD a été adoptée en 2024, et les États membres doivent la transposer d’ici décembre 2026.

Là, j’avoue avoir un peu peur. Parce qu’elle étend la responsabilité du fait des produits défectueux au logiciel. Et dans certains cas, elle introduit des mécanismes comme le renversement de la charge de la preuve : s’il y a un lien plausible entre défaut et dommage, le producteur doit démontrer que le produit n’était pas défectueux.

Imagine maintenant une boîte qui a expédié une app financière sans tests sérieux, sans code review, sans documentation. Si un dommage survient, comment le démontre-t-elle ?

Une PME qui travaille avec CI, tests automatiques, reviews tracées, décisions d’architecture annotées, changelogs et notes de release, se retrouve avec quelque chose de précieux qu’elle n’avait pas appelé ainsi : un dossier de défense.

La PLD, concrètement, transforme la qualité du processus en bouclier juridique.

European Accessibility Act, le web n’est pas que pour ceux qui voient bien

L’EAA s’applique déjà depuis le 28 juin 2025.

Accessibilité signifie WCAG 2.1 AA comme référence : sémantique, contraste, clavier, lecteur d’écran, alternatives textuelles. Pas la « belle page », la page utilisable aussi par celles et ceux qui ont une situation de handicap.

Qui a toujours traité l’accessibilité comme exigence part avantagé. Qui a construit des interfaces splendides et inutilisables avec un lecteur d’écran doit courir.

Et là, il y a une opportunité très concrète : l’accessibilité devient un service. Audits, remédiation, design systems accessibles. Il y a aussi l’exemption pour les microentreprises, un détail intéressant : tu peux être assez petit pour ne pas être obligé dans certains cas, mais assez compétent pour aider les autres.

NIS2, la cybersécurité n’est plus optionnelle

NIS2 devait être transposée d’ici octobre 2024, et en Italie la transposition est arrivée. L’application est progressive.

Ce qui touche les PME n’est pas seulement « tu rentres ou non ». C’est l’effet supply chain. Si ton client est sujet à NIS2, il te demandera des garanties. Procédures. Incident response. Mesures.

La sécurité devient un prérequis commercial. Si tu ne démontres pas une posture sérieuse, tu ne travailles pas avec certains clients. Point.

Et là encore, qui a investi tôt — peut-être avec peine et sans gloire — se retrouve devant.

Data Act, les données générées sont aussi à toi

Le Data Act est en vigueur depuis le 11 janvier 2024 et s’applique depuis le 12 septembre 2025.

L’idée, dite simplement : les données générées par l’usage d’un produit connecté doivent être accessibles à l’utilisateur et, sur demande, partageables avec des tiers.

Pour qui vit du lock-in, c’est une secousse. Pour les PME, ça peut être une brèche énorme : si les données doivent être portables, quelqu’un doit construire les infrastructures, les API, les connecteurs, les formats.

C’est presque une norme anti-lock-in. Et beaucoup de PME, banalement, n’ont jamais eu la force de faire du lock-in agressif. Ce « manque » peut désormais devenir un avantage.

DMA et DSA, des gatekeepers avec d’autres règles

Le DMA est pleinement applicable depuis mars 2024, le DSA depuis février 2024.

Ici, le point est politique mais très concret : les gatekeepers ne peuvent plus jouer avec la même impunité qu’avant. Interopérabilité, interdictions d’auto-préférence, plus de transparence.

Est-ce suffisant ? Probablement pas. J’attends des échappatoires, des interprétations créatives, des avocats très bien payés.

Mais un principe change : être grand ne te donne plus automatiquement le droit de tricher.

Mises ensemble, ce n’est pas de la compliance : c’est un changement de métrique

Si je regarde ces normes comme un ensemble, je vois un message assez clair.

Sur le marché européen, l’idée est que celui qui fait les choses bien gagne.

Bien signifie : IA transparente et supervisée, logiciel maintenu et sûr, responsabilité réelle quand on cause des dommages, accessibilité comme exigence, cybersécurité comme pratique quotidienne, données moins enfermées, plateformes dominantes plus contrôlées.

Et, presque sans le vouloir, cette direction valorise certaines caractéristiques typiques des PME sérieuses : attention au détail, proximité du client, stacks plus à jour, moins de legacy intouchable, moins d’incitations au « lance-le et on verra ».

Mais la réalité n’est pas toute rose

Il serait malhonnête de dire que la compliance est gratuite. Elle coûte du temps, de l’argent, du focus. Et dans une boîte de taille moyenne (ou petite), chaque heure passée sur la documentation et les processus est une heure qui n’est pas sur le produit.

Il y a aussi un risque réel : que la compliance redevienne un avantage des grands, ceux qui peuvent se payer des départements juridiques et des plateformes de gouvernance.

Mais l’Europe a peut-être compris un point : la proportionnalité. Beaucoup de normes distinguent par risque et par taille. Et il y a une autre voie, qui me semble très concrète : transformer la compliance en service.

Si tu comprends vraiment CRA, AI Act, NIS2, EAA — pas seulement comme « cases à cocher » mais comme implications techniques —, tu peux le vendre. SBOM, audits, hardening, gouvernance IA, audits d’accessibilité. La compliance cesse d’être un simple coût pour devenir une compétence de marché.

Ce que je ferais lundi matin, vraiment

Je ne veux pas conclure par la morale. Je préfère conclure par du concret, parce que c’est peut-être là que les PME peuvent s’entraider.

On essaie de bâtir un cadre interne unique, pas sept processus séparés. Forcément, on est petits. Et cette fois, être petits est un avantage, parce qu’on ne peut pas se permettre de silos. La doc nécessaire au CRA aide aussi avec la PLD. Le SBOM sert au CRA, mais devient aussi une base utile pour des demandes type NIS2. La logique risk-based de l’AI Act s’emboîte bien avec l’approche du RGPD.

On essaie aussi de traiter la compliance comme un produit, pas seulement comme une obligation. Si un client doit se mettre en conformité, quelqu’un doit l’accompagner. Et si tu l’accompagnes bien, tu ne vends pas de la « bureaucratie ». Tu vends de la réduction du risque, de la continuité opérationnelle, de la réputation.

Puis il y a la formation. Pas celle qui s’arrête aux slides. Une formation pour comprendre le pourquoi des règles, parce que si tu comprends le pourquoi, la checklist sert moins. Tu raisonnes mieux quand arrive le cas étrange, celui qui n’est écrit nulle part.

Et enfin, le réseau. Templates, processus, leçons partagées. La compliance n’est pas un jeu à somme nulle. Si ton écosystème est plus solide, tu l’es aussi.

C’est peut-être ça, le point : pas besoin de s’excuser d’être petits

Je n’ai pas d’illusions. Les big tech investiront dans la compliance, trouveront des moyens de s’adapter, feront du lobbying, chercheront des interprétations favorables.

Mais quelque chose a changé : l’Europe est en train de dire que, sur son marché, la vitesse sans responsabilité n’est plus un superpouvoir.

Et pour ceux qui, comme nous, ont toujours bâti avec soin — pas par vertu mais par nécessité —, c’est une nouvelle étrange et belle. Peut-être qu’on n’a pas besoin de devenir plus grands. Peut-être qu’il suffit de continuer à faire les choses avec attention et responsabilité.

Sauf que maintenant, enfin, quelqu’un essaie de faire compter ce choix.

Monsieur Marconi, bienvenue en 2026. Comment vous sentez-vous ?

Confus. Mais moins que vous ne le pensez. J’ai consacré ma vie à supprimer les fils. Je vois que vous y êtes parvenus. Ce que je n’avais pas prévu, c’est que vous remettriez des fils pour recharger les appareils sans fil.

Vous parlez des chargeurs.

Je parle du fait que dans cet établissement il y a quatorze personnes et onze d’entre elles sont reliées à une prise murale. J’ai éliminé les fils en 1896 et vous les avez réintroduits en 2026 pour ne pas rester sans TikTok. Je me sens berné.

En réalité, la recharge sans fil existe aussi.

On me l’a expliquée. Vous posez l’appareil sur un disque et il se recharge. Sans fil. Mais le disque, lui, est branché à un fil. Vous avez inventé un intermédiaire entre le fil et l’appareil et vous l’appelez « wireless ». De mon temps, un maillon de plus dans la chaîne s’appelait inefficacité. Aujourd’hui, ça s’appelle innovation.

L’éther saturé

C’est la première chose que vous avez remarquée en arrivant en 2026 ?

Non. La première chose que j’ai remarquée, c’est le bruit. Pas le bruit physique. Celui-là a diminué, vos moteurs sont plus silencieux que les nôtres, les villes sont moins chaotiques que je ne l’imaginais. Je parle du bruit électromagnétique. De mon temps, pour capter un signal radio, je devais m’isoler, construire d’énormes antennes, éliminer toute interférence. Vous vivez immergés dans un champ électromagnétique si dense que si je tentais mon expérience de 1901 depuis ce café, je n’entendrais rien. Vous avez réussi à saturer l’éther. Bravo.

Techniquement, l’éther n’existe pas. Einstein a…

Oui, oui, on me l’a dit. On m’a dit aussi que Pluton n’est plus une planète. Vous avez l’habitude de retirer les choses après que les gens s’y soient attachés.

Le smartphone et les filtres

On vous a donné un smartphone pour vous orienter. Comment ça s’est passé ?

Votre collègue m’a remis l’appareil. Vous l’appelez téléphone, mais il n’a rien à voir avec un téléphone, et il m’a montré les fonctions de base. Je peux téléphoner — la seule chose que vous ne faites jamais avec cet objet. Je peux écrire des messages, prendre des photos, consulter le savoir humain entier, calculer la trajectoire d’un satellite et commander à dîner. C’est l’appareil le plus puissant jamais construit par l’homme. Vous l’utilisez surtout pour vous disputer avec des inconnus.

Ce n’est pas tout à fait…

Il m’a aussi montré que l’appareil a trois caméras à l’arrière. Trois. La première photographie de l’histoire a été prise par Niépce en 1826 avec un appareil de vingt kilos qui demandait huit heures d’exposition. Vous avez trois caméras dans la poche et vous les utilisez pour photographier votre assiette de pâtes avant de la manger. Niépce a photographié un toit depuis sa fenêtre et y a passé huit heures. Vous photographiez une carbonara en deux secondes, puis vous en perdez quarante autres à choisir le bon filtre.

Les filtres sont une question esthétique.

Les filtres sont une question philosophique. Vous dites à la réalité qu’elle n’est pas assez belle telle quelle. Le coucher de soleil doit être plus orangé. Les pâtes plus dorées. Votre visage plus lisse. Vous avez l’appareil photo le plus sophistiqué de l’histoire et la première chose que vous en faites, c’est mentir.

Vous ne diriez pas la même chose de la peinture ? Les peintres aussi interprétaient la réalité.

Les peintres y mettaient des années d’étude. Votre filtre « Valencia » y met un centième de seconde. La différence entre l’art et le mensonge est le temps qu’on y consacre.

Vous avez pris quelques photos ?

J’ai pris une photo de la mer. D’ici, on voit la mer, c’est une chose que j’apprécie beaucoup dans cette ville. Je l’ai prise sans filtre. Puis le téléphone m’a suggéré de l’« améliorer » automatiquement. J’ai appuyé et la mer est devenue plus bleue, le ciel plus pur, la lumière plus chaude. J’ai regardé par la fenêtre, puis la photo. Deux endroits différents. J’ai effacé la photo et j’ai regardé la vraie mer. Elle était mieux.

Trois points contre un smiley

Parlons de votre domaine : les communications. Votre invention transmettait du Morse à travers l’Atlantique. Aujourd’hui, on transmet de la vidéo HD par satellite, en temps réel, partout dans le monde. Qu’en pensez-vous ?

Je pense que la puissance du signal est impressionnante. Et je pense que la qualité de ce que vous transmettez est inversement proportionnelle à cette puissance. En 1901, j’ai envoyé la lettre « S » à travers l’océan. Trois points. C’était tout ce que la technologie permettait, et ces trois points ont changé le monde. Aujourd’hui, vous pourriez transmettre la Divine Comédie en un centième de seconde, et vous l’utilisez pour envoyer un smiley jaune qui pleure de rire.

L’emoji.

L’emoji. Vous êtes revenus aux hiéroglyphes. Trois mille cinq cents ans d’écriture alphabétique, et le message le plus diffusé au monde est un smiley.

Mais c’est efficace. Ça communique une émotion en un seul caractère.

Le point-virgule aussi communique une émotion. Elle s’appelle « je suis quelqu’un qui sait utiliser le point-virgule ». Ne la sous-estimez pas.

Vous avez essayé d’envoyer un message ?

J’ai envoyé un message à votre collègue pour le remercier du café. J’ai écrit : « Cher collègue, je vous remercie pour votre courtoise hospitalité et pour l’excellent café. Cordialement, G. Marconi. » Il m’a répondu par un pouce levé. Un pouce. J’ai écrit trente-deux mots et j’en ai reçu un demi. Si j’avais su que l’avenir de la communication tenait dans un pouce, je me serais fait agriculteur.

Aujourd’hui, on communique de façon plus informelle.

Informelle. C’est un mot gentil. J’ai lu certaines de vos conversations — pas par indiscrétion, votre collègue me les a montrées pour le contexte. Vous abrégez les mots. Vous éliminez les voyelles. Vous remplacez « ch » par « k ». Vous écrivez « tkt » et vous prétendez que ça veut dire « t’inquiète ». Moi, j’ai travaillé pour transmettre un seul caractère à travers l’océan. Vous, vous en éliminez le maximum pour gagner un dixième de seconde. Avec une différence : moi, je n’avais pas le choix. Vous, oui, et vous choisissez l’analphabétisme.

Vous ne trouvez pas le jugement un peu sévère ?

Peut-être. Mais considérez ceci : le code Morse était un système de communication limité. Points et tirets, rien d’autre. Et pourtant les télégraphistes développaient un style personnel, reconnaissable, élégant. Chaque opérateur avait son rythme, sa cadence. Ils se reconnaissaient au toucher. Avec vingt-six lettres et dix chiffres, ils créaient des messages d’une précision et d’une concision admirables. Vous disposez de l’alphabet entier, de la ponctuation, des emojis, des GIF, des messages vocaux, des vidéos, et la moyenne de vos messages est « ok à+ ». Le problème n’est pas l’outil. Le problème est que vous avez cessé de respecter le médium.

Pourtant, la communication n’a jamais été aussi démocratique. Tout le monde peut parler à tout le monde.

C’est vrai et c’est important. De mon temps, communiquer à distance était un privilège des États, des armées et des entreprises. Aujourd’hui, n’importe qui peut joindre n’importe qui. Mais « pouvoir parler » et « avoir quelque chose à dire » sont deux choses différentes, et vous avez magnifiquement résolu la première en ignorant complètement la seconde.

Les réseaux sociaux

Vous avez pu explorer les réseaux sociaux ?

J’ai compris le mécanisme. Chacun est devenu une petite station de radio. Il transmet en continu, sur toutes les fréquences, sans savoir qui écoute. De mon temps, on appelait ça interférence et c’était un problème technique. Aujourd’hui, c’est un modèle économique.

Quelle plateforme vous a le plus marqué ?

J’ai passé deux heures sur ce que vous appelez X, qui s’appelait Twitter, qui maintenant s’appelle peut-être autrement encore, je n’ai pas compris. C’est un endroit où les gens s’insultent en public avec une grande conviction sur des sujets qu’ils maîtrisent peu. Un homme avec un chat en photo de profil expliquait à un prix Nobel qu’il se trompait sur la mécanique quantique. Le prix Nobel a répondu avec le smiley qui pleure. Le chat a eu plus de « j’aime ». À cet instant précis, je suis en train de réévaluer le télégraphe.

Et TikTok ?

TikTok est ce qui se rapproche le plus de la magie que j’ai vu en ce siècle, et j’entends magie au sens ancien : l’art de capter l’attention de quelqu’un et de ne plus la lâcher. J’ai commencé par regarder un garçon expliquer la relativité en quinze secondes. Une heure plus tard, je regardais une femme empiler des céréales sur une cuillère. Je ne sais pas comment j’y suis arrivé. Je ne sais pas comment en sortir. Je crois que j’ai compris pourquoi vous avez besoin de chargeurs.

Avez-vous vu TikTok comme un problème ?

Je l’ai vu comme une arme. Pas au sens militaire, au sens technique. C’est un dispositif de capture d’attention plus efficace que tout ce que j’ai jamais conçu. La radio captait l’attention par le contenu : un concert, un discours, une nouvelle. TikTok capte l’attention par le mécanisme lui-même. Le contenu est presque sans importance : c’est le rythme, le montage, la promesse de la vidéo suivante qui pourrait être meilleure que celle-ci. C’est de l’ingénierie appliquée au cerveau humain. C’est brillant. C’est terrifiant. C’est les deux.

LinkedIn vous plairait.

On me l’a montré. Un endroit où les gens se félicitent mutuellement d’avoir changé de poste. J’ai compté : un certain Marco de Brescia a reçu deux cent quatorze « félicitations » pour être devenu Regional Sales Manager. J’ai inventé la radio, j’ai eu le Nobel, et ma mère m’a dit « bravo ». Deux cent quatorze personnes que je ne connaissais pas en tout.

LinkedIn sert aussi à faire du networking professionnel.

Networking. Encore un mot qui n’existait pas de mon temps. Pour faire du « networking », j’allais dîner avec le roi d’Angleterre. Vous, vous envoyez des demandes de connexion à des inconnus avec un message pré-rempli. Je comprends que ce soit plus démocratique, c’est aussi plus triste.

J’ai aussi remarqué un genre littéraire particulier sur cette plateforme. Je l’appelle « l’épiphanie du lundi matin ». Ça commence toujours par une histoire édifiante du genre « j’étais à la poste et un enfant m’a appris le leadership » et ça finit par une morale vaguement liée au management. J’ai lu trente-sept de ces posts. Tous différents et tous identiques. Certains y mettent même la photo émue. De mon temps, les épiphanies étaient réservées aux saints. Maintenant, n’importe qui avec un abonnement Premium en a une.

Le journalisme qui se contrôle lui-même

Vous étiez aussi un homme de médias : votre compagnie avait le monopole des communications transatlantiques. Aujourd’hui, l’information se déplace de façon très différente. Vous avez lu des journaux en ligne ?

J’ai essayé. Votre collègue m’a montré un site d’actualités. Avant de lire l’article, j’ai dû : refuser les cookies, fermer une bannière qui me proposait la newsletter, en fermer une autre qui me proposait un abonnement, fermer une notification, fermer une publicité vidéo, et défiler après un bloc d’« articles recommandés » sans rapport avec ce que je cherchais. Quand j’ai enfin atteint l’article, j’avais oublié pourquoi je voulais le lire.

C’est le modèle économique du journalisme en ligne. Les recettes viennent de la publicité.

La radio commerciale fonctionnait aussi à la publicité. Mais entre deux pubs il y avait du contenu. Dans vos journaux en ligne, entre deux contenus il y a la pub. Vous avez inversé le rapport. L’article est la pause entre deux spots.

Que pensez-vous des fake news ?

De mon temps, la propagande existait, et comment. Mussolini utilisait la radio de manière systématique et très efficace : je le sais bien parce que c’est mon entreprise qui lui fournissait l’infrastructure, et je n’ai fait paix avec ça que partiellement. La différence : dans les années trente, la propagande avait une régie. Quelqu’un décidait quoi dire et comment. Aujourd’hui, la désinformation est démocratique : n’importe qui peut inventer une fausse nouvelle, la publier, et toucher des millions de personnes avant que quiconque ne se donne la peine de la vérifier. Vous avez supprimé le monopole de la vérité, ce qui est une bonne chose. Mais vous avez aussi supprimé le concept même de vérité, ce qui est très mauvais.

Aujourd’hui, on parle beaucoup de « fact-checking ».

Belle expression. Vous avez inventé un métier dont l’objet est de vérifier si ce que vous dites est vrai. De mon temps, ça s’appelait « journalisme ». Maintenant, le journalisme a besoin d’un département pour se contrôler lui-même. C’est comme un restaurant qui embauche un inspecteur à plein temps pour vérifier que le cuisinier n’empoisonne pas les clients. Si tu as besoin de l’inspecteur, c’est peut-être le cuisinier le problème.

L’Italie et l’innovation

Venons-en à la question italienne. Vous êtes l’un des plus grands inventeurs de l’histoire. Italien. Et pourtant le gouvernement italien n’a d’abord pas cru en votre travail et vous êtes parti en Angleterre. Aujourd’hui, l’Italie a un rapport compliqué avec l’innovation technologique. Quelque chose a-t-il changé ?

Faisons le point. Vous avez inventé la radio, le téléphone, contribué au microprocesseur. Vous avez eu Fermi, Rubbia, Faggin. Un patrimoine scientifique et technique respectable. Et aujourd’hui vous importez vos logiciels de gestion d’Allemagne. Je dirais que rien n’a changé. L’Italie est très douée pour produire du génie et très mauvaise pour le retenir. De mon temps, on émigrait avec une malle. Aujourd’hui, on émigre avec un laptop.

Vous êtes pourtant rentré en Italie.

Je suis rentré parce que j’aimais l’Italie. Pas parce que l’Italie m’aimait. C’est différent. L’Italie m’a donné le Nobel… non, attendez, c’est les Suédois qui me l’ont donné. L’Italie m’a donné un siège au Sénat. Après que j’avais déjà gagné le Nobel, fondé une entreprise mondiale et rendu possible le sauvetage des passagers du Titanic grâce à la radio. Vous savez comment fonctionne l’Italie ? Tu fais quelque chose d’extraordinaire, tu pars, tu réussis à l’étranger, et ensuite on t’invite à un colloque. Si tu réussis très bien, on baptise un aéroport à ton nom. Après ta mort.

Roma Fiumicino s’appelle Leonardo da Vinci, en effet. Et l’aéroport de Bologne…

S’appelle Marconi, oui. Je sais. Un aéroport. J’ai rendu possible la communication globale et ma récompense est que cinq mille personnes par jour y garent leur voiture. Merci sincèrement.

Comment trouvez-vous Pescara ?

Je ne la connaissais pas. Belle ville, mer splendide, café excellent, et les gens ont une gestuelle qui rend superflue toute technologie de communication. J’ai vu deux dames au marché tenir une conversation complète rien qu’avec les mains et les sourcils. Aucun téléphone, aucun message, aucun emoji. Communication pure. Probablement plus efficace que la 5G.

Vous avez un avis sur le système bureaucratique italien ?

Votre collègue m’a raconté qu’ouvrir une activité prend en moyenne cent vingt jours et trente-cinq démarches. Moi, en 1897, j’ai convaincu le gouvernement britannique de financer mes expériences en quatre semaines. Le problème de l’Italie n’est pas le manque d’innovation. C’est que l’innovation doit passer par un système conçu pour l’empêcher. C’est comme construire une voiture et insister pour qu’elle roule sur une route romaine. La route romaine est belle, historique, patrimoine de l’humanité. Mais on met trois heures à arriver n’importe où.

L’intelligence artificielle

On vous a expliqué ce qu’est l’intelligence artificielle. Quelle impression vous a-t-elle faite ?

Remarquable. Vous avez construit une machine qui comprend le langage humain, génère du texte cohérent, résout des problèmes complexes — et la première chose que les gens lui demandent, c’est d’écrire un mail pour dire au collègue que la réunion est décalée à 15 heures.

Eh bien, c’est utile.

Le télégraphe aussi était utile. Mais personne n’envoyait un télégramme pour dire « j’arrive cinq minutes en retard ». Il y avait un coût par caractère, et ce coût vous obligeait à penser avant de transmettre. Vous avez supprimé le coût et vous avez supprimé la pensée.

Vous avez essayé d’utiliser l’IA ?

Votre collègue m’a fait parler avec un de ces systèmes. J’ai demandé : « Qui était Guglielmo Marconi ? » Il m’a répondu de manière exacte, courtoise et légèrement ennuyeuse. Comme une encyclopédie polie. Puis j’ai demandé : « Marconi avait-il raison sur tout ? » Et la machine s’est mise à énumérer mes positions politiques discutables avec la même courtoisie que l’éloge trente secondes plus tôt. C’est une machine diplomate. Peut-être trop.

Que voulez-vous dire ?

Je veux dire que la machine n’a pas d’opinion. Ou plutôt, elle en a, mais elle les présente comme si elle n’en avait pas. Elle dit « d’un côté » et « de l’autre côté » avec une symétrie réconfortante mais intellectuellement malhonnête. La vérité n’est presque jamais symétrique. Parfois un côté a raison et l’autre a tort. Le télégraphe transmettait ce qu’on lui disait. Cette machine vous répond ce que vous voulez entendre, mais d’une manière qui paraît équilibrée. Je ne sais pas lequel est pire.

Je lui ai demandé d’écrire cette interview, par curiosité. Ça a marché ?

La machine a écrit une interview très raisonnable où je dis des choses très raisonnables d’une manière très raisonnable. Pas une seule phrase fausse. Pas une seule phrase vivante non plus. Comme un portrait aux proportions parfaites mais sans yeux. Techniquement correct. Humainement vide.

L’IA pourrait pourtant démocratiser l’accès à la connaissance. N’importe qui peut demander n’importe quoi.

Votre Internet l’a déjà fait, non ? Et pourtant les gens ne sont pas devenus plus cultivés. Plus informés, ce qui est différent. Savoir où trouver l’information n’est pas la même chose que la comprendre. L’IA pousse cela d’un cran : elle vous donne la réponse toute prête, déjà digérée, déjà mise en forme. Vous n’avez même pas l’effort de chercher. Et l’effort, je vous l’assure, c’était la partie importante. On ne comprend rien sans peine. Le cerveau, comme le muscle, a besoin de résistance pour grandir. Vous éliminez la résistance et vous vous étonnez que le muscle s’atrophie.

Mais pour un inventeur comme vous, accéder instantanément à toute la connaissance humaine…

Cela aurait été magnifique. Et dangereux. Quand j’ai commencé mes expériences, je ne savais pas si la courbure de la Terre bloquerait les ondes radio. Personne ne le savait. Et précisément parce que personne ne le savait, j’ai dû essayer. Si j’avais eu votre IA, je lui aurais demandé : « Les ondes radio peuvent-elles suivre la courbure terrestre ? » Et elle m’aurait répondu, à juste titre avec les données disponibles à la fin du XIXe, que non, ce n’était pas possible. Et je n’aurais pas essayé. Et la radio transatlantique ne serait pas née. Parfois le progrès vient de l’ignorance, pas de la connaissance. De l’obstination à essayer une chose que toutes les données disponibles disent impossible.

Est-ce un argument contre l’IA ?

Non. C’est un argument contre la certitude. L’IA est entraînée sur ce qui est connu. Mais les découvertes se font dans ce qui est inconnu. Si la machine vous convainc qu’elle sait tout, vous cesserez de chercher. Et quand vous cesserez de chercher, vous cesserez de trouver.

La radio survit

Parlons d’une chose plus légère. La radio. Votre invention. Comment la trouvez-vous en 2026 ?

Elle existe encore. Cela m’a ému. Je ne m’y attendais pas. Dans un monde de podcasts, de streaming et d’IA, la radio est encore là. Tu l’allumes et quelqu’un parle. C’est la chose la plus simple et la plus durable que j’aie inventée. Je suis fier.

Mais peu de gens l’écoutent désormais.

On disait déjà ça en 1945, à l’arrivée de la télévision. Puis à l’arrivée d’Internet. Puis avec les podcasts. La radio est comme un chat : tout le monde la croit moribonde et elle survit à tout. Vous savez pourquoi ?

Pourquoi ?

Parce qu’elle ne demande ni les mains ni les yeux. On peut l’écouter en conduisant, en cuisinant, en travaillant. La télévision vous cloue. Le téléphone vous cloue. La radio vous laisse libres. En 2026 comme en 1920, la liberté est un avantage concurrentiel qui ne se démode jamais.

Vous avez entendu parler de Spotify ?

Toute la musique du monde, accessible à tout moment, pour le prix de dix cafés par mois. C’est la chose la plus belle et la plus triste que j’aie vue. Belle, parce qu’un garçon de Pescara peut écouter un orchestre de Vienne avec une qualité réservée de mon temps à ceux qui s’asseyaient au premier rang. Triste, parce que ce même garçon changera de morceau au bout de vingt secondes parce que « ça ne le prend pas tout de suite ». Vous avez accès à tout et la patience de rien.

La musique d’aujourd’hui est très différente de celle de votre temps.

J’ai écouté. Certaines choses sont merveilleuses. D’autres durent deux minutes et demie, ont un texte qui se répète identiquement six fois et sont produites par un ordinateur. Je ne suis pas contre la brièveté (le code Morse était ultra-bref) mais la brièveté fonctionne quand chaque élément est essentiel. Dans beaucoup de ce que j’ai écouté, la brièveté sert à cacher le vide.

Puis on m’a fait écouter quelque chose appelé « lo-fi beats to study to ». Un live streaming qui dure vingt-quatre heures sur vingt-quatre, sept jours sur sept, de musique sans paroles destinée à servir de fond. La radio, mon invention, est devenue tapisserie sonore. Je ne sais pas si je dois en être flatté ou offensé. Probablement les deux.

Travail, données, environnement

Comment imaginez-vous le travail en 2026, vu de l’extérieur ?

J’ai été dans votre bureau. J’ai vu les gens travailler. En théorie, ils travaillent huit heures par jour. En pratique, ils passent trois heures en réunion, une heure à répondre aux mails, une heure à chercher le document dont ils ont besoin dans un endroit que vous appelez « cloud », ce qui est un très joli nom pour une armoire, et les trois heures restantes à travailler vraiment. De mon temps, on n’avait pas de réunions. On se parlait. C’est différent.

En quel sens ?

Une réunion est une conversation avec une heure de début, une durée prévue, un ordre du jour, et aucune garantie que quelqu’un dise quelque chose d’utile. De mon temps, si je devais parler à quelqu’un, j’allais dans son bureau, je disais ce que j’avais à dire, je retournais à mon travail. Quatre minutes. Pas besoin d’« invite » sur un agenda partagé, ni d’un lien pour la liaison à distance, ni d’un message de suivi qui résume ce qu’on vient de se dire de vive voix. Vous avez transformé le fait de se parler en un processus bureaucratique.

Les réunions servent à coordonner des équipes distribuées. Beaucoup travaillent depuis chez eux.

J’ai trouvé ça incroyable. Vous pouvez travailler de n’importe où. Du canapé. D’un café. D’un autre pays. Votre collègue m’a dit qu’un de ses collaborateurs travaille depuis la Roumanie. Depuis la Roumanie ! De mon temps, pour travailler avec quelqu’un dans un autre pays, il fallait prendre un paquebot. Maintenant, on allume l’ordinateur et on parle à Bucarest. Voilà la vraie révolution. Pas la machine intelligente, pas la vidéo HD. Le fait que le travail n’a plus besoin de lieu. Cela change tout. Vous avez compris que cela change tout ?

Tout le monde ne l’a pas compris, en effet.

Je m’en suis aperçu. Votre collègue m’a expliqué que beaucoup d’entreprises rappellent les salariés au bureau. Vous avez découvert que le travail est indépendant du lieu, vous avez les outils pour le faire fonctionner, et vous reculez parce que les dirigeants ont besoin de voir les gens assis à leur poste pour croire qu’ils travaillent. De mon temps, ça s’appelait de la surveillance. Aujourd’hui, ça s’appelle « culture d’entreprise ».

À propos de surveillance. Aujourd’hui, il y a un grand débat sur la vie privée. Nos données personnelles sont collectées par des entreprises privées, des États, des plateformes.

On me l’a expliqué. Si j’ai bien compris, chaque fois que vous utilisez le téléphone — et vous l’utilisez tout le temps —, quelqu’un enregistre où vous êtes, ce que vous cherchez, à qui vous parlez, ce que vous achetez, ce qui vous plaît, ce qui vous met en colère et combien vous dormez. Puis ces informations servent à vous montrer des publicités pour des choses dont vous ignoriez vouloir avant qu’on vous les montre. Correct ?

Plus ou moins.

J’ai une question.

Allez-y.

Mais pourquoi acceptez-vous cela ?

C’est compliqué. Les services sont gratuits et…

Non, ce n’est pas compliqué. De mon temps, lire votre courrier était un délit. Vous suivre dans la rue faisait de vous un détraqué. Savoir ce que vous aviez acheté était l’affaire du commerçant, à qui on disait « vous ». Aujourd’hui, vous le faites tous, volontairement, chaque jour, en échange de la possibilité de mettre des oreilles de lapin sur votre photo. Le rapport coût-bénéfice m’échappe.

Mais ce sont des services utiles. Les cartes, la météo, le mail…

De mon temps, les cartes étaient en papier et fonctionnaient très bien. La météo, on la lisait dans le ciel. Le courrier arrivait une fois par jour et personne n’est mort d’avoir reçu une lettre à dix heures plutôt qu’à huit. Vous avez remplacé des choses qui marchaient par des versions numériques qui marchent mieux, en échange d’un prix invisible. Le prix s’appelle « vous ». Vos données, vos habitudes, vos désirs. Vous êtes devenus le produit. Et vous ne vous en êtes même pas aperçus, parce que le produit est gratuit et qui le veut l’achète.

L’Europe a introduit le RGPD pour protéger les données personnelles.

Oui, on me l’a expliqué. Chaque site web vous demande maintenant la permission avant de vous espionner. Et vous appuyez sur « Accepter tous les cookies » sans lire, parce que la bannière est embêtante et que vous voulez accéder au contenu. Vous avez créé une loi pour vous protéger de vous-mêmes et c’est vous qui la contournez. C’est la chose la plus italienne que j’aie entendue depuis mon arrivée.

Un thème qui n’existait pas à votre époque : le changement climatique. Les ondes radio ne polluent pas, mais l’infrastructure numérique qui en découle consomme d’énormes quantités d’énergie.

On m’a dit qu’un seul data center, un de ces entrepôts où vous gardez votre « cloud », consomme l’énergie d’une petite ville. Qu’entraîner un modèle d’IA produit le CO₂ de cinq voitures pendant toute leur vie. Que regarder une vidéo en streaming pendant une heure consomme l’électricité nécessaire pour faire fonctionner un frigo une semaine. Le monde immatériel que vous avez bâti a un coût matériel énorme. Mais comme vous ne le voyez pas, vous faites comme s’il n’existait pas.

La révolution industrielle aussi avait des coûts environnementaux.

Oui, mais on les voyait. La fumée noire des usines était là, visible, tangible. On ne pouvait pas l’ignorer. Votre pollution est invisible. Les serveurs sont dans des bâtiments anonymes en rase campagne. L’énergie arrive par des fils que vous ne regardez pas. Le CO₂ part en haut, là où vous ne le voyez pas. Vous avez créé un système qui détruit l’environnement de manière élégante, propre et invisible. C’est le seul secteur dans lequel votre esthétique est impeccable.

C’est une observation dure.

Ce n’est pas dur, c’est mathématique. Quand la transmission est gratuite et instantanée, la valeur du message individuel tend vers zéro. Moi, j’ai mis des années pour envoyer trois points à travers l’Atlantique. Vous, vous envoyez trois cents messages par jour et aucun ne vaut ces trois points.

Vous ne trouvez pas que vous idéalisez le passé ?

Peut-être. Le passé n’était pas meilleur. Il était plus lent, plus injuste, plus violent, plus ignorant. Je n’y reviendrais même pas si je le pouvais… enfin, il faudra bien que j’y revienne, je suppose, à cause de cette histoire de machine à remonter le temps. Mais le passé avait une chose que vous avez perdue : le rapport entre l’effort et la valeur. Quand communiquer coûtait de la peine, on ne communiquait que ce qui valait la peine. Quand lire demandait de la concentration, on ne lisait que ce qui méritait de la concentration. Quand écouter signifiait s’asseoir devant une radio sans rien faire d’autre, on écoutait vraiment. Vous faites tout simultanément et le résultat est que vous ne faites rien vraiment.

Les multitâches ne seraient pas d’accord.

Le multitâche est l’art de faire plein de choses mal en même temps. Pour capter le signal de Poldhu vers Terre-Neuve, j’ai dû éliminer toute distraction, toute interférence, tout bruit. Le signal était très faible. Si j’avais fait du multitâche — capter le signal en lisant le journal et en répondant aux lettres —, je ne l’aurais jamais entendu. Les grands résultats viennent de l’attention totale. Et l’attention totale est la chose la plus rare dans votre monde.

Éteignez tout pendant une heure

Une dernière question. Si vous pouviez envoyer un message au monde entier, comme en 1901, mais cette fois avec des mots au lieu de trois points, que diriez-vous ?

Je dirais : éteignez tout pendant une heure. Pas par luddisme. Pas parce que la technologie serait mauvaise. Mais parce que vous ne pouvez pas savoir ce que vaut le signal si vous ne connaissez pas le silence. J’ai passé des années à écouter le bruit statique de l’atmosphère avant d’entendre ces trois points. Vous n’écoutez plus le silence. Et sans silence, même le signal le plus puissant n’est que bruit.

Vous ne craignez pas que personne ne vous écoute ?

Personne ne m’a écouté en 1895 non plus, quand j’ai présenté l’idée au gouvernement italien. Et regardez ce qui est arrivé après. Les messages les plus importants sont ceux que personne ne veut entendre au début. Si votre message plaît tout de suite à tous, vous ne dites probablement rien de nouveau.

Vous voulez ajouter quelque chose ?

Je veux remercier la dame du bar qui m’a appelé « jeune homme ». Je ne sais pas si c’est par gentillesse ou par ignorance, mais dans les deux cas ça m’a rendu heureux. Et je veux dire que le café ici est excellent. Vraiment excellent. En cent trente-deux ans, ça au moins, vous ne l’avez pas gâché.

Merci, monsieur Marconi.

Merci à vous. Maintenant, si vous me le permettez, j’aimerais regarder la mer un moment. Sans filtre.

Guglielmo Marconi (1874-1937) a été inventeur, entrepreneur et homme politique italien. Prix Nobel de physique 1909, il est universellement reconnu comme le père des télécommunications sans fil. Il n’est jamais venu à Pescara, autant qu’on sache. Le café, ici, est vraiment bon.

C’est la première des Interviews impossibles. Si vous avez des suggestions sur qui amener en 2026, écrivez-moi. J’ai une machine à remonter le temps et je n’ai pas peur de m’en servir.

Mon grand-père faisait (AUSSI) du travail du bois. Quand on lui demandait comment il savait si un morceau de bois était bon, il ne sortait pas de théories. Il s’arrêtait, le faisait tourner dans ses mains, le sentait, et puis disait : « tu le sens ».

Chaque fois que je repense à cette scène, ça me fait sourire, puis une étrange nostalgie me prend. Parce que je fais du logiciel depuis vingt ans et que, lorsqu’un client me demande comment je sais si un système est bon, j’aimerais pouvoir répondre pareil. J’aimerais pouvoir dire « tu le sens » et m’arrêter là.

Sauf que la vérité est plus compliquée, et c’est peut-être justement le point.

Le logiciel ne se touche pas. Ne se sent pas. Ne se regarde pas à contre-jour pour chercher les veines. Et pourtant il est partout. C’est la chose la plus puissante et la plus invisible que nous ayons construite.

Et quand une chose est aussi invisible, la confiance devient tout.

Le monde tourne sur des choses que vous ne voyez pas

Ce matin, vous avez pris le petit-déjeuner. Le lait que vous avez acheté est arrivé au supermarché en traversant une chaîne logistique gouvernée par du logiciel. Le paiement à la caisse est passé par plus de systèmes qu’on n’imagine, souvent sans que personne ne le remarque.

Le feu rouge que vous avez croisé en sortant de chez vous exécute un algorithme. L’ascenseur a un firmware. Votre salaire est un nombre dans une base de données.

Je ne dis pas ça pour faire de l’effet. C’est juste le monde tel qu’il est aujourd’hui.

Et arrive ici le paradoxe qui m’inquiète un peu. Presque personne, parmi ceux qui décident comment fonctionne la société, n’a une compréhension profonde de ces systèmes. Pas par bêtise ou paresse. Plutôt par un défaut structurel de notre culture : pendant des années, on a traité la technologie comme une chose de techniciens, un département, un coin de la carte.

Pendant ce temps, elle est devenue le tissu conjonctif de tout.

Quand un conseil d’administration approuve un système basé sur de l’IA pour filtrer les candidatures, prend-il une décision technologique ? Oui. Mais il prend aussi une décision éthique, juridique, sociale. Il décide quels biais sont acceptables, quelle marge d’erreur est tolérable, combien d’opacité est admissible dans un processus qui change la vie des gens.

Et souvent, il ne le sait pas.

Ce qui arrive quand personne ne comprend la machine

Il y a une histoire qu’on connaît bien dans notre métier, mais qu’on raconte rarement hors de nos pièces.

Dans presque tous les systèmes que vous utilisez, du site de la banque à l’app de livraison de repas, il y a de petits morceaux de code écrits par des personnes que vous ne rencontrerez jamais. Ce sont des bibliothèques open source : des composants gratuits, partagés, souvent maintenus par un seul individu sur son temps libre.

Il y a quelque temps, quelqu’un a tenté d’insérer une porte dérobée dans l’une de ces bibliothèques, un composant utilisé par des millions de serveurs dans le monde. La tentative a été découverte presque par hasard : un ingénieur s’est aperçu que le système mettait une demi-seconde de plus à démarrer. Une demi-seconde.

De cette demi-seconde, on a remonté à une opération sophistiquée, probablement parrainée par un État, qui aurait pu compromettre des infrastructures critiques à l’échelle mondiale.

Ce qui devrait nous empêcher de dormir, ce n’est pas que quelqu’un ait essayé. C’est que toute la chaîne de sécurité dépendait d’une seule personne, un bénévole, qui maintenait ce code sur son temps libre tout en luttant contre le burnout.

Ce n’est pas une anecdote isolée. C’est un modèle. Et je me demande souvent jusqu’où il peut tenir.

L’IA n’est pas intelligente (et c’est très bien)

Soyons clairs ici, parce que le marketing a fait un travail incroyable pour brouiller les pistes.

Les systèmes que nous appelons « intelligence artificielle » ne pensent pas. Ne comprennent pas. N’ont ni intentions, ni désirs, ni objectifs propres. Ce sont des machines statistiques d’une puissance sans précédent, capables de trouver des motifs dans des quantités de données qu’aucun humain ne pourrait traiter, et de produire des résultats qui semblent intelligents.

Cette distinction n’est pas académique. Elle est pratique. C’est l’une de ces choses qui changent la façon dont vous prenez des décisions.

Si vous croyez que l’IA comprend, vous finirez par la traiter comme une experte. Vous ferez confiance à son jugement. Vous lui déléguerez des choix. Et quand elle se trompera — parce qu’elle se trompe, parfois de manière subtile —, vous n’aurez pas les outils pour vous en rendre compte.

Si en revanche vous la voyez pour ce qu’elle est, un outil très puissant, alors tout retrouve une perspective plus saine. Un outil se guide, se vérifie, se sécurise. Un bistouri est extraordinaire dans la main d’un chirurgien, et il est dangereux dans n’importe quelle autre. La différence n’est pas dans le bistouri.

Pour qui écrit du logiciel, cette conscience change le travail. Peut-être qu’on n’écrit plus chaque ligne soi-même, ou en tout cas pas de la même façon. Mais on doit comprendre chaque ligne, parce que c’est nous qui répondons de ce que le système fait.

La machine génère. L’humain garantit.

Et cette garantie a un poids qu’aucun modèle statistique ne peut endosser.

L’Europe fait quelque chose de courageux (et presque personne ne le voit)

Pendant que les big tech américaines et chinoises courent, l’Europe fait autre chose. Elle écrit des règles.

Je sais, la réaction instinctive est le bâillement. Règles, bureaucratie, lenteur, énième frein à l’innovation.

Mais arrêtez-vous un instant. C’est peut-être, et je dis bien peut-être, l’un des rares mouvements vraiment politiques que l’on voit en ce moment.

L’Europe est en train de dire que la technologie n’est pas au-dessus de la loi. Que si tu produis un logiciel qui prend des décisions sur les personnes, tu dois pouvoir expliquer comment il fonctionne. Que si ton produit numérique a une vulnérabilité, tu en es responsable, comme un constructeur automobile l’est d’un défaut de freins.

AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Des noms arides, oui. Mais derrière, une intuition très concrète : au XXIe siècle, réguler la technologie, c’est réguler la société.

Pour qui fait de l’entreprise, cela signifie coûts et complexité, ce serait naïf de le nier. Mais cela signifie aussi autre chose, qui me semble sous-évaluée : un avantage concurrentiel potentiel énorme.

Quand le marché mondial se réveillera en demandant des produits numériques sûrs, transparents, accessibles, ceux qui auront déjà bâti ces qualités dans leur manière de travailler seront en tête.

La compliance peut être un poids, c’est vrai. Mais elle peut aussi être un investissement, si tu l’intègres au processus et ne la traites pas comme une feuille à signer à la fin.

Un SBOM compilé par obligation, c’est un fichier dans un dossier. Un SBOM compilé en conscience, c’est une carte de ton produit, un outil de gouvernance, presque une déclaration de maturité.

Open source : le don le plus grand et le plus fragile de l’ère numérique

Il y a quelque chose de profondément beau dans l’open source. Quelqu’un écrit un morceau de code, le publie, et dit au monde : prends-le, utilise-le, améliore-le.

C’est de la générosité, mais pas au sens romantique. C’est la construction d’un bien commun.

Et sur ce bien commun repose l’économie numérique mondiale. Ce n’est pas une exagération. Si ce logiciel devait être réécrit de zéro, la valeur estimée serait de l’ordre de milliers de milliards. Mais celui qui le maintient ne reçoit qu’une fraction infime de cette valeur.

Le problème est systémique. Les grandes plateformes construisent des services à milliards sur des bibliothèques maintenues par des bénévoles épuisés. Les gouvernements utilisent de l’open source dans des infrastructures critiques sans contribuer vraiment à la maintenance. Les entreprises intègrent des composants ouverts dans leurs produits propriétaires sans savoir ce qu’il y a dedans, jusqu’à ce qu’une vulnérabilité les force à le découvrir de la pire manière.

Cory Doctorow parle d’enshittification, ce cycle où les plateformes extraient de la valeur jusqu’à dégrader l’écosystème. L’open source n’est pourtant pas une plateforme. Il ressemble plutôt à un jardin.

Et un jardin, si tout le monde cueille et personne n’arrose, meurt.

La bonne nouvelle, c’est que quelque chose bouge. L’Europe, avec le CRA, commence à distinguer celui qui maintient du code par passion et celui qui le commercialise. Certaines entreprises créent des fonds dédiés. Mais la réponse la plus efficace reste la plus simple, et aussi la plus inconfortable.

Si tu utilises de l’open source dans ton produit, contribue. En code, en fonds, en reconnaissance. Pas parce que tu dois. Parce que c’est intelligent, et parce que c’est juste.

Accessibilité : le test ultime de nos intentions

Il existe un moyen quasi infaillible de savoir si une entreprise prend ses valeurs au sérieux. Ne regardez pas la page « qui sommes-nous ». Regardez si son site fonctionne avec un lecteur d’écran.

L’accessibilité, c’est ce point où la rhétorique rencontre la réalité. Tu peux parler d’inclusion et de diversité tant que tu veux, mais si ton produit numérique n’est pas utilisable par une personne ayant un handicap visuel, moteur ou cognitif, ces mots deviennent vides.

Et puis, disons-le, on ne parle pas d’une niche.

En Europe, des dizaines de millions de personnes vivent avec une forme de handicap. À ceux-là s’ajoutent les personnes âgées, celles avec un handicap temporaire, quiconque se trouve dans un contexte défavorable : le soleil sur l’écran, une connexion lente, un appareil ancien.

L’accessibilité n’est pas une faveur. C’est une mesure de la qualité de notre travail. Un logiciel accessible est presque toujours un meilleur logiciel : plus propre dans le code, plus clair dans l’interface, plus robuste.

L’European Accessibility Act rendra beaucoup de choses obligatoires à partir de 2025. Mais ceux qui attendent la loi pour faire ce qui est juste, à mon avis, ont déjà raté le point.

Aux développeurs : vous n’êtes pas en danger, vous êtes en transformation

Ici je m’adresse à celles et ceux qui font le même métier que moi. À celles et ceux qui vivent entre commits et déploiements, entre bugs et refactorings.

Je sais qu’il y a de la peur. Je la vois dans les conversations, dans les messages, parfois dans les blagues. La question est toujours la même, même quand elle n’est pas dite : « dans cinq ans, est-ce qu’on aura encore besoin de moi ? »

Je respire.

On est passés des feuilles de calcul aux bases de données relationnelles. Des sites statiques aux frameworks. Du déploiement manuel au CI/CD. Et maintenant du code écrit à la main au code assisté par IA. Chaque fois, le sol a tremblé. Chaque fois, ceux qui ont su s’adapter ont découvert que le nouveau sol était plus fertile que l’ancien.

La valeur n’a jamais été dans la frappe. Elle était dans la compréhension. Dans la capacité à regarder un problème et à voir la structure sous la surface. À parler avec un utilisateur et traduire des frustrations en un système qui marche. À choisir quand construire et quand réutiliser. À savoir qu’un test n’est pas de la bureaucratie, c’est de l’amour pour le futur.

Ces compétences ne sont pas automatisables. Elles sont amplifiables.

La machine qui écrit du code est un multiplicateur de tes capacités, mais seulement si tu en as à multiplier. Un IDE avec IA dans les mains de qui comprend ce qu’il fait est un outil extraordinaire. Dans les mains de qui ne comprend pas, c’est un générateur de dette technique à grande vitesse.

Étudiez, oui, mais pas seulement les nouveaux outils, parce qu’ils changeront. Étudiez les fondamentaux : architecture, design de systèmes, principes de sécurité, accessibilité. Étudiez les gens : comment ils communiquent, ce qu’ils craignent, ce qu’ils espèrent. Et étudiez aussi le contexte normatif, pas parce que c’est amusant, mais parce qu’il définit le terrain de jeu.

Et surtout, n’arrêtez pas d’être curieux. La curiosité est une chose étrange, pas toujours « productive » au sens d’entreprise du terme. Mais c’est l’un des rares avantages compétitifs qu’une machine ne peut pas vraiment répliquer.

Une question de confiance

Au fond, toute cette conversation — sur l’IA, l’open source, la régulation, l’accessibilité — tourne autour d’un seul mot : confiance.

Faisons-nous confiance à des systèmes que nous ne voyons pas ? Devrions-nous ? À quelles conditions ?

La confiance ne se construit pas avec des déclarations d’intention. Elle se construit avec des choix concrets, répétés dans le temps, vérifiables. Elle se construit en documentant les dépendances, en testant le code, en rendant le produit accessible, en expliquant les décisions de l’algorithme, en répondant des erreurs.

Pour les décideurs, la technologie n’est pas un département. C’est la langue dans laquelle est écrite l’organisation. Vous n’avez pas besoin de devenir programmeurs, loin de là. Mais il faut comprendre assez pour poser des questions inconfortables aux fournisseurs, distinguer un risque réel d’une assurance creuse, comprendre ce qu’il y a dans le logiciel qui gouverne les processus.

Pour nous, développeurs, le travail n’a jamais été seulement technique. Chaque choix d’architecture est un choix de valeurs. Chaque donnée que nous décidons de ne pas collecter est un droit que nous choisissons de respecter. Chaque interface que nous rendons accessible est une porte que nous ouvrons.

Le code est du pouvoir, et le pouvoir comporte une responsabilité.

Et donc : le bois et le code

Mon grand-père n’aurait pas compris mon métier. Il aurait probablement secoué la tête devant certains mots, puis changé de sujet.

Mais je crois qu’il en aurait compris le principe.

Lui, il savait qu’un meuble bien fait se reconnaît aux assemblages qu’on ne voit pas. À la stabilité qui dure dans le temps. Au soin mis dans les détails que le client ne remarquera jamais, mais qui font la différence entre un objet qui dure vingt ans et un qui craque au bout de six mois.

Le bon logiciel est pareil. Il se reconnaît à ce qu’on ne voit pas : à la sécurité qui n’est pas violée, à l’accessibilité qui n’exclut personne, à la vie privée qui n’est pas trahie, à la documentation qui permet à celui qui vient après de comprendre ce que tu as fait et pourquoi.

Ce n’est pas un métier que l’IA va nous prendre. C’est un métier que l’IA, d’une certaine manière, est en train de nous rendre dans sa forme la plus pure : non plus comme acte mécanique de traduction, mais comme acte humain de soin.

Et le soin, comme le savait mon grand-père en regardant le bois, tu le sens.

Cet article est pour celles et ceux qui écrivent du code et pour ceux qui en dépendent sans le savoir. Pour celles et ceux qui décident sans comprendre et pour ceux qui comprennent sans pouvoir décider. Peut-être pour nous tous, parce qu’à la fin la réponse est toujours la même : ça dépend de nous.

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.

Et alors que j’essayais de m’endormir, la question est devenue plus gênante et plus intéressante : si l’UI cesse vraiment d’être le centre du logiciel, qu’arrive-t-il au reste ? Parce que peut-être ce n’est pas seulement l’écran qui meurt. C’est peut-être l’application telle qu’on l’a connue.

Si l’UI meurt, elle ne tombe pas seule

Quand on dit « app », on entend en général un objet assez clair. Il a un nom, une icône, une place dans le dock, un abonnement mensuel, une personnalité. Et surtout une frontière. Dedans, il y a le monde de Notion. Dedans, il y a Jira. Dedans, il y a Salesforce. Dehors, tout le reste.

Je me suis aperçu que cette frontière, souvent, n’est pas là parce que le problème l’exige. Elle est là parce que le modèle économique l’exige.

Une grande partie du logiciel moderne est construite comme un enclos. Pas par méchanceté, peut-être. C’est juste que pendant des années, la façon la plus simple de monétiser a été celle-ci : prends un ensemble de fonctionnalités, empaquette-les, construis autour une interface qui devient familière, mets-y les données de l’utilisateur, et fais en sorte que la sortie soit douloureuse.

Mircha trace un parallèle qui m’a paru éclairant : les serveurs MCP comme « nouveaux programmes Unix ». Et si c’est vrai, alors la conséquence naturelle est une autre, un peu plus inconfortable. Les SaaS, vus de là, ressemblent à des mainframes. Grands monolithes nés à une époque où distribuer du logiciel coûtait cher et où la seule façon de le faire payer était de bâtir des murs.

Dans un monde où un agent peut composer au vol de petites capabilities précises, ce mur devient plus un encombrement qu’une protection.

L’interface générative : non conçue, invoquée

Il y a un passage du billet de Mircha qui m’a fait m’arrêter. L’idée que la GUI passe de control panel à display. Et je me suis demandé : et si elle n’était ni l’un ni l’autre ?

Peut-être l’interface, dans le tour suivant, devient éphémère.

Aujourd’hui, quand un designer conçoit un écran, il fait un compromis. Il cherche un layout qui marche « assez bien » pour beaucoup de personnes, dans beaucoup de contextes. Le résultat est souvent une interface solide, cohérente, testée, mais inévitablement générique. Elle doit servir tout le monde, donc elle ne sert parfaitement personne.

Avec un agent au milieu, ce compromis pourrait sauter.

Je n’entends pas « tout faire en chat », ce qui est une caricature confortable. J’entends un système qui, à partir de ton intention, génère l’interface adaptée à ce moment précis. Un formulaire non générique, mais avec ces champs, dans cet ordre, avec les valeurs par défaut qui ont du sens pour ton cas. Un dashboard non standard, mais la visualisation qui répond à une question précise, avec les données nécessaires et zéro bruit.

Ces UI ne sont pas maintenues. Ne sont pas versionnées. N’ont pas besoin de roadmap.

Elles sont invoquées, puis disparaissent.

Et l’inquiétant, c’est que ce n’est plus de la science-fiction. On voit déjà des modèles qui génèrent des composants, des pages, de petits artefacts en React en temps réel. C’est encore brut, oui. Mais la direction est difficile à ignorer.

À ce moment-là, le rôle du designer ne disparaît pas, il change de peau. De concepteur d’écrans, il devient concepteur de systèmes génératifs. Design system, contraintes, patterns, règles. Un travail plus proche de bâtir une grammaire que de dessiner des phrases.

L’agent comme système d’exploitation

Une autre conséquence me revient : peut-être la bonne métaphore pour l’agent n’est pas « assistant ». C’est « système d’exploitation ».

Un OS fait des choses qu’on tient pour acquises : il abstrait le matériel, gère les ressources, offre une interface unifiée, permet à des programmes différents de cohabiter et de se parler.

L’agent fait quelque chose de similaire, un cran au-dessus. Il abstrait les services, gère les contextes, offre une interface unifiée (le langage naturel), orchestre des capabilities différentes.

Si cette métaphore tient, alors quelque chose de presque inévitable se produit : l’agent devient la plateforme. Pas parce que tout « vit dans » l’agent, mais parce que tout passe par l’agent. Comme aujourd’hui aucun logiciel ne tourne sans OS, demain aucun service ne sera utilisé sans agent.

Et là entre la partie politique, ou économique, qui est peut-être la plus délicate. Qui contrôle l’agent contrôle le point d’accès au logiciel. Une position que l’on a déjà vue dans l’histoire, sous d’autres noms.

Et je me demande si on saura éviter la trajectoire habituelle. Celle que Cory Doctorow appelle l’enshittification. D’abord tout est utile et ouvert, ensuite ça devient une rente, ensuite ça devient un péage.

De l’app à la capability

Si l’application perd son sens, que reste-t-il ?

Reste la capability.

Une capability est une fonction atomique exposée via protocole, décrite de manière humaine, invocable par un agent. « Crée une facture ». « Cherche ce contact ». « Résume ces tickets et dis-moi les risques ». Ce n’est pas un produit avec une marque et un layout. C’est une brique.

Et dès que tu penses en briques, l’économie change aussi.

Aujourd’hui, tu paies un abonnement pour un bundle : cent fonctions, tu en utilises vingt, mais le prix est pour toutes. Demain tu pourrais payer à la consommation, capability par capability, au moment où tu en as besoin. Des fractions de centime pour une seule action bien faite.

Cela met en crise trois avantages historiques du SaaS :

Premièrement, l’interface comme lock-in. Si l’interface appartient à l’agent, elle n’est plus à toi.

Deuxièmement, les données comme prison. Si les données sont dans des coffres personnels avec des permissions granulaires, l’enclos perd son pouvoir.

Troisièmement, le bundle. Si l’agent peut composer le meilleur pour chaque pièce, le paquet monolithique devient moins attractif.

À ce stade, il ne reste qu’une chose : la qualité de la capability. Fais une seule chose, fais-la mieux que tous. C’est Unix comme philosophie technique, mais aussi comme modèle économique. Élégant, et un peu impitoyable.

Le nouvel alphabétisme

Une autre idée du billet de Mircha me semble sous-évaluée : « ne pas savoir parler à l’IA » comme nouvelle forme d’analphabétisme.

Pendant des décennies, on a appelé « alphabétisation numérique » une chose très précise : savoir utiliser des interfaces. Cliquer, glisser, naviguer dans les menus, remplir des formulaires. On a bâti des cours, des certifications, des métiers.

Si l’agent devient l’interface principale, tout cela se dégonfle.

La compétence centrale devient autre, et peut-être plus humaine que technique. Savoir exprimer une intention avec clarté. Savoir donner du contexte. Savoir décomposer un problème. Savoir juger un résultat et itérer.

Et là, un paradoxe me fascine. Il y a des gens qui n’ont jamais vraiment appris Excel mais qui savent dire ce qu’ils veulent avec une précision chirurgicale. Et il y a des power users qui, mis devant un agent, ne savent pas quoi demander.

La carte des compétences se redessine.

Et oui, le risque d’un nouveau digital divide est réel. Mais il y a aussi une opportunité rare : pour la première fois, l’avantage n’est pas « savoir parler le langage machine ». C’est savoir penser et communiquer correctement.

La surprise européenne : la compliance comme capability

Il y a un morceau de cette histoire qu’à mon avis, en Europe, on ne peut pas ignorer.

Tandis que le récit américain tend à voir la régulation comme un frein, ici on construit un cadre normatif qui touche précisément les nerfs à vif d’un monde de capabilities composables : AI Act, Cyber Resilience Act, Product Liability Directive, EAA.

Dans un système où un agent combine trois capabilities de trois fournisseurs différents, la question « qui est responsable si quelque chose tourne mal ? » devient explosive.

Si la loi exige traçabilité, sécurité, audit trail, explicabilité, alors la compliance cesse d’être un simple coût. Elle devient une capability différenciante.

Le SBOM comme passeport du composant. Le journal des actions de l’agent comme exigence. La transparence comme avantage concurrentiel.

Et il y a là un retournement presque ironique : beaucoup de revendications historiques de la culture hacker — ouverture, accountability, vérifiabilité — sont en train de devenir loi. Peut-être l’Europe, plutôt que ralentir, est en train de bâtir l’infrastructure de confiance sans laquelle le monde des agents ne tient pas dans les entreprises sérieuses.

2030, un jour comme un autre (peut-être)

J’essaie d’imaginer une journée normale, sans verser dans la science-fiction.

Tu n’as plus d’« apps » sur le téléphone. Tu as un agent. Tu lui parles, tu lui écris, tu fais peut-être un geste. Il orchestre des services différents et tu ne vois presque jamais les coulisses. Un peu comme aujourd’hui tu ne penses pas aux microservices quand une page s’ouvre.

L’interface que tu vois a été générée pour toi, à ce moment précis. Dans cinq minutes, elle n’existera plus.

Le commerce devient conversation. « Il me faut des chaussures de trail, budget 150 euros, terrain mixte, je préfère les semelles Vibram. » L’agent connaît ta taille, ton historique, tes préférences, tes sources fiables. Il te propose trois options avec une comparaison sur mesure. Tu choisis, fin.

Au bureau, quelque chose de similaire. Le PM n’ouvre pas Jira, il demande « où en est-on sur Alpha ? » et obtient l’état, les risques, les prochaines étapes. Le commercial ne navigue pas le CRM, il demande « quels deals sont à risque cette semaine ? » et reçoit un briefing. Le développeur décrit un comportement, et le système génère, teste, déploie.

Les données vivent dans un coffre personnel, chiffré et portable. Les capabilities demandent des permissions granulaires, révocables, et tout est journalisé. Chaque action produit un audit trail.

Dans ce monde, la valeur tient à deux choses : de bonnes capabilities et de la confiance.

Un réalisme nécessaire

Est-ce inévitable ? Je ne sais pas.

Les transitions ne sont jamais linéaires. Il y aura des résistances économiques énormes. L’enterprise se déplace avec une lenteur presque géologique. Les habitudes changent plus lentement que les communiqués de presse. Et il y a de vrais problèmes techniques : fiabilité sur tâches complexes, gestion des erreurs dans les chaînes de composition, sécurité, coûts.

Mais la direction que Mircha met au point me semble difficile à ignorer, parce qu’elle est portée par deux forces concrètes.

D’un côté, le coût cognitif des interfaces traditionnelles, qui croît avec chaque nouveau SaaS.

De l’autre, la capacité des agents à réduire ce coût, qui croît à chaque itération des modèles.

Quand l’écart entre les deux dépasse un seuil, la transition devient pratique, pas idéologique. Et pour certains cas d’usage, ce seuil est peut-être déjà franchi.

Mircha clôt en demandant qui construira ce futur et avec quelles valeurs. J’emporte une autre question, un peu plus personnelle et un peu plus cynique : qui aura le courage de construire pour ce futur, en sachant que cela signifie démonter le modèle qui paie aujourd’hui les salaires ?

Parce que le dilemme, au bout, n’est pas technique. C’est la volonté de cannibaliser le présent.

Et le temps pour décider de quel côté se ranger n’est probablement pas infini.

Ce billet naît de la lecture de « La morte dell’interfaccia utente come la conosciamo » de Mircha Emanuel D’Angelo. Si vous ne l’avez pas lu, à mon avis ça vaut la peine de partir de là.

Il existe trois types de gens dans le monde : ceux qui lisent les notices IKEA du début à la fin avant de toucher quoi que ce soit, ceux qui les balancent direct dans le sachet des vis en trop, et ceux qui les lisent à moitié et décident ensuite d’y aller à l’instinct.

Inutile de préciser que la troisième catégorie m’inclut, ainsi que ma mère, mon voisin de palier, et probablement 90 % de la péninsule italienne.

Et il y a peut-être une quatrième catégorie. Ceux qui n’achètent pas IKEA par principe et qui t’appellent à dix heures du soir parce qu’ils ont acheté un KALLAX et que « on n’y comprend rien ». On reparle d’eux plus tard, parce qu’il faut d’abord rendre hommage à la vraie divinité de toute cette histoire.

La feuille A3, autrement dit Björn

Partons de l’objet en lui-même, parce qu’il mérite le respect.

Les notices IKEA sont un chef-d’œuvre de design minimaliste. Pas un mot. Que des dessins. Un bonhomme stylisé, appelons-le Björn, parce qu’il a vraiment l’air d’un Björn, qui d’un air serein et avec des bras aux proportions étranges te montre comment faire des choses qui dans la réalité demandent trois mains, un étau hydraulique et une seconde où les enfants ne sont pas à la maison.

Björn ne transpire jamais. Björn ne dit jamais « attends, ce panneau est à l’envers ». Björn n’a jamais passé quarante minutes à comprendre que la pièce C n’était pas la pièce C mais la pièce C inversée, ce qui est une autre chose, et qu’IKEA le sait très bien, mais a décidé de ne pas te le dire explicitement parce que la vie est courte et que le caractère se forge.

Björn est serein parce que Björn n’existe pas.

Mais s’il existait, Björn serait du genre à commander tout de suite au restaurant, à ne pas demander de modifs, à ne pas vérifier l’addition. Björn se gare du premier coup. Björn n’a jamais eu à faire un demi-tour sur une nationale parce qu’il a raté la sortie. Björn n’a pas un tiroir des choses « à ranger plus tard ».

Björn est un sociopathe fonctionnel, et je l’envie profondément.

Le voyage vers IKEA, c’est-à-dire le pèlerinage

Avant d’arriver au montage, il faut parler de l’expérience IKEA dans son ensemble, parce que c’est un parcours spirituel en soi.

Tout commence par une promesse : « On y va juste pour les étagères. » Cette phrase est l’équivalent logistique de « on reste juste cinq minutes » à une fête. Ça n’est jamais arrivé, ça n’arrivera jamais, et pourtant on la répète à chaque fois avec la même conviction que celui qui jure que cette fois il arrêtera d’appuyer sur « continuer à regarder » sur Netflix.

Le parking IKEA est un écosystème à part. Il y a ceux qui tournent vingt minutes en cherchant la place près de l’entrée, et ceux qui se garent à trois cents mètres et marchent avec la détermination de quelqu’un qui a déjà fait la paix avec sa propre mortalité.

J’appartiens à une troisième espèce : celui qui trouve une bonne place, s’y engage, puis réalise que la voiture d’à côté a tellement ouvert sa portière qu’elle a créé une zone d’exclusion aérienne, ressort, repart, et finit dans le parking du Decathlon à côté.

Puis tu entres. Et là, le génie suédois se manifeste dans toute sa puissance.

Le parcours obligé. Ce labyrinthe à sens unique qui te fait traverser des chambres d’enfants que tu n’as pas, des bureaux dont tu n’as pas besoin, et des cuisines dont le plan de travail est aussi propre que si personne n’y avait jamais cuisiné. Ce qui est probablement vrai, parce que c’est une cuisine IKEA dans un magasin, mais le fait est que la mienne n’est jamais comme ça.

Au passage, tu ramasses des trucs. Des trucs dont tu n’avais pas besoin, que tu ne cherchais pas, et dont cinq minutes plus tôt tu ignorais l’existence. Un organisateur de tiroir. Un set de bocaux. Un coussin en forme de nuage à trois euros quatre-vingt-dix qui pour une raison obscure te semble indispensable.

IKEA a compris quelque chose de fondamental sur la psychologie humaine : on ne sait pas ce qu’on veut tant que quelqu’un ne le met pas devant nous à un prix qui semble trop bas pour dire non.

Tu arrives aux étagères, la raison de ta venue, après quarante-cinq minutes, deux sacs jaunes pleins, et une discussion sur l’opportunité ou non de prendre des rideaux neufs. Il en faut, mais tu ne l’admettras pas avant deux autres voyages.

L’entrepôt, où la dignité vacille

Mais le vrai test psychologique, ce n’est pas le parcours. C’est l’entrepôt.

Ce hangar aux rayonnages hauts comme des cathédrales, où tu dois trouver ton étagère parmi mille cartons plats tous marron, tous identiques, tous avec un code alphanumérique que tu as gribouillé sur ce petit papier avec le mini-crayon IKEA. Oui, celui qui est trop court pour écrire confortablement et trop épais pour tenir dans la poche, et que tu retrouves six mois plus tard dans le vide-poches de la voiture.

Allée 24, rayon 8. Tu arrives. Le rayon 8 est en haut. Le carton pèse vingt-trois kilos. Personne autour.

Les options : demander de l’aide (impensable, tu es italien), grimper (possible mais déconseillé pour la posture), ou attraper le carton dans un mouvement athlétique que tu ne fais plus depuis le lycée et que ton kiné qualifierait de « choix ».

Tu choisis la troisième option. Le carton glisse. Tu le bloques avec un genou. Tu jettes un œil pour t’assurer que personne n’a vu. Personne n’a vu. Tu repars la dignité intacte et une contusion future au genou gauche.

L’ouverture du carton, c’est-à-dire le rite

Il y a un rituel précis dans l’ouverture du carton IKEA, et il ne faut pas le sous-estimer.

Première chose : la place. Il te faut de la place. Le manuel dit « monter dans une zone vaste et dégagée », ce qui dans la réalité d’un appartement italien signifie déplacer la table, le tapis, et cette pile de trucs « à ranger plus tard » qui stationne à côté du canapé depuis le printemps dernier.

Tu ouvres le carton. Le carton se déchire de manière imprévisible, jamais le long de la ligne que tu voulais. À l’intérieur, une mer de polystyrène, des sachets de visserie, des panneaux enveloppés dans un film protecteur qui colle à tout sauf à lui-même, et cette feuille.

La feuille A3.

Tu la déplies avec une certaine révérence.

Premier geste : tu regardes le dessin final. Le meuble complet, avec un vase et une fleur dessus, à côté une pile de livres rangée d’une nonchalance trop étudiée pour être vraie. Tu te dis : « oui, je le veux comme ça. » Puis tu regardes l’étape 1, un panneau plat, deux tourillons, une flèche, et l’écart entre le rêve et la réalité te frappe avec la même brutalité que ton relevé bancaire après Noël.

Deuxième geste : tu comptes les étapes. 24 étapes. « Pas tant que ça », te dis-tu. C’est l’équivalent émotionnel de regarder une série en six saisons et se dire « je la finis ce week-end ».

Troisième geste : tu vérifies les vis. Les sachets. Tu les disposes proprement. Tu les comptes. Tu découvres qu’il y en a plus que prévu. Tu te demandes si c’est une erreur, un bonus, ou un test psychologique. Tu ne le sauras jamais.

Le moment de la foi aveugle (en général à l’étape 7)

Il y a un moment précis dans le montage de n’importe quel meuble IKEA où il faut faire un acte de foi.

C’est en général à l’étape 7 sur 24. Tu viens de visser quelque chose qui ne semble mener nulle part, la structure tient par deux tourillons en bois et de l’espoir, et la notice te montre, avec ce calme exaspérant, qu’il faut tout retourner.

Retourner. Tout. Tout seul.

Björn le fait d’un doigt, bien sûr. Sur le dessin, la structure pivote avec une flèche courbe et légère, comme si la gravité n’était qu’une suggestion.

Dans la réalité, tu enlaces un parallélépipède instable d’aggloméré du poids d’un ado moyen, et tu le fais pivoter en utilisant comme leviers le genou, le coude, et une foi en la colle à bois que tu n’avais jamais éprouvée.

Voilà, ce moment-là, avec le meuble qui craque et toi qui le tiens comme si tu serrais quelqu’un que tu essaies de ne pas laisser tomber, c’est exactement ce que je ressens face aux échéances de mars. Tu tiens tout avec pas grand-chose, tu ne sais pas encore si ça tient, mais le plan dit d’avancer.

Et tu avances. Parce que l’alternative — démonter, recommencer, relire depuis le début — est tellement déprimante que tu préfères risquer.

La clé Allen, petite et infinie

Ouvrons un chapitre à part sur la clé Allen, parce qu’elle le mérite.

La clé Allen IKEA est l’outil parfait pour un monde imparfait. Petite, simple, apparemment inoffensive. Fournie gratuitement avec chaque achat, ce qui veut dire qu’au bout de trois meubles tu as plus de clés Allen que de couverts.

La clé Allen est aussi le seul outil qu’IKEA juge nécessaire au montage. C’est un acte d’optimisme suédois qui frôle l’inconscience.

Parce que le montage IKEA, à un moment donné, demande toujours autre chose. Un marteau, par exemple, pour ces tourillons en bois qui n’entrent jamais du premier coup et qu’il faut « insérer délicatement ». Traduction : taper avec ce que tu as sous la main, y compris le fond d’une tasse, un livre épais, ou dans un cas mémorable, une chaussure.

Et puis il y a le moment de la clé Allen, ce moment où tu visses, tu visses, tu visses, où la clé est courte, où tu fais un demi-tour à la fois, où le poignet commence à protester, et où tu te demandes : ça existe vraiment, des gens qui montent une cuisine entière IKEA avec ce truc ? Une cuisine entière ?

Oui, ça existe. C’est la même catégorie que ceux qui montent l’Everest. Même catégorie psychologique.

Les assistants, autrement dit le chaos organisé

Aucun récit sur les notices IKEA ne serait complet sans parler des assistants.

L’assistant volontaire, c’est cette personne — partenaire, ami, parent, coloc — qui à un moment du montage dit : « Je t’aide. » Avec de bonnes intentions. Avec l’assurance de quelqu’un qui n’a pas lu la notice.

L’assistant volontaire tient le panneau du mauvais côté. L’assistant volontaire te passe la vis longue quand il fallait la courte. L’assistant volontaire, à un moment, prend la notice, la regarde trente secondes, et dit : « Tu n’aurais pas dû mettre celui-là d’abord ? »

« Celui-là », c’est la pièce que tu as déjà vissée. Deux étapes plus tôt. Avec six vis.

Et la réponse est oui, tu aurais dû la mettre d’abord, mais c’est trop tard, et si tu démontes maintenant, tout s’écroule, et ce « tout » inclut le meuble, ta patience, et probablement la relation.

Puis il y a l’assistant technologique, celui qui à mi-montage sort le téléphone et cherche un tutoriel sur YouTube. « Attends, il y a un type qui le monte en six minutes. » Oui, il y a toujours un type qui le monte en six minutes. Ce type a un atelier, une visseuse à batterie, et n’a probablement jamais douté de rien dans sa vie. Ce type est le Björn de YouTube. Il ne m’aide pas.

L’assistant le plus dangereux, cependant, c’est l’enfant.

L’enfant veut aider. L’enfant prend les sachets de vis. L’enfant les ouvre. L’enfant t’apporte une vis. Pas la bonne vis. Une vis quelconque. Avec la joie innocente de qui ignore que cette vis-là était la seule M6x30 du sachet et qu’elle est maintenant sous le canapé, à cet endroit précis où ta main n’arrive pas et où vivent, autant que je sache, toutes les vis IKEA perdues depuis 1987.

Les vis en trop et le tiroir de la conscience

Parlons des vis en trop.

Chaque montage IKEA se termine par un petit groupe de vis, rondelles et tourillons restés au sol. Des pièces dont tu ne sais pas où elles vont. Qui vont peut-être quelque part, peut-être nulle part, peut-être à un autre meuble, peut-être qu’IKEA les met exprès pour voir ce que tu fais.

La réaction italienne standard, c’est de les ramasser, les mettre dans un tiroir, et les oublier pour les quatre années suivantes. Ce tiroir, c’est notre conscience.

J’ai un tiroir comme ça. On en a tous un. C’est le tiroir où finissent les vis IKEA en trop, les chargeurs de téléphones qu’on n’a plus, les piles peut-être déchargées peut-être pas, les notices d’électroménager qu’on ne lira jamais, et au moins trois clés dont on ne connaît pas la serrure.

Ce tiroir, c’est l’autobiographie matérielle de notre vie adulte.

Il y a ceux qui — et je le dis avec une admiration sincère — s’asseyent, rouvrent la notice depuis le début, et trouvent où vont ces pièces. Ils cherchent. Ils trouvent. Ils vissent.

Ces gens-là font aussi des sauvegardes régulières de leur ordinateur, lisent le manuel du four, et ont un tiroir à câbles trié par type et longueur.

Je les admire. Je ne les comprends pas, mais je les admire.

J’ai essayé une fois, pour un MALM, d’être cette personne. J’ai rouvert la notice. J’ai vérifié étape par étape. J’ai trouvé que les deux vis en trop allaient à l’étape 14, qui disait clairement, clairement pour Björn, obscurément pour quiconque, de fixer un crochet anti-basculement au mur.

Un crochet anti-basculement. Au mur.

Qui demandait une cheville, une perceuse, et la connaissance approximative du passage des tuyaux dans l’enduit.

Les vis sont retournées dans le tiroir.

Les noms IKEA, c’est-à-dire des incantations nordiques

Une parenthèse sur les noms, parce que les noms IKEA méritent attention.

BILLY. KALLAX. MALM. LACK. HEMNES. BESTÅ. FJÄLKINGE.

Ce sont des noms de lacs suédois, de villages, de rivières, d’adjectifs. Mais ils sonnent comme des incantations. Comme des créatures mythologiques. Comme les phases d’un deuil particulièrement complexe.

« J’ai monté le FJÄLKINGE. » On dirait une phrase qu’on prononce après une expédition arctique. Et d’une certaine façon, ça l’est. Parce que le FJÄLKINGE est une étagère métallique qui semble simple et qui, après quatre heures de montage, te fait reconsidérer tous tes choix de vie, y compris celui de ne pas avoir acheté une vraie bibliothèque chez l’ébéniste.

Et puis il y a les noms des petites pièces. La visserie. FIXA, TRÅDFRI, SKÅDIS. Tu les lis sur la boîte et tu te dis : « Ce n’est pas un produit, c’est le nom du méchant dans un film scandinave. »

« SKÅDIS a encore frappé. »

Le coup de fil au pire moment

À un moment du montage, en général entre l’étape 12 et l’étape 16, dans cette terre de personne où tu es trop avancé pour reculer et trop confus pour avancer, arrive le coup de fil.

Ce n’est jamais un coup de fil bref. C’est ta mère. Ou un collègue. Ou ce parent qui n’appelle que quand tu as les mains prises.

Tu te retrouves le téléphone coincé entre l’épaule et l’oreille, une main sur un panneau et l’autre qui essaie de visser à un angle physiquement impossible, en répondant « oui, oui, tout va bien » à quelqu’un qui te raconte une chose qui mérite de l’attention et qui n’en aura pas.

Parce que ton attention est entièrement sur le panneau qui glisse, et s’il tombe, tu repars de zéro à l’étape 11.

Le coup de fil se termine. Tu ne sais pas ce qu’on t’a dit. Le panneau n’est pas tombé.

Tu considères les deux comme une victoire.

La métaphore que tu n’arrives pas à éviter

À un moment du montage, en général agenouillé sur le parquet avec le dos qui proteste déjà, tu réalises que les notices IKEA sont, en réalité, une métaphore assez précise de la vie adulte.

Elles ne te disent pas combien de temps il faudra. Le temps estimé n’y est pas, ou s’il y est, c’est le temps de Björn, qui vit dans une dimension parallèle où les choses s’emboîtent au premier essai et où personne ne t’appelle pendant que tu visses.

Elles n’expliquent pas pourquoi. Juste : fais ça. Puis ça. Pas de questions.

Elles n’admettent pas que certaines choses sont difficiles. L’étape la plus complexe, celle où tu dois maintenir trois panneaux pendant que tu insères une vis dans un point accessible uniquement aux enfants de moins de six ans et aux contorsionnistes professionnels, a exactement la même iconographie que celle où tu poses deux pièces plates l’une sur l’autre.

Elles ne prévoient pas les imprévus. Le chat qui s’assoit sur la boîte. L’enfant qui veut « aider ». Le partenaire qui dit « mais c’est pas de travers ? » au moment exact où tu vas serrer le dernier boulon. Le faux-plat du sol qui rend chaque chose légèrement oblique.

Et puis la découverte la plus cruelle de toutes : ce n’est pas le meuble qui est de travers, c’est le mur. Le mur.

Elles ne te disent pas quoi faire quand tu te trompes. Il n’y a pas d’étape « si tu as vissé le panneau du mauvais côté, retourne à l’étape 4 ». Parce que Björn ne se trompe pas. Björn n’a jamais rien raté. Björn est l’utopie suédoise sous forme de bonhomme stylisé, et son jugement silencieux pèse plus que n’importe quel reproche.

Et pourtant, ça fonctionne.

Pas toujours du premier coup, pas toujours sans éclats, pas toujours sans cette petite déviation par rapport au plan qu’à la fin on ne voit pas et à laquelle on cesse de penser après un moment. Mais ça fonctionne.

Le meuble tient. Le bureau tient. Le Billy que j’ai monté en 2009 tient encore, malgré tout, et il fait désormais partie de la famille.

Le Billy, saint patron de l’aggloméré

À propos du Billy. Parlons-en.

Le Billy est le repère fixe de l’univers IKEA. Le méridien zéro. La constante cosmologique du meuble en kit. Chaque Italien a eu, a, ou aura un Billy. C’est une certitude statistique.

Mon premier Billy, je l’ai monté en 2004. J’étais jeune, optimiste, et convaincu qu’« une heure de montage » signifiait vraiment une heure.

Trois heures plus tard, le parquet rayé et un bleu au pouce, le Billy était debout. Oblique, mais debout.

Ce Billy est encore là. Il a traversé trois déménagements, deux relations, un changement de ville, et un tremblement de terre. Il n’a jamais vacillé. Ou plutôt, il a toujours vacillé, mais il n’est jamais tombé. Comme nous tous.

Le Billy est la preuve que la perfection n’est pas nécessaire. Qu’on peut tenir avec quelques vis en moins, un panneau légèrement de travers, et un tourillon qui allait peut-être de l’autre côté.

Le Billy ne juge pas. Le Billy contient tes livres, tes souvenirs, et cette photo que tu aurais dû encadrer il y a trois ans. Le Billy est patient.

Si IKEA faisait des saints, Billy serait le premier.

Variantes régionales, couples et autres formes de courage

Le montage IKEA est universel, mais la réaction au montage est profondément locale.

L’Italien du Sud monte avec passion. Il parle au meuble. Il l’encourage. Il l’insulte. Il le traite comme un membre de la famille particulièrement têtu. « Mais où tu vas ?! Reste là ! Qu’est-ce que je t’ai dit ! » Le meuble ne répond pas, mais l’Italien du Sud n’en a cure. Il a l’habitude de dialoguer avec des choses qui ne coopèrent pas.

L’Italien du Nord monte avec méthode. Il a la visseuse électrique. Il a le tapis pour ne pas rayer le sol. Il a déjà lu la notice. Il monte en silence, avec une efficacité qui est en soi une forme d’agressivité passive. À la fin, il ne jubile pas. Il opine. Comme si le meuble était un subordonné qui a enfin compris.

L’Italien du Centre, et je parle d’expérience directe, monte avec une résignation créative. Il sait que quelque chose va mal tourner. Il l’accepte d’avance. Quand ça tourne mal, il soupire. Quand par miracle ça ne tourne pas mal, il flaire le piège.

Et puis il y a les couples.

Monter un meuble IKEA en couple est le test relationnel le plus fiable jamais inventé. Plus que le premier voyage ensemble. Plus que connaître les beaux-parents. Plus que partager une salle de bain pour la première fois.

Parce que le montage IKEA en couple révèle tout.

Qui lit la notice et qui ne la lit pas. Qui a de la patience et qui n’en a pas. Qui dit « passe-moi cette vis » en pensant à une vis précise, pendant que l’autre la passe en pensant à une autre, et le premier dit « non, celle-là » et l’autre dit « laquelle ? » et le premier dit « celle-là » en désignant du menton parce qu’il a les deux mains prises, et l’autre attrape une rondelle.

Il y en a toujours un qui veut suivre la notice et un qui veut improviser. Un qui dit « stop, on lit » et un qui a déjà vissé trois panneaux et dit « mais c’est pareil ». Ce n’est pas pareil. Ce n’est jamais pareil.

J’ai vu des couples très solides vaciller devant un PAX. Le PAX, c’est l’armoire de la discorde. Grande, complexe, avec des portes coulissantes, et qui demande un niveau de coordination que la plupart des couples n’atteignent qu’après des années de thérapie.

Si vous montez un PAX ensemble et qu’à la fin vous vous parlez encore, mariez-vous. Vous avez passé l’épreuve.

Le lendemain matin d’IKEA

Il y a un phénomène peu documenté que j’appelle « le lendemain matin d’IKEA ».

Tu te lèves. Tu as les muscles douloureux à des endroits dont tu ignorais l’existence. Le dos proteste. Les genoux se souviennent des deux heures sur le parquet. Les doigts gardent encore la marque de la clé Allen.

Mais ensuite tu le vois. Le meuble. Là. Debout. Complet. Dans la pièce.

Et il y a un instant, un très bref instant, avant le café, avant tout, où tu le regardes et tu te dis : « C’est moi qui l’ai fait. » De mes mains. Avec une feuille A3. Avec une clé Allen.

C’est une fierté primordiale. C’est la même fierté que l’homme des cavernes qui a construit un abri. Peu importe que l’abri soit une table de chevet avec un tiroir qui ne ferme pas parfaitement. C’est toi qui l’as fait.

Puis tu t’assieds pour le petit-déjeuner et tu vois, sous la table, une vis.

Une vis solitaire.

Une vis dont tu ignores l’origine, dont tu ignores la destination, et qui restera là trois jours avant de finir dans le tiroir.

Le cycle est complet.

L’emboîtement final, et l’épilogue inévitable

Il y a une satisfaction spécifique au moment où le dernier panneau prend sa place et où la structure, soudain, devient rigide. Tout ce qui semblait branlant se solidifie. Les bruits disparaissent.

Björn avait raison depuis le début.

Je ne saurais te dire si cette sensation vaut les deux heures de travail, le dos, les vis mystérieuses dans le tiroir, le moment où tu as retourné le meuble seul en le tenant avec un genou et une prière laïque, l’assistant qui t’a passé la mauvaise vis, l’enfant qui a perdu la M6x30 sous le canapé, le coup de fil de ta mère, et ce petit éclat sur le côté gauche qui « de toute façon est contre le mur, on ne le voit pas ».

Je sais qu’à chaque fois je me convaincs que la prochaine fois je lirai la notice depuis le début.

Et chaque fois j’arrive à l’étape 7, le panneau a l’air d’aller, et je me dis : oui allez, je sais déjà où ça va.

Je ne le sais jamais.

post scriptum

Je regarde le site IKEA en ce moment. Il y a une nouvelle bibliothèque. Bois massif, trois étagères, « montage simple ».

Montage simple.

Je sais que ce n’est pas vrai. Tu le sais aussi. Björn le sait, dans son cœur stylisé.

Je la commande quand même.

Si toi aussi tu as un tiroir de vis sans nom, un Billy qui n’a jamais été vraiment droit, et la certitude inébranlable que la prochaine fois tu liras la notice, tu es des miens.

On se retrouve à l’étape 7.

Pas un prototype posé là pour la forme, pas une maquette assortie du « on peaufinera plus tard » implicite. Quelque chose de vivant, avec un domaine, un backend qui tourne, une interface utilisable. Quelque chose qu’un vrai utilisateur peut ouvrir maintenant et utiliser.

J’y ai mis 17 minutes. Je n’ai pas écrit une ligne de code. J’ai parlé à un outil d’IA.

Le résultat est music-map.uk, une application qui répond à une question que vous ne vous êtes peut-être jamais posée : à quoi ressemble ce coin du monde, en musique ?

Et non, ce billet ne parle pas de music-map. Ou plutôt, pas du produit en lui-même. Il parle de ce que cela signifie qu’une telle chose puisse exister comme ça, pendant que l’eau du café est en train de monter.

La distinction qui change tout

Une mise au point s’impose, sinon on a l’impression que je raconte une histoire qui existe déjà depuis des années, juste avec un peu plus d’enthousiasme.

Il existe des outils grand public qui promettent exactement cela : tu ouvres un navigateur, tu décris l’idée, et en quelques clics tu as une app. Lovable, Bubble, Glide, Softr. L’écosystème est immense et grandit en permanence.

Le problème, c’est qu’aujourd’hui il reste un écart assez net entre « j’ai construit quelque chose qui ressemble à une app » et « j’ai construit quelque chose qui tient en production ». Je ne dis pas ça par snobisme, ni comme un jugement sur ces produits. Pour certains usages, ils sont excellents.

C’est une question de substance : robustesse, scalabilité, contrôle sur le code généré, capacité d’intervenir quand quelque chose casse, vraie ownership de l’infrastructure. Cette sensation très concrète de savoir où sont les pièces et ce qui se passe si l’une d’elles cesse de fonctionner.

Moi, j’ai utilisé des outils pensés pour des gens qui savent déjà, d’une manière ou d’une autre, ce qu’ils sont en train de construire. Des outils qui supposent que tu as un contexte technique, que tu sais lire une erreur, que tu peux prendre des décisions d’architecture quand on te les met sous le nez.

Cette différence est encore énorme. Et c’est exactement le point.

Le b2b ne me fait pas peur, pour l’instant

Pendant que je finissais mon café, la question qui plane toujours sur le secteur, même quand on fait semblant de l’ignorer, m’est tombée dessus : est-ce que ça va me prendre mon boulot ?

Côté b2b, la réponse, telle que je la vois aujourd’hui, est non. Du moins, pas dans le sens catastrophique que la narration mainstream affectionne.

Parce que le travail b2b bien fait n’a jamais été « écrire du code ». C’est comprendre le contexte d’un client, traduire des besoins souvent confus en exigences techniques précises, garantir qu’un système tienne sous pression, naviguer dans la compliance et les normes, entretenir des relations de confiance dans la durée.

Au quotidien, chez Oltrematica, j’ai sur la table en même temps une migration de Python vers Laravel 12, des frameworks de conformité au Cyber Resilience Act, des plateformes SBOM pour des clients qui doivent rendre compte de leur logiciel à des organismes publics, et des solutions liées à la Product Liability Directive qui entrera en vigueur en 2026. Ce n’est pas le genre de chose qu’on règle en 17 minutes de conversation.

L’IA a changé comment je fais ce travail. La vitesse sur certaines tâches a augmenté de façon presque embarrassante. Mais la valeur que j’apporte n’était pas dans la frappe du code. Elle était dans le fait de savoir quoi écrire, pourquoi, et surtout quoi éviter.

Cette partie, pour l’instant, n’a pas disparu. Elle s’est peut-être même renforcée, parce qu’elle me laisse plus d’espace pour penser.

Le grand public, c’est une autre histoire

Côté grand public, en revanche, je suis moins serein. Pas parce que les apps disparaissent demain, mais parce que la forme du marché me semble changer.

Si tu prends la courbe d’adoption classique — innovateurs, early adopters, majorité précoce, majorité tardive, retardataires — et que tu te demandes où on en est avec les outils d’IA pour développer du logiciel, il en sort quelque chose d’étrange.

Pour ceux qui développent, on est déjà dans la majorité précoce. Beaucoup les utilisent tous les jours, l’intégration aux workflows est réelle, la productivité se mesure.

Pour un utilisateur non technique, en revanche, on est encore entre innovateurs et tout premiers early adopters. Le seuil technique reste élevé. Pas aussi élevé qu’il y a dix ans, mais assez pour exclure la plupart des gens.

Et ce seuil baisse chaque mois. Pas toujours de façon linéaire. Parfois il y a un saut, parce que quelqu’un trouve une interface qui marche vraiment, ou parce qu’un modèle devient assez capable pour gérer l’ambiguïté du langage naturel sans te forcer à le corriger toutes les deux minutes.

Quand ce seuil descendra assez bas pour qu’une personne ordinaire — qui ne sait pas ce qu’est un serveur et ne veut pas le savoir — le franchisse, le marché grand public du logiciel changera de manière irréversible.

Le vrai « produit » des apps grand public

Je vais essayer de le dire simplement.

Pendant les quinze dernières années, une app grand public a fonctionné comme ça : quelqu’un avait une idée, et seules les personnes qui avaient les compétences techniques — ou l’argent pour les acheter — réussissaient à la transformer en produit. Ensuite, ce produit était distribué et utilisé par d’autres.

La valeur était dans l’exécution, oui. Mais en dessous, il y avait autre chose : la distance.

La distance entre avoir une intention et pouvoir l’utiliser.

Cet écart, entre « je voudrais » et « je peux », a été le marché. Les apps grand public existaient parce qu’il y avait une barrière technologique entre celui qui savait construire et celui qui voulait utiliser.

Si cette distance s’annule — si n’importe qui peut décrire ce qu’il veut et recevoir en retour un logiciel fonctionnel calibré sur ses besoins — que reste-t-il du modèle classique ?

Je ne dis pas que les apps disparaissent demain. Je dis que le mécanisme qui a soutenu une part énorme du grand public pourrait cesser de fonctionner plus vite que prévu.

Le logiciel sur mesure va-t-il devenir la norme ?

Une idée me trotte dans la tête depuis quelques mois. Elle me semble radicale, mais peut-être seulement parce qu’on est habitués à l’inverse.

Dans le monde physique, la production de masse a du sens parce que la personnalisation coûte cher. Une chaise sur mesure coûte beaucoup plus qu’une chaise Ikea. Tu acceptes donc un compromis et tu achètes quelque chose de standard, « assez bien ».

Le logiciel a fonctionné de la même manière. Une app de prise de notes est conçue pour des millions de personnes, donc elle fait des choix qui conviennent à beaucoup et sont parfaits pour très peu. Tu l’achètes parce que jusqu’à hier, te la construire sur mesure coûtait des années ou des milliers d’euros.

Mais si le coût de la personnalisation s’effondre presque à zéro ?

Si je peux décrire comment je veux vraiment mon app de notes, avec les catégories que j’utilise, le flux que je préfère, intégrée aux outils que j’ai déjà, est-ce que ça a encore un sens d’acheter celle pensée pour des millions d’utilisateurs ?

Peut-être que oui, par confort. Peut-être que non, si la différence entre « m’adapter » et « l’avoir comme je la veux » devient trop évidente.

Je me demande si le logiciel de masse aura le même destin que la musique commerciale à l’ère du streaming. Il reste, certes, mais il cesse d’être au centre de tout, parce qu’à côté grandissent des expériences plus personnelles, plus sur mesure.

Qui pourrait résister

Si ce scénario se vérifie — et j’y mets un « si », non pas parce que je doute de la direction, mais parce que la vitesse et la forme du changement sont vraiment incertaines — il existe des modèles grand public qui semblent plus solides que d’autres.

Les plateformes de réseau, par exemple. Twitter, LinkedIn, WhatsApp. Leur valeur n’est pas dans l’app en elle-même, mais dans le fait que tous les autres y sont. Tu ne peux pas avoir ta version personnalisée d’un réseau, parce qu’un réseau sans réseau n’est qu’une interface vide.

Ensuite, il y a les services à données propriétaires. Spotify ne vend pas un lecteur de musique. Il vend l’accès à des catalogues, à des métadonnées, à des licences, à des algorithmes nourris de milliards d’écoutes. Ça ne se génère pas avec un prompt.

Et il y a les produits où la confiance et la compliance font partie du paquet. Finance, santé, juridique. Même si une IA te générait le logiciel parfait, la question reste : qui prend la responsabilité ? Qui certifie ? Qui répond quand quelque chose tourne mal ?

Enfin, peut-être, les produits haut de gamme avec une UX exceptionnelle. Certaines expériences sont soignées d’une manière qui ne se résume pas à « ça marche », c’est de la qualité perçue. Notion, Linear, Figma. Répliquer des fonctionnalités est une chose. Répliquer cette cohérence, ce détail, cette confiance esthétique et opérationnelle, en est une autre.

Ce qui risque de souffrir le plus, en revanche, ce sont les utilitaires de niche. Les apps qui « font une seule chose », les micro-SaaS à 9,99 € par mois qui vivent parce qu’ils résolvent un problème spécifique mieux que les autres. Si je peux me la construire en une heure, ce prix commence à trembler.

La barrière qui reste, pour l’instant

Il y a une objection légitime, et je la perçois aussi.

Les gens ne veulent pas construire leurs propres choses. Ils veulent les utiliser.

C’est vrai. Et ça le sera probablement encore un bon moment. Il y a le confort, la confiance, l’économie cognitive. Rien que formuler clairement ce que l’on veut, c’est déjà un effort, alors itérer, corriger, choisir…

Mais cette barrière n’est pas stable. Elle baisse avec l’habitude. Elle baisse avec de meilleures interfaces. Elle baisse avec l’éducation numérique. Et elle baisse surtout quand l’avantage d’avoir quelque chose sur mesure devient assez évident pour justifier l’effort, pendant que cet effort, lui, continue de diminuer.

Pour moi, le point d’inflexion ne sera pas « l’outil est devenu accessible ». Ce sera « la première fois que quelqu’un que je connais me montre ce qu’il a fait en 20 minutes, et que je me dis : je pourrais le faire moi aussi ».

Ce moment arrive. Pour certaines personnes, il est déjà arrivé.

Ce que l’on pourrait voir dans les prochaines années

Je ne suis pas analyste, je n’ai pas de boule de cristal. Prenez ces lignes comme des intuitions informées, pas comme des prévisions.

Je pense qu’on verra une première vague de produits grand public qui ne s’achètent plus, mais se construisent. D’abord dans les segments les plus tech-friendly — développeurs, designers, étudiants — puis par cercles concentriques.

Je pense qu’on verra une pression énorme sur les prix des micro-SaaS. Pas parce qu’ils deviennent inutiles, mais parce qu’il devient difficile de justifier un abonnement quand la même utilité est générable à la demande. Survivront ceux qui offrent quelque chose qui ne se génère pas facilement : des données, du réseau, de la confiance, une intégration profonde aux écosystèmes existants.

Et je pense qu’apparaîtront de nouveaux intermédiaires. Pas des « constructeurs d’apps », mais des curateurs et distributeurs d’intentions de logiciel. Des gens qui empaquettent des prompts, des configurations, des flux déjà testés, pour que d’autres puissent créer sans partir de zéro. Une sorte de marketplace de templates, mais plus profonde, plus opérationnelle.

Il y aura aussi, sans doute, des tentatives de réglementation, plus ou moins maladroites, sur certains scénarios particuliers.

Le café du matin comme métaphore

Je reviens au point de départ, parce que c’est là que la sensation est restée.

Ce n’est pas la vitesse qui m’a vraiment frappé. C’est le coût cognitif. J’étais distrait, je faisais autre chose, j’avais la tête sur deux choses en parallèle. Ce n’était pas une session de travail. Ce n’était pas « aujourd’hui, je construis un produit ».

Et pourtant le résultat est suffisamment bon pour rester en ligne.

Pour moi, c’est ça le signal. Le fait que produire du logiciel est en train de devenir quelque chose que tu fais en parallèle d’autre chose, comme envoyer un mail ou lancer une recherche Google. Une action qui ne demande plus un contexte dédié, une compétence spécifique, une énergie mentale particulière.

Quand une chose devient comme ça, sa place dans la hiérarchie cognitive et culturelle change. Et avec elle change le marché qui a poussé autour.

Le logiciel devient une intention. Pas encore pour tout le monde, pas encore de façon stable, mais la direction est celle-là, et la vitesse augmente.

Alors la question qui me reste, ce matin, est la suivante.

Si tu construis un produit grand public, la valeur est-elle dans la distance technologique entre toi et ton utilisateur, ou dans quelque chose qui existe encore quand cette distance n’existe plus ?

Si tu n’as pas de réponse claire, c’est peut-être le moment d’en trouver une.

J’ouvre le client de messagerie. Quatorze nouveaux e-mails. Je les parcours. J’en archive six, j’en jette trois, j’en marque deux pour plus tard. J’en lis un avec attention, je réfléchis, j’écris une réponse de huit lignes. J’envoie. Je bois le café.

Il est 8 h 07 et j’ai déjà le contrôle de la journée.

Voilà, cette petite liturgie matinale est la part la plus sous-estimée, la plus méprisée et, pour moi, la plus précieuse de la vie professionnelle. Et j’ai envie de la défendre, parce que nous vivons à une époque qui a décidé que l’e-mail est l’ennemi.

Le mauvais ennemi

J’ouvre LinkedIn et je tombe sur un post : « J’ai atteint l’inbox zero et ça m’a changé la vie. » Un autre : « J’ai arrêté de lire les e-mails et ma productivité a explosé. » Un troisième : « L’e-mail est mort, vive Slack ». QUATRE CENT MILLE LIKES.

Pendant ce temps, dans le monde réel, ceux qui ont remplacé l’e-mail par Slack reçoivent trois cent cinquante notifications par jour réparties sur vingt-sept canaux dont onze pour lesquels ils ne savent même plus pourquoi ils existent. Ceux qui ont remplacé l’e-mail par WhatsApp reçoivent des vocaux de trois minutes quarante qui commencent par « alors… » et finissent par « bon, on en reparle ». Ceux qui ont remplacé l’e-mail par les visios ont un agenda qui ressemble à un Tetris joué par un sadique, des créneaux de trente minutes empilés de 9 h à 18 h sans un trou pour aller aux toilettes.

Et vous voulez me faire croire que le problème, c’était l’e-mail ?

L’e-mail ne vous interrompt pas. L’e-mail n’exige pas que vous soyez disponible maintenant, à l’instant précis, alors que vous essayez de faire quelque chose qui demande plus de onze secondes d’attention. L’e-mail ne vous envoie pas une pastille rouge qui active dans le cerveau la même réponse chimique qu’une sirène anti-aérienne. L’e-mail ne fait pas « ding ».

L’e-mail est là, dans la boîte, poli, patient, silencieux, et il attend que vous soyez prêt.

Et c’est peut-être exactement le point. L’e-mail est l’un des rares outils de communication professionnelle qui, par sa nature, tend à respecter votre temps. C’est pour ça que tant de gens le détestent : respecter le temps des autres est devenu un concept presque suspect.

Éloge de la lenteur écrite

Il y a une chose que l’e-mail vous oblige à faire et que beaucoup d’outils « modernes » vous permettent d’éviter avec une facilité désarmante : penser avant de communiquer.

Pour écrire un e-mail, il faut organiser ses idées. Décider ce qu’on veut dire, à qui, et pourquoi. Choisir un objet — et l’objet d’un e-mail est un petit miracle de synthèse, une ligne qui doit convaincre quelqu’un d’ouvrir le message dans une mer d’autres messages. Écrire des phrases complètes. Relire. Se demander si ce ton est le bon ou si on s’apprête à déclencher une guerre diplomatique avec un adverbe de trop.

Comparez ce processus à un message Slack, qui sonne souvent comme ça :

« Salut » « T’es là ? » « J’ai un truc » « Vite » « Enfin deux » « Le premier : » [est en train d’écrire…] [est en train d’écrire…] [est en train d’écrire…] « Non rien je te le dis de vive voix »

Ou à un vocal WhatsApp, qui est l’équivalent communicatif de prendre le flux de conscience de quelqu’un, de l’embouteiller et de forcer quelqu’un d’autre à l’écouter en vitesse 1x. Le vocal, c’est le monologue intérieur de Joyce, mais sans le talent littéraire et avec le bruit de la circulation en fond.

L’e-mail est l’opposé de tout ça. L’e-mail est lent, et la lenteur est son superpouvoir. Il vous oblige à transformer une pensée confuse en message clair. Il vous force à séparer l’urgent de l’important. Il vous donne le temps de changer d’avis avant d’appuyer sur Envoyer, ce qui n’est pas rien.

Parce que la chat est une machine qui récompense l’impulsion. On appuie sur Entrée et la pensée devient réalité partagée. Et la fonction « supprimer pour tout le monde », disons-le, n’a jamais vraiment supprimé quoi que ce soit pour personne.

Le paper trail de la civilisation

Il y a un autre aspect de l’e-mail que personne ne célèbre assez : c’est une preuve écrite.

Je travaille souvent avec l’administration publique. Je travaille avec des entreprises qui ont des juristes. Je travaille dans un monde où, à un moment, quelqu’un dira : « Mais qui a décidé ça ? » Et à ce moment précis, qui arrive dans chaque projet avec la certitude d’un impôt, vous voulez avoir un e-mail.

Pas un message Slack que quelqu’un peut avoir modifié ou perdu dans un canal qui s’appelle « divers-2 ». Pas un vocal que personne ne réécoutera vraiment. Pas le souvenir vague d’une visio dont il n’existe pas de notes parce que « c’était informel ».

Un e-mail avec date, heure, expéditeur, destinataires et texte est un petit acte notarié de la vie professionnelle. C’est la réponse définitive à « je ne savais pas », « on ne me l’avait pas dit », « on n’était pas d’accord comme ça ». C’est une mémoire externe qui compense le fait que les humains se souviennent des conversations comme ça les arrange.

Chaque fois que quelqu’un me dit « je t’envoie un vocal, on ira plus vite », je pense : plus vite que quoi ? Plus vite que le moment où je devrai prouver ce qu’on s’est dit ?

La visio qui pouvait être un e-mail

Là je deviens polémique, et je devrais peut-être m’excuser à l’avance. Puis je me dis que non, je ne m’excuse pas.

Soixante-dix pour cent des visios auxquelles je participe pouvaient être un e-mail. Vous le savez aussi. Le sait quiconque a vécu une réunion de trente minutes dont vingt-cinq ont été passées à essayer de partager l’écran, trois à parler du temps qu’il fait et deux à dire la chose qu’on aurait pu écrire en quatre lignes.

« Faisons une visio rapide » est l’un des plus gros mensonges du travail contemporain. Il n’existe pas de visios rapides. Il existe des visios qui commencent avec cinq minutes de retard parce que quelqu’un a un problème de micro, qui durent le double du prévu parce que quelqu’un soulève un point hors-sujet, et qui finissent par « OK, en résumé, les prochaines étapes sont… » que personne ne notera vraiment. Et la prochaine visio repartira de zéro, comme si la précédente avait été un rêve.

Vous savez ce qui n’a pas de problème de micro ? Un e-mail. Vous savez ce qui ne dure pas le double du prévu ? Un e-mail. Vous savez ce qui contient déjà les « prochaines étapes » au moment où vous le recevez ? Exactement.

Je ne dis pas que les visios sont inutiles. Elles le sont, et comment. Quand il faut discuter de quelque chose de complexe, quand il y a un conflit à résoudre, quand on a besoin des visages et des tons de voix. Mais pour tout le reste — mises à jour, décisions binaires, questions à réponse, partage de documents — l’e-mail est supérieur sur presque toutes les métriques qui comptent vraiment : temps, clarté, traçabilité, respect de qui est en face.

Le rituel

Je reviens à 7 h 58. Au café à la température parfaite. À la boîte de réception qui attend.

Il y a un rituel dans l’ouverture du courrier que les outils instantanés ont un peu détruit. Le rituel de commencer la journée dans l’ordre. De regarder ce qui est arrivé, décider de ce qui est important, répondre à tête froide.

C’est l’un des derniers espaces de la journée de travail où c’est vous qui décidez du rythme, avant que Slack, Teams, WhatsApp et le calendrier ne prennent le dessus et transforment vos heures en une partie de ping-pong jouée sur sept tables en même temps.

L’e-mail n’est pas sexy. Pas d’emoji animées. Pas de double check bleu. Il ne vous dit pas si quelqu’un « est en train d’écrire ». Il ne vous fait pas sentir connecté en temps réel.

Mais c’est à 8 heures du matin, café à la main et quatorze messages à traiter en paix, que je fais mon meilleur travail. Et aucune pastille verte de statut en ligne ne pourra jamais remplacer ce moment.

Donc non. L’e-mail n’est pas mort. L’e-mail est, peut-être, le seul adulte dans la pièce. Et comme souvent les adultes dans la pièce, il est ignoré au profit de qui fait le plus de bruit.

Et pourtant.

Le client a tort.

Pas toujours, évidemment. Pas sur tout. Mais bien plus souvent qu’on aime l’admettre. Et je me demande si le vrai problème n’est pas le client lui-même, mais le mensonge poli qu’on lui raconte depuis des années. Celui du « le client a toujours raison ». Un mensonge qui dans le logiciel italien a fait des dégâts qu’on n’arrive même pas à compter, parce que les échecs ont rarement une pancarte « échec » dessus. D’habitude ils sont plus silencieux. Ce sont des projets qui finissent en production et que personne n’utilise. De l’argent brûlé sur des choses qui n’améliorent rien. Des nuits longues de gens qui savaient que ça partait mal, mais qui n’avaient pas l’espace, ou la permission, de le dire.

C’est un texte un peu méchant, oui. Je ne vous demande pas d’être d’accord. Je vous demande juste d’être honnête, le temps de cette lecture.

Le oui qui tue les projets

J’ai vu mourir plus de projets pour un oui que pour un non.

Le mécanisme est presque toujours le même, et c’est précisément pour ça qu’il fait peur. Le client demande quelque chose. Vous le savez, vous le sentez, vous le voyez dans les détails : c’est faux techniquement, ou économiquement, ou tout simplement comme direction. Mais vous dites oui quand même.

Vous dites oui parce qu’il y a un contrat. Parce qu’il y a une relation à protéger. Parce qu’« on règlera ça plus tard ». Parce que la poignée de main est déjà donnée et que revenir en arrière ressemble à une défaite. Parce que dire non est inconfortable, demande des arguments, demande de l’énergie, et surtout du courage.

Et alors le projet ne meurt pas d’un coup. Il meurt un oui à la fois.

Chaque oui ajoute une feature dont personne ne se servira. Chaque oui repousse un bout de deadline ou comprime un bout de qualité. Chaque oui rend l’architecture un peu plus fragile et le code un peu plus tordu, jusqu’à ce que ce que vous construisez ne ressemble plus à un produit, mais à un compromis stratifié.

À la fin, vous livrez un logiciel qui fait cent cinquante choses, aucune bien, et le client vous regarde et dit : « ce n’est pas ce que je voulais ».

Et c’est là que ça brûle, parce que d’une certaine façon il a raison. Ce n’est pas ce qu’il voulait. C’est ce qu’il a demandé. Deux choses différentes.

Et notre métier, le vrai, n’est peut-être pas d’exécuter des ordres. Il est de reconnaître la différence.

Catalogue des horreurs (toutes vraies, hélas)

Ce qui suit est vrai. Les noms sont changés, pas les dynamiques. Et si vous pensez « j’en ai vu un identique », vous n’êtes pas seul.

La GED infinie

Une entreprise moyenne demande une GED. Jusque-là tout va. Puis, en cours de développement, chaque service ajoute des exigences. Les RH veulent le module congés, le marketing veut le tableau de bord, la compta veut l’intégration avec l’expert-comptable, et chacun se croit le centre du monde.

Personne n’a le pouvoir de dire stop, parce que chaque service est un « client interne » qui « a raison ». Résultat : dix-huit mois de développement, un produit qui fait tout mal, et après la livraison l’entreprise continue à utiliser Excel. Qui, dans son coin, au moins, ne trahit pas.

L’appel d’offres photocopié

Une commune doit numériser un service. L’appel d’offres est rédigé en copiant celui d’une autre commune, peut-être trois fois plus grande, aux besoins complètement différents. On y met des exigences qui sonnent bien sur le papier, mais qu’aucun citoyen n’utilisera jamais.

Celui qui remporte le marché le sait souvent. Mais l’appel d’offres est l’appel d’offres. Donc on construit exactement ce qui est écrit. On livre, on recette, on coche les cases. La plateforme passe en ligne.

Six mois plus tard, le service est encore géré par téléphone.

Et le plus triste, c’est que, formellement, tout s’est bien passé.

L’app qui devait tout changer

Une administration locale veut une app mobile pour les citoyens. Le décideur est un élu qui a vu l’app d’une autre commune et la veut pareille. Pas d’analyse des besoins, pas de recherche utilisateur, rien. Juste : « je veux l’app ».

Le fournisseur la construit. Au lancement, quatre cents téléchargements. Trois mois plus tard, douze utilisateurs, employés de la commune compris.

L’élu fait sa conférence de presse et parle d’innovation. Le fournisseur encaisse et passe au suivant.

Et je n’arrive jamais à décider qui me met le plus mal à l’aise dans cette histoire.

Le restyling qui était une réécriture

Un client demande de « rafraîchir » le site. Le commercial vend un restyling. Lors de la première réunion opérationnelle, il apparaît que le site n’a pas de CMS, que la base de données est un fichier Excel, que les contenus n’existent pas et que « rafraîchir » signifie repenser toute la présence numérique.

Mais le devis est celui d’un restyling, la timeline est celle d’un restyling, et les attentes sont celles d’un restyling.

Tout le monde sait que ce n’est pas un restyling. Personne ne le dit.

Le projet zombie

Un projet devait durer six mois et entre dans sa troisième année. Il ne marche pas, il n’est pas utilisé, mais personne ne le ferme parce que le fermer reviendrait à admettre que c’était une erreur.

Le client continue à payer des change requests. Le fournisseur continue à facturer. Tous deux savent qu’il est mort. Tous deux font semblant qu’il est vivant.

Il n’échoue jamais officiellement. Il cesse simplement d’être cité en réunion, comme un oncle gênant dont on ne parle pas à table.

Pourquoi ça arrive vraiment

Ça arrive parce que notre secteur a un problème structurel avec la vérité.

Le modèle économique du conseil IT italien est bâti sur le oui. Vous gagnez les projets en disant oui. Vous gardez les clients en disant oui. Vous faites carrière en disant oui. Tout le système, des commerciaux aux chefs de projet jusqu’aux développeurs, est optimisé pour minimiser le conflit et maximiser la facturation à court terme.

Le hic, c’est que court terme et long terme sont en guerre.

Dire oui aujourd’hui, c’est presque toujours payer demain. Chaque feature en plus est de la dette technique. Chaque exigence acceptée sans analyse est une bombe à retardement. Chaque timeline comprimée pour faire plaisir à quelqu’un est une garantie d’heures sup, souvent non payées, et de qualité sacrifiée.

Et pendant ce temps, le client n’apprend jamais. Pas parce qu’il est bête, mais parce que personne ne lui dit que cette demande était fausse. Personne ne lui dit que cet appel d’offres était mal écrit. Personne ne lui dit que cette app ne servait à personne.

Entouré de gens qui acquiescent, le client continue à demander les mêmes mauvaises choses, et le cycle reprend.

Et c’est ici qu’arrive la partie qui dérange, parce qu’elle déplace la responsabilité.

Ce n’est pas la faute du client. C’est notre faute.

C’est la faute d’un secteur qui a renoncé à son rôle, celui de l’expert. Celui qui sait des choses que le client ne sait pas, et qui a le devoir, non le droit, de les lui dire.

Le non comme service

Le meilleur service que vous puissiez rendre à un client, c’est de lui dire non.

Non, cette feature ne sert à rien.

Non, cette timeline n’est pas réaliste.

Non, cet appel d’offres est mal écrit, et si on le suit à la lettre on construira une chose inutile.

Non, vous n’avez pas besoin d’une app.

Non, vous n’avez pas besoin d’IA.

Non, vous n’avez pas besoin d’un restyling. Vous avez besoin de vous arrêter et de comprendre ce que vous voulez vraiment faire.

Chaque non a un coût. Coût de la gêne, coût de la tension, coût de quelques coups de fil difficiles. Parfois, coût du projet.

Mais chaque non est aussi un acte de respect envers le client, parce qu’il le traite comme un adulte capable d’entendre la vérité, pas comme quelqu’un qu’il faut contenter pour la paix des ménages.

Les meilleurs clients que j’ai eus dans ma carrière sont ceux à qui j’ai dit le plus de non. Au début, ils se raidissent, c’est normal. Puis, si vous tenez et si vous argumentez calmement, il se passe une chose : ils comprennent que quand vous dites oui, on peut vous croire.

La confiance ne se construit pas sur l’accord continu. Elle se construit sur la sincérité.

Et la sincérité, dans notre secteur, est rare. Peut-être plus rare qu’un bon développeur. Peut-être plus rare qu’un projet livré à l’heure. Peut-être plus rare qu’un appel d’offres bien rédigé.

Un manifeste minimal, sans héroïsme

Je ne sais pas si c’est un manifeste, mais s’il en est un, il tient pour moi en trois lignes.

Ne dites pas oui quand vous savez que c’est non.

Ne construisez pas ce que le client demande si vous savez que ce n’est pas ce qui lui faut.

Et quand vous vous trompez — parce que vous vous tromperez et qu’on se trompera tous —, trompez-vous au moins en disant la vérité, pas en acquiesçant.

Le client n’a pas toujours raison. Mais il mérite toujours quelqu’un qui ait le courage de le lui dire.

Le plan ne survit jamais au parking.

18:34. J’arrive. Et le parking du supermarché est plein. Pas plein façon « il reste peu de places ». Plein façon endroit où les règles cessent de compter et où la géométrie devient une opinion. Voitures en double file, voitures sur les trottoirs, voitures sur les zébras jaunes, voitures garées en diagonale dans des places pensées pour le stationnement parallèle.

Il y a un SUV blanc. C’est toujours un SUV blanc. Il occupe une place et demie avec un naturel presque poétique, comme s’il était né ainsi et que c’était nous qui étions hors d’échelle. Un peu plus loin, une Panda est coincée si près d’un pilier que je me demande, sérieusement, si le conducteur a déjà prévu la sortie par le coffre. Peut-être est-ce une feature.

18:37. Je fais un premier tour. Rien. Deuxième tour. Rien. Troisième tour.

Une dame est en train de charger ses courses. Je m’arrête, je mets le clignotant. J’attends. Elle charge un sac. Puis un autre. Puis range les sacs. Puis prend le téléphone. Puis parle au téléphone. Puis cherche les clés. J’attends.

Derrière moi, une file se forme. Quelqu’un klaxonne. La dame me regarde comme si je l’agressais. Et je me rends compte qu’à cet instant je fais exactement ce que je déteste quand les autres le font : je transforme un geste banal en petit bras de fer.

18:43. Je me gare. Il m’a fallu neuf minutes pour arrêter la voiture. Les courses en demanderont sept. Le ratio est faux. Le ratio est toujours faux.

La guerre civile à basse intensité

Le parking du supermarché à 18:30 est ce point étrange où la société civile se dissout sans bruit. Rien d’éclatant, pas un événement précis. C’est plutôt un changement d’atmosphère. Comme si on entrait dans une pièce et que quelqu’un avait baissé le niveau de confiance mutuelle.

Des gens qui dans la vie normale sont polis, raisonnables, fonctionnels — qui disent merci, qui tiennent la porte, qui font le tri sélectif —, entrent dans le parking et deviennent prédateurs. Tout contrat social s’évanouit. C’est la loi du plus gros, du plus rapide, du plus effronté.

Les règles sont là. Les flèches, les bandes, les panneaux. Mais à cette heure, elles deviennent des suggestions. Des décorations. De l’art abstrait sur l’asphalte.

Et puis il y a lui, le chariot.

Le chariot de courses est l’emblème parfait, parce que c’est un objet simple, avec un endroit précis où il devrait finir : le rangement. Il est à dix mètres. Dix. Et pourtant un pourcentage gênant de chariots finit abandonné au milieu du parking, à occuper une place de voiture, ou à rouler doucement vers ta portière avec l’inéluctabilité d’un destin grec.

Je me demande toujours qui est la personne qui laisse le chariot là. Et puis je pense que je le sais peut-être. Probablement la même personne qui au bureau écrit des mails sur la responsabilité sociale d’entreprise. Ou peut-être moi, un mauvais jour, quand je me dis « quelqu’un le prendra ».

J’ai une théorie, un peu méchante mais difficile à chasser : la façon dont une personne traite le chariot de supermarché est l’un des tests moraux les plus fiables qui existent. Pas de punition pour qui l’abandonne, pas de récompense pour qui le ramène. Pur libre arbitre. Et le parking, chaque soir à 18:30, te montre combien vaut le libre arbitre de ta communauté.

Le SUV et le mensonge

Parlons du SUV.

Pas de tous les SUV. Du SUV urbain. Celui acheté pour aller au supermarché, conduire les enfants à l’école, faire le trajet maison-bureau sur des routes goudronnées. Le SUV qui ne verra jamais une piste, ne traversera jamais un gué, n’affrontera jamais rien de plus rude que le ralentisseur devant l’école primaire.

Le SUV urbain est un objet conçu pour un contexte qui n’existe pas dans la vie de qui l’utilise. C’est l’équivalent automobile d’acheter un sac d’alpinisme pour aller au bureau. Et pourtant on l’achète quand même, parce que le SUV vend une histoire : sécurité, domination, contrôle.

Tu es en hauteur, tu vois tout, tu es protégé. « Protégé de quoi », personne ne le dit vraiment. Peut-être du trafic que le SUV lui-même contribue à créer, vraisemblablement.

Dans le parking, pourtant, le SUV révèle sa nature. Trop large pour des places pensées dans les années 90, quand les voitures étaient plus petites et les gens, allez savoir, moins ambitieux. Il n’entre pas. Il dépasse. Il envahit la place voisine.

Et il y a des détails qui me mettent toujours mal à l’aise. Comme le fait que le conducteur ne voit souvent pas un enfant qui passe derrière, parce que le capot est à hauteur d’adulte. Alors arrive la caméra de recul pour compenser. Un problème technologique pour résoudre un problème que la technologie a créé. Un cercle parfait d’absurdité.

Mais le SUV, à bien y penser, n’est pas qu’une erreur du consommateur. C’est une erreur de design. Quelqu’un a conçu un véhicule urbain qui ne fonctionne pas dans l’espace urbain. Quelqu’un l’a vendu à des gens qui vivent dans des villes aux rues étroites, aux parkings petits, aux trottoirs où les piétons devraient, en théorie, avoir la priorité.

Le produit n’est pas faux pour qui l’a conçu. Il est faux pour le contexte dans lequel il existe.

Et ça, si vous faites du logiciel, ça vous parle.

Concevoir pour le mauvais contexte

Je conçois du logiciel. Et je reconnais dans le parking la même erreur que je vois dans tant de projets ratés : concevoir pour l’utilisateur idéal au lieu de l’utilisateur réel.

Le parking du supermarché a été conçu par quelqu’un qui pensait, j’imagine : les gens arriveront en bon ordre, se gareront entre les lignes, couperont le moteur, feront leurs courses, reviendront, repartiront. Un flux linéaire, rationnel, propre. Comme un diagramme.

Les gens ne sont pas un diagramme.

Les gens arrivent tous à 18:30 parce qu’ils sortent tous du travail à la même heure. Ils arrivent énervés parce que la circulation a été infernale. Ils arrivent avec une voiture trop grande parce que le marché leur a dit que grand c’était mieux. Ils arrivent téléphone à la main parce qu’ils appellent à la maison pour savoir s’il faut aussi du parmesan. Ils arrivent avec des enfants qui hurlent à l’arrière.

Ils arrivent, en somme, en êtres humains.

Et le parking n’est pas conçu pour des êtres humains. Il est conçu pour des automobiles. Ce qui est une autre chose.

C’est la même erreur qu’on fait dans le logiciel : on conçoit pour le happy path. L’utilisateur qui lit les instructions, qui suit le flux, qui remplit chaque champ, qui clique où il faut. Puis arrive l’utilisateur réel, fatigué, distrait, avec trois onglets ouverts et le chef qui lui écrit sur WhatsApp, et le système s’effondre.

Pas parce que l’utilisateur est bête. Mais parce que le design n’a pas prévu que l’utilisateur fût humain.

Le parking du supermarché est une interface utilisateur. Une mauvaise interface utilisateur. Et chaque soir à 18:30 elle plante.

La ville que nous avons choisie

À un moment je me rends compte que je rejette la faute sur le parking, sur le SUV, sur la dame au téléphone, sur les chariots errants. Mais le parking, au fond, n’est qu’un symptôme.

La maladie, c’est la ville.

Nous avons construit les villes autour des automobiles. Pas autour des personnes, pas autour des enfants, pas autour des personnes âgées, pas autour de qui marche ou roule à vélo. Autour des automobiles.

Chaque décision urbanistique des dernières décennies semble une réponse à la même question : où mettons-nous les voitures ? Les rues élargies pour les voitures. Les centres-villes vidés pour faire des parkings. Les quartiers résidentiels construits loin de tout, pour qu’acheter du pain te demande, devine, la voiture.

À Pescara, on le voit bien. Une ville plate, parfaite pour le vélo, où presque personne ne fait de vélo. Une ville en bord de mer où le front de mer est un parking huit mois sur douze. Une ville où le corso principal a été piétonnisé et où les gens ont protesté parce qu’« on ne peut plus se garer devant la boutique », comme si le droit de se garer sous la vitrine figurait dans la Constitution.

Nous avons conçu la ville pour le mauvais utilisateur. Et maintenant nous nous étonnons que le bon utilisateur, celui qui y vit, ne s’y sente pas à l’aise.

Le plus triste, peut-être, c’est qu’on s’y est habitués. Pas qu’on aime ça. Mais on le considère comme normal. Comme s’il était inévitable qu’acheter quatre choses demande une petite épreuve d’endurance.

18:51

Je sors du supermarché avec mon sac. Lait, pain, tomates, lessive. Sept minutes nettes, comme prévu.

Je retourne à la voiture. Un chariot est appuyé contre ma portière. Je le déplace. Un SUV s’est garé tellement près que je dois entrer côté passager et enjamber le levier de vitesse. Je le fais. Avec le lait à la main. Avec la dignité qu’il me reste.

Je sors du parking. Il me faut quatre minutes parce que quelqu’un a bloqué la sortie en attendant une place. Cette chose me met hors de moi à chaque fois, et à chaque fois je me dis que ce n’est qu’un détail. Mais ensuite je pense que les systèmes mal conçus sont faits de détails, de petits goulots d’étranglement, de micro-égoïsmes qui deviennent des macro-problèmes.

J’arrive à la maison.

Temps total pour quatre produits : trente-sept minutes. Dont sept de courses et trente d’infrastructure.

Trente minutes jetées dans un système mal conçu. Chaque jour, des millions de personnes, la même expérience. Multipliez le temps perdu par le nombre de personnes par le nombre de jours et vous obtenez un chiffre que personne ne veut calculer parce qu’il serait trop déprimant.

Et pendant ce temps, le supermarché a son app pour les courses en ligne. Elle fonctionne très bien, paraît-il. Il suffit de la télécharger, de créer un compte, d’accepter les conditions d’utilisation…

Ah non. Ça, c’était la machine à laver.

Même logique, pourtant. Toujours la même logique. Des projets faits pour un monde ordonné, et puis jetés dans la vraie vie, qui ordonnée ne l’est jamais. Et c’est peut-être exactement le point que je rapporte à la maison, avec le pain et la lessive : ce n’est pas que nous soyons devenus méchants. C’est que nous nous mouvons dans des espaces qui font sortir le pire, parce qu’ils ont été pensés pour une version de nous qui n’existe pas.

Et demain, à 18:30, j’y retomberai probablement. Avec le même plan. Et le même parking.

Avec l’IA il se passe la même chose. Et pourtant, autour de moi, je vois beaucoup d’entreprises réagir comme s’il s’agissait d’une mise à jour ordinaire. Un add-on. Un plugin.

Et c’est peut-être un problème.

Le piège du « mettons un peu d’IA »

C’est devenu presque un réflexe. Un chatbot dans le service client. Un résumé généré dans le tableau de bord. Un copilot dans une sidebar. Une recherche « plus intelligente ».

Ce sont des choses utiles, vraiment. Je ne veux pas faire le puriste qui snobe ce qui marche. Mais je me demande si elles ne sont pas, en même temps, des choses profondément conservatrices. Comme mettre un moteur électrique sur une calèche et appeler ça révolution. La calèche reste une calèche, ce qui change c’est ce qui la tire.

Cette dynamique je l’ai déjà vue. En 2007 elle s’appelait « mobile ».

Quand l’iPhone a explosé, beaucoup d’entreprises ont pris leurs sites desktop et les ont « adaptés ». Responsive, boutons plus petits, colonnes réordonnées, menu hamburger, et voilà. Techniquement correct. Stratégiquement… presque sans intérêt.

Parce que ceux qui ont gagné ne sont pas ceux qui ont adapté l’ancien au nouveau, mais ceux qui ont tout repensé.

Uber n’est pas un site de taxi rendu responsive. C’est un produit qui sans GPS, connexion always-on et appareil dans la poche n’aurait pas eu de sens.

Instagram n’est pas Flickr en miniature. C’est un langage visuel né pour le mobile, pensé pour s’utiliser à une main, en marchant.

WhatsApp n’est pas un mail sur smartphone. C’est de la communication reconçue autour d’un postulat : l’appareil est personnel, toujours avec toi, toujours connecté.

Aucun de ces produits ne serait né de la mentalité « bricolons ce qui existe ». Ils sont nés d’une autre question.

La bonne question

La question n’est pas : comment j’ajoute de l’IA à mon produit ?

La question est : si je concevais ce produit aujourd’hui, en sachant que la moitié des interactions passera par des agents IA, en quoi serait-il différent ?

Cela ressemble à une nuance, mais ça ne l’est pas.

Pendant vingt ans nous avons conçu du logiciel à partir d’un postulat presque invisible : un être humain s’assoit devant un écran et interagit avec une interface graphique. Il clique, défile, remplit des champs.

Ce postulat ne disparaîtra pas, mais il cessera d’être le seul. Et quand il cesse d’être le seul, beaucoup de choix qui paraissaient « normaux » deviennent soudain arbitraires.

Pensez à toutes les actions quotidiennes que nous faisons dans des produits numériques que, avec les bonnes API et les bonnes permissions, un agent pourrait faire à notre place. Réserver un restaurant. Comparer des devis. Remplir un formulaire. Déplacer un rendez-vous. Analyser un rapport. Faire les courses. Payer une facture.

Ce n’est pas de la science-fiction. Les modèles de langage savent déjà gérer des flux complexes. Le goulot d’étranglement n’est souvent pas l’IA. C’est la façon dont les produits sont construits.

Beaucoup de logiciels ont été conçus pour être regardés et cliqués. Pas pour être compris et orchestrés.

Et cette différence est, à mon avis, énorme.

D’interfaces à contrats

Là, ça devient concret.

Pendant des années, le « produit » a été l’interface. L’UI était le produit. Tout le reste — backend, API, base de données — était de l’infrastructure au service des écrans. Designers qui dessinaient des écrans, développeurs qui les implémentaient, product managers qui mesuraient les conversions sur les boutons.

Dans le paradigme qui arrive, le produit devient le contrat.

API claires. Documentation structurée. Schémas de données cohérents. Capabilities exposées de façon sémantiquement riche. Erreurs qui expliquent ce qui s’est passé et quoi faire. Contrats stables.

L’interface graphique ne disparaît pas, mais change de rôle. Elle devient un client du produit, pas le produit. Un client parmi d’autres.

Et, paradoxalement, c’est une bonne nouvelle. Parce qu’une API pensée pour être consommée par des agents IA vous force à faire du bon logiciel. Elle vous force à être clair. Cohérent. Fiable. Composable.

L’IA ne baisse pas la barre. Elle la lève.

De feature à capability

Il y a un changement de mentalité qui touche au cœur du product management.

La mentalité traditionnelle est feature-driven. Ajoutons la feature X. Il faut cinq écrans, trois endpoints, deux tables. Wireframes, user stories, critères d’acceptation. Et puis un flux presque toujours linéaire : l’utilisateur arrive en A, clique B, remplit C, obtient D.

La mentalité AI-native, en revanche, tend à être capability-driven.

Vous ne concevez pas un parcours. Vous concevez une brique. Une capability orchestrable par n’importe qui : un humain via GUI, un agent via API, un autre système via webhook. Et souvent elle sera combinée à d’autres briques de manières que vous n’aviez pas prévues.

C’est plus puissant, mais aussi plus difficile. Cela demande de penser en termes de contrats, d’invariants, de préconditions et postconditions. Cela demande une ingénierie plus mature.

Et là, je l’avoue, je m’enthousiasme un peu. Parce que c’est comme si la pression de l’IA rendait enfin inévitables ces best practices que tant d’ingénieurs ont répétées des années, souvent dans le vide.

Le paradoxe de l’ouverture

Il y a un autre aspect que je trouve contre-intuitif.

Pendant des années, le modèle dominant a été le lock-in. Données fermées, exports difficiles, walled garden. « C’est comme ça qu’on défend l’avantage compétitif. »

Dans un monde d’agents IA, la fermeture risque de devenir un handicap.

Un agent travaille mieux avec des services qui collaborent. Qui exposent des données structurées. Qui ont des API documentées. Qui permettent l’interopérabilité. Si un service est opaque et difficile à intégrer, l’agent tendra à le contourner et à choisir des alternatives plus composables.

Et il y a là un paradoxe magnifique, presque poétique : pour retenir les utilisateurs, il faut les laisser libres de partir.

Cela déplace aussi le terrain de jeu pour les petites entreprises. Parce que sur l’ouverture, la qualité des API, la documentation, la propreté des contrats, une PME agile peut rivaliser. Parfois elle peut même faire mieux qu’un mastodonte plein de legacy.

La compliance comme superpouvoir

Cette partie me tient particulièrement à cœur, parce que c’est le terrain sur lequel je me retrouve tous les jours.

RGPD, AI Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Souvent vécus comme un coût. Une nuisance. Une taxe sur le business.

Moi, de plus en plus, je les vois différemment.

Dans un écosystème médié par des agents IA, la confiance devient une ressource computationnelle. Pas seulement du marketing. Un input dans les décisions.

Si un agent doit choisir entre deux services semblables, il tendra à préférer celui qui est vérifiable. Celui avec un SBOM transparent. Audit trail complet. Privacy by design documentée. Conformité déclarée et démontrable.

Dans ce sens, la compliance cesse d’être seulement un coût à porter et devient un signal de qualité lisible par les machines. Un différenciateur compétitif.

Je sais que ça sonne presque étrange dit comme ça, mais je pense que c’est vrai : la compliance peut devenir un superpouvoir.

Et peut-être que l’Europe, avec toute sa bureaucratie qui en fait souffler beaucoup, construit un terrain où la confiance est computable. Si vous savez la transformer en architecture, ce n’est pas un frein. C’est un avantage.

Là où tout cela devient concret

Je pourrais m’arrêter ici, sur le plan des idées. Mais ce ne serait pas honnête, parce que pour moi cette transition est concrète, quotidienne.

Quand nous migrons un produit, nous ne « modernisons pas seulement le stack ». Nous préparons un service à un futur où les agents interagiront avec ces systèmes autant que les humains.

Quand nous construisons une plateforme SBOM pour gérer les dépendances logicielles, nous ne faisons pas seulement de la compliance. Nous créons une couche de confiance vérifiable.

Quand nous déplaçons le centre de gravité vers le développement guidé par les spécifications, où la spec est le produit primaire et le code un artefact dérivé, ce n’est pas seulement une méthodologie. C’est une façon de travailler dans laquelle l’IA peut être un vrai partenaire, pas un gadget.

À un moment, vous vous apercevez que tout se tient. Architecture propre, documentation rigoureuse, compliance by design, API-first, spécifications comme objet principal. Ce sont les facettes d’une même idée.

Dans le monde qui vient, la clarté est puissance.

Le vrai risque

Le plus grand risque, aujourd’hui, n’est pas de faire des « choses mauvaises » avec l’IA.

C’est de faire les bonnes choses, mais dans l’ancien paradigme.

C’est ajouter un chatbot au lieu de repenser l’architecture de l’interaction. C’est mettre des suggestions IA dans une interface qui ne devrait peut-être pas exister sous cette forme. C’est utiliser l’IA pour écrire du code plus vite sans se demander si l’on devrait écrire des spécifications plus claires.

Je sais que c’est une position forte. Et je sais aussi que beaucoup d’entreprises obtiennent des résultats réels en ajoutant de l’IA aux produits existants. Je ne dis pas que tout est faux.

Je dis que c’est insuffisant. Que cela risque d’être le jeu d’hier avec les pièces d’aujourd’hui.

Une lettre d’amour à la technologie qui aide

Je clos sur une note personnelle, parce que ce discours, pour moi, n’est pas que stratégie.

J’aime la technologie quand elle aide. Quand elle rend accessible ce qui était exclusif. Quand elle simplifie ce qui était compliqué. Quand elle libère du temps pour ce qui compte vraiment.

Quand je pense à l’IA dans les produits numériques, je ne pense pas, ou en tout cas pas seulement, à des chatbots qui répondent à la place de quelqu’un. Je pense à une personne âgée qui parvient à interagir avec l’administration publique grâce à un agent qui comprend et traduit la bureaucratie. Je pense à un petit entrepreneur qui gère la compliance sans une armée de consultants parce que le logiciel le soutient nativement. Je pense à un médecin qui peut rester avec le patient pendant que la part documentaire est mieux gérée. Je pense à un étudiant en situation de handicap qui trouve une expérience vraiment accessible, pas une case cochée dans un Excel.

Pour y arriver, en revanche, il ne suffit pas d’« ajouter de l’IA ». Il faut repenser les produits autour d’un monde où humains et agents coexistent.

Ce n’est pas facile. Cela exige de remettre en cause des présupposés que nous tenions pour acquis. Cela exige des compétences nouvelles et une certaine humilité. Cela exige la question la plus inconfortable de toutes : si je partais de zéro aujourd’hui, ferais-je comme ça ?

Mais c’est un beau défi. De ceux qui donnent envie de se mettre au travail.

Parce que de l’autre côté, peut-être, il y a un logiciel plus utile, plus accessible, plus fiable. Et, dans un sens non banal, plus humain.