L’audit clinique
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.
Ce qu'il faut retenir
La « spécification fantôme » n’est pas une pathologie rare : c’est la condition ordinaire de tout système qui vit assez longtemps. Le document signé reste identique pendant que le système devient autre chose.
Sous le nouveau régime européen — PLD révisée avec transposition au 9 décembre 2026, CRA pleinement applicable au 11 décembre 2027, AI Act sur les systèmes à haut risque — le logiciel n’est plus jugé seulement sur ce qu’il fait, mais sur la cohérence entre la promesse écrite et le comportement observé. La spécification devient l’actif juridiquement pertinent.
L’industrie a le versionnage atomique, le blame, les tests, la code review, la CI, les branch protection pour le code. Pour la spécification elle a la signature en bas de page et l’archive. La culture agile a lu « working software over comprehensive documentation » comme une abolition, pas comme un recadrage.
La dette de spécification est une sous-catégorie de la dette technique avec une dynamique économique différente : on ne la paie pas en mensualités, on la paie en une seule traite, en général quand un audit, un procès ou un incident vous force à la regarder — et presque toujours plus chère que la somme des mensualités évitées.
La spécification se détache du code de deux manières : comme Unix, où elle devient culture vivante et traverse les réécritures, ou comme l’AIPD archivée, où elle devient un monument et meurt lentement. La différence n’est pas dans l’objet — elle est dans la pratique de qui le maintient.
Questions & réponses
Qu'est-ce que la « dette de spécification », et en quoi diffère-t-elle de la dette technique classique ?
La dette de spécification, c’est la distance qui s’ouvre, semaine après semaine, entre le document qui décrit un système (AIPD, ADR, évaluation des risques AI Act, exigences contractuelles, documentation technique CRA) et le système réellement en exploitation. Elle diffère de la dette technique classique par son économie, pas par son concept. La dette technique classique a des incitations naturelles au remboursement, parce qu’elle vous ralentit chaque jour. La dette de spécification ne ralentit pas le développement, ne génère pas de bugs visibles, n’entrave pas l’onboarding — jusqu’à ce qu’un événement la rende contraignante : un audit, un incident, un procès, une demande d’accès aux données. À ce moment-là, elle se paie en une seule traite, en heures d’avocats et de consultants, et presque toujours plus chère que les mensualités évitées.
Qu'est-ce qui change avec la Product Liability Directive révisée et le Cyber Resilience Act pour qui développe du logiciel ?
Ce qui change, c’est le statut évaluatif du logiciel. La PLD révisée, adoptée fin 2024 avec une transposition due pour le 9 décembre 2026, inclut explicitement le logiciel dans la notion de produit et applique la responsabilité objective. Le « défaut » ne coïncide pas avec le « bug » : il coïncide avec l’écart entre ce que l’on pouvait légitimement attendre et ce que le produit a réellement fait. Les attentes légitimes se reconstruisent à partir de la documentation technique, des matériaux commerciaux, des évaluations de risque. Le CRA, pleinement applicable à partir du 11 décembre 2027, renforce la même logique du côté de la sécurité : la conformité se démontre par une documentation technique vivante. La spécification cesse d’être une annexe et devient une partie constitutive de l’évaluation.
Le spec-driven development et les spécifications exécutables (BDD, OpenAPI, TLA+) ne résolvent-ils pas déjà le problème ?
Ils résolvent la synchronisation initiale entre la spécification et le code, et c’est un gain réel. Ils ne résolvent pas la dérive ultérieure. Une fois le système en production et modifié en réponse aux demandes, aux incidents, aux changements d’environnement, la spécification formalisée peut être mise à jour ou ne pas l’être, et les incitations pratiques jouent contre la mise à jour. Les suites Gherkin restent plus résistantes qu’une AIPD parce qu’elles sont du code, donc soumises aux incitations du code, mais sous pression de delivery elles sont sautées, marquées pending, supprimées. Il y a aussi un second problème : les spécifications exécutables couvrent bien le comportement fonctionnel, et presque rien de ce que la nouvelle compliance européenne demande de documenter — évaluations de risque, choix architecturaux, finalités des traitements.
Pourquoi la culture d'ingénierie du logiciel en est-elle venue à traiter la spécification comme un sous-produit ?
Pour des raisons historiques précises. La culture agile, depuis le Manifeste de Snowbird en 2001, a grandi en opposition à la culture de la documentation waterfall. La formulation originale était prudente — « working software over comprehensive documentation » avec la note de fin « while there is value in the items on the right, we value the items on the left more » — mais la lecture industrielle des deux décennies suivantes a été plus drastique que le texte. La documentation compréhensive est devenue synonyme de documentation superflue. Cela fonctionnait parce que le logiciel était jugé sur des critères fonctionnels et commerciaux. Cela ne fonctionne plus, parce que le cadre normatif charge la spécification de valeur de manière asymétrique, et la culture d’ingénierie ne l’a pas encore métabolisé.
Concrètement, à quoi ressemblera la pratique dans cinq ans pour une équipe qui a métabolisé le problème ?
L’AIPD vivra comme un fichier YAML dans un repository protégé, avec historique des versions, auteurs des modifications, processus d’approbation par pull request. Quand un développeur introduira un nouveau traitement de données personnelles, une pipeline d’analyse statique détectera le flux et marquera la pull request comme « DPIA-impacting », bloquant le merge jusqu’à l’approbation du DPO sur la modification correspondante du document. Les évaluations de risque AI Act suivront un mécanisme analogue, avec des drift detectors comparant le modèle en production aux métriques déclarées. Les SBOM se mettront à jour automatiquement à chaque build. La compliance deviendra maintenance continue intégrée au rythme du développement, plus archéologie reconstructive déclenchée par un événement.
La dette de spécification ne concerne-t-elle que les entreprises très régulées ?
Non, mais ce sont elles qui la paieront en premier. Quiconque développe du logiciel en Europe entre dans au moins l’un des périmètres (PLD pour tout produit numérique, CRA pour les produits avec éléments numériques, RGPD pour tout traitement de données personnelles, AI Act pour les systèmes des catégories à risque). La différence entre secteurs tient au calendrier et à la sévérité de la confrontation, pas à l’existence du risque. La question à se poser n’est pas « suis-je concerné ? », c’est « quand arrivera le premier événement qui me forcera à confronter la spécification au système, et dans quel état me trouvera-t-il ? ».
L'auteur
