AIPD comme genre, pas comme formulaire

Le template EDPB est arrivé publiquement la semaine dernière. Je l’ai ouvert pour la première fois dans le train entre Pescara et Rome, un PDF d’une quarantaine de pages qu’il me semblait connaître avant même de le lire, avec cette attention distraite qu’on réserve aux documents dont on croit déjà tout savoir. L’AIPD, je la fréquente depuis des années, j’en ai aidé à rédiger des dizaines, je m’étais habitué à la considérer comme un objet stable : un formulaire, une checklist, un artefact de compliance à remettre au DPO et à archiver. En ouvrant le nouveau template, j’avais entre les mains une chose familière et légèrement altérée, comme quand on rentre dans un appartement où l’on a vécu jeune et que quelqu’un a déplacé les meubles sans le dire. Quelque chose m’agaçait sans que j’arrive à le nommer.

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.

L'auteur

Andrea MargiovanniCompliance UE

Je travaille aux côtés d'équipes qui conçoivent des systèmes sous AI Act, CRA, NIS2, RGPD. La règle n'est pas une liste à cocher : c'est une contrainte architecturale, à intégrer dès la conception, pas après.

Voir le parcours →