Le droit de savoir ce qui a changé

Une décision publique n'est jamais seulement sa phrase finale. Elle est la règle, les données, le système, le flux de travail et l'autorité humaine qui ont...

Le droit de savoir ce qui a changé

Le document qui n’était pas là

En mars 2024, la Médiatrice européenne a ouvert une enquête sur la manière dont la Commission européenne décide d’utiliser l’intelligence artificielle et l’utilise. Les questions portaient sur trois domaines ordinaires du travail administratif : l’analyse des retours du public, la détection d’éventuelles infractions aux règles de concurrence et le traitement des plaintes. La Médiatrice s’est renseignée sur l’automatisation, la décision de recourir à l’IA, la transparence autour de cette décision et la responsabilité. L’avis public ne décrivait pas un échec spectaculaire. Il décrivait la nécessité de comprendre comment une institution prend et encadre une décision.

Cette distinction compte. Lorsqu’on demande à une autorité pourquoi elle a utilisé un système, la réponse utile est rarement le communiqué de presse final. Un examinateur doit savoir quelle finalité a été approuvée, quelle règle et quelle définition des données étaient en vigueur, quelle version du système a été utilisée, ce que l’opérateur pouvait voir et quelle personne avait le pouvoir d’accepter ou de rejeter le résultat. L’explication est un parcours dans le temps. Si ce parcours a été écrasé par le présent, l’institution peut offrir un récit plausible, mais pas nécessairement celui qui était vrai au moment où la décision a été prise.

Les organisations publiques comprennent ce problème depuis longtemps. Un permis, une note de politique, une entrée de registre, un dossier judiciaire et une décision ministérielle tirent tous leur sens de leur histoire. Une loi a une date d’entrée en vigueur. Un document public a un créateur et un contexte. Une correction ne devient pas silencieusement le texte original. Les systèmes numériques n’ont pas supprimé ces faits. Ils les ont dispersés entre les versions, la configuration, les flux sources, les files d’attente, les invites, les règles d’accès et les services des fournisseurs. Le statut final peut encore être visible. Le chemin qui lui a donné son autorité peut avoir disparu.

Le droit de savoir ce qui a changé n’est donc pas une demande de chaque frappe de touche. C’est une revendication sur la mémoire responsable. Les personnes concernées par une décision publique devraient pouvoir apprendre quelle version du monde pertinent l’a produite, dans les limites fixées par la vie privée, la sécurité et d’autres intérêts légitimes. Les institutions ont besoin du même savoir pour corriger leurs erreurs, répondre aux recours et expliquer leur propre conduite. Une histoire n’est pas une annexe décorative à une décision. Elle fait partie de ce qui fait d’une décision une décision plutôt qu’un résultat orphelin.

Un journal des modifications est une courtoisie ; l’histoire est une preuve

Les équipes logicielles connaissent bien les journaux des modifications. Une note de version indique qu’une interface a été améliorée, qu’un bug a été corrigé ou qu’une dépendance a été mise à jour. Un bon journal des modifications est une communication utile. Il aide les utilisateurs à décider s’ils doivent mettre à niveau et donne aux mainteneurs un compte rendu public de leur travail. Il n’est pas, en soi, un registre de décisions. Il décrit normalement ce que l’éditeur considère comme important. Il ne promet pas de reproduire l’état de chaque dossier passé par le système.

L’historique des décisions a un autre rôle. Il doit répondre à une question sur un acte particulier à un moment particulier. Quelle version de la règle d’éligibilité a été appliquée à cette demande. Quelle définition du revenu était disponible lorsque le score a été calculé. Quel modèle et quel calibrage ont produit le classement. Quel parcours de flux a placé le dossier devant cet examinateur. Quelles preuves l’examinateur a-t-il vues. Quelle notification a été envoyée. La réponse peut renvoyer à un journal des modifications, mais elle ne peut pas s’y arrêter. Une note de version décrit un changement en général. Un historique relie un changement à une décision concernée.

C’est pourquoi une ligne verte indiquant « mis à jour » ne suffit pas. Mis à jour quand, sous quelle autorité, avec quelle date d’entrée en vigueur et pour quels dossiers. Une entrée indiquant « politique améliorée » laisse ouverte la question de savoir si l’ancienne politique reste pertinente pour un recours, si un résultat antérieur doit être réexaminé et si le changement a été déployé partout en même temps. Un historique porte des relations, pas des adjectifs. Il relie un objet à son état précédent, à son successeur, à la raison de la transition et à la période pendant laquelle l’état était valide.

Il existe une différence pratique dans la manière dont les deux registres sont rédigés. Un journal des modifications peut être écrit après le travail d’ingénierie, car son lecteur a besoin d’un résumé. Un historique des décisions doit être créé au fur et à mesure que le travail se déroule, ou à partir de documents créés à ce moment-là. Les notes rétrospectives sont utiles, mais elles relèvent de l’interprétation. Elles ne peuvent pas remplacer en toute sécurité le contexte contemporain. La différence n’a rien de romantique. Un registre aide les gens à suivre l’évolution d’un produit. L’autre permet à une institution de se porter garante d’un acte.

Un historique des décisions relie le résultat aux versions qui l’ont rendu possible, puis laisse une voie pour la correction.

Ce qui a changé est rarement une seule chose

Lorsqu’une décision est réexaminée, les gens commencent souvent par le composant le plus visible. Le modèle a changé. Le formulaire a changé. La page de politique a un nouveau titre. Le fournisseur a déployé une mise à jour. Ces affirmations peuvent toutes être vraies et pourtant manquer le changement déterminant. Une décision publique est assemblée à partir de couches qui évoluent à des vitesses différentes, avec des propriétaires différents et des idées différentes de ce qui constitue une version.

La couche de données peut changer lorsqu’une autorité source corrige l’adresse d’une personne, une définition statistique, un code de classification ou une table de référence. Un pipeline peut changer la manière dont il joint les enregistrements ou gère les valeurs manquantes. Un index de récupération peut être reconstruit à partir d’une collection différente. Un cache peut conserver une interprétation plus ancienne après que la source a évolué. Aucune de ces modifications ne doit être appelée une modification d’IA pour modifier le résultat d’un flux de travail assisté par IA.

La couche de règles présente également plus d’une surface. Il peut y avoir une loi, une politique interne, une instruction écrite, un seuil dans la configuration, une table d’exceptions et une note de formation pour les examinateurs. La politique publiée peut rester mot pour mot tandis qu’un seuil change dans un fichier de déploiement. Inversement, une politique peut changer tandis que l’ancienne règle continue de s’appliquer dans une région parce que la version a été déployée progressivement. Une personne affectée par le résultat ne devrait pas avoir à savoir quelle équipe possède quel fragment avant de demander ce qui s’est passé.

La couche système comprend le modèle, ses poids ou son paquet, son invite ou son modèle, sa configuration de récupération, ses paramètres de sécurité et le logiciel qui l’appelle. La couche de flux de travail comprend la file d’attente, le routage, les autorisations, l’écran et la transmission. L’action d’un examinateur dépend de ce que l’interface présente comme pertinent et de ce qu’elle rend possible. La couche de décision comprend le résultat, l’explication, l’avis, l’effet en aval et tout recours. L’historique des versions est la discipline consistant à nommer les couches qui ont compté, et non une tentative de faire accomplir une magie institutionnelle à un numéro de version géant.

Les archives savent déjà que les versions comptent

The Dutch National Archives uses a definition that is refreshingly plain: a historical version is a previous version of an information object. Its guidance gives ordinary examples. A note can move from draft to concept to adopted text. A law can be amended. Information can be added to a permit application. A person can move, changing the value in a register. Depending on the importance of the change, earlier versions may need to remain accessible. That is not a new demand created by machine learning. It is recordkeeping applied to digital work.

The same guidance makes two points that are easy to lose in a discussion about cloud systems. Government information is covered regardless of its technical form. It can be a database entry, a webpage, a message or a video, not only a signed paper. And the place where the information is stored does not settle whether it needs to remain accessible. A supplier’s server does not make the record less relevant to the institution that used it. A private laptop does not turn official information into a personal souvenir.

These principles are useful for AI because AI hides ordinary information inside technical surfaces. A feature definition, a model card, an evaluation notebook, a prompt template, a routing rule or an approval message can determine how a public service behaves. Calling them configuration does not remove their administrative effect. It simply makes their history harder to see. Archive thinking asks a better question: what information was made or received while the organisation carried out its task, and what must remain usable so that the task can later be understood.

Archiving is not the same as keeping everything. The National Archives describes choices about which historical versions remain accessible. A draft may not need the same treatment as an adopted decision. A personal field may need a different retention path from a legal basis. The point is to make the choice deliberately and record the reason. Deleting history can be legitimate. Deleting it without knowing whether it is the history of an affected decision is merely a fast way to lose the argument later.

GDPR asks for responsibility, not archaeology

The General Data Protection Regulation does not prescribe a single version-control product for public authorities. It does something more demanding. Article 5(2) places responsibility on the controller and requires the controller to be able to demonstrate compliance with the data protection principles. Article 24 describes responsibility for appropriate technical and organisational measures. Article 30 requires records of processing activities in the circumstances set out by the Regulation. Together, these provisions make accountability a property an organisation must be able to show, not only a belief it can state.

A record of processing activities is not a complete decision history. It normally describes a processing operation at an organisational level: its purpose, categories of data and people, recipients, retention and security measures. That record answers a different question from which source value was active in an individual case. But the accountability principle creates a clear reason to preserve the relationships that let the organisation demonstrate what it did. Version history is one way to make those relationships inspectable. It supports the legal duty; it does not magically satisfy it.

Cette distinction permet d’éviter deux erreurs courantes. La première consiste à traiter un registre comme s’il s’agissait de la relecture de chaque décision. Une page qui indique que l’organisation traite des données d’adresse pour la prestation de services ne peut pas prouver quelle adresse a été utilisée pour un avis particulier. La seconde consiste à traiter des journaux détaillés comme s’ils constituaient automatiquement des preuves légales. Un journal peut contenir plus de données personnelles que ne l’exige la finalité, être conservé plus longtemps que justifié, ou être accessible à des personnes qui n’ont pas besoin de le consulter. La responsabilité inclut la minimisation et la sécurité. La mémoire doit être conçue avec une sortie autant qu’avec une entrée.

Pour les équipes qui développent ou achètent des systèmes dotés d’IA, l’implication pratique consiste à définir le plus petit enregistrement durable qui puisse répondre à la question prévisible. Il peut s’agir d’une référence à une version source plutôt que d’une copie de l’ensemble de la source. Il peut s’agir d’un dossier de preuves scellé à accès restreint. Il peut s’agir d’un identifiant de règle et d’un intervalle d’application associés à un résultat. Le critère juridique n’est pas de savoir si l’organisation a collecté une quantité impressionnante de télémétrie. Il s’agit de savoir si l’organisation peut démontrer un traitement licite, loyal et limité à des finalités déterminées sans transformer chaque personne en une traînée permanente de données résiduelles.

L’AI Act fait de la mémoire du cycle de vie une exigence

L’AI Act est plus explicite sur la mémoire technique de certains systèmes. L’article 11 exige que la documentation technique d’un système d’IA à haut risque soit préparée avant la mise sur le marché ou la mise en service du système, tenue à jour et suffisamment claire pour permettre aux autorités et aux organismes notifiés d’évaluer la conformité. L’article 12 exige que les systèmes à haut risque permettent techniquement l’enregistrement automatique des événements pendant toute la durée de vie du système, avec une journalisation pertinente pour le risque, la surveillance après mise sur le marché et le fonctionnement. Il s’agit d’obligations liées au cycle de vie, et non d’une demande de brochure de lancement.

Le considérant du règlement sur la traçabilité explique pourquoi. Les informations sur la manière dont un système à haut risque a été développé et fonctionne pendant sa durée de vie sont nécessaires pour évaluer la conformité et surveiller le fonctionnement. La documentation doit couvrir les caractéristiques, les capacités, les limites, les algorithmes, les données, la formation, les tests, la validation et la gestion des risques. Les mots « tenue à jour » font un travail important. Un document qui décrivait un système antérieur mais qui n’a jamais été modifié est une preuve d’un état antérieur, et non une preuve que l’état actuel reste conforme.

L’annexe IV rend concrète la relation entre les versions. La description générale d’un système à haut risque comprend son nom et sa version, ainsi que sa relation avec les versions précédentes, de même que les versions logicielles ou micrologicielles pertinentes et les exigences de mise à jour. Un numéro de version sans la relation n’est qu’une étiquette. La relation permet à un examinateur de comprendre la continuité, le changement et la portée. C’est la différence entre dire qu’il s’agit de la version quatre et montrer quelles hypothèses la version quatre a héritées, remplacées ou rendues obsolètes.

Tout cela ne signifie pas que chaque décision publique relève automatiquement d’un cas d’IA à haut risque au titre du règlement. La classification dépend du système, de la finalité et de l’utilisation décrits par le règlement. Cela signifie que les organisations devraient cesser de considérer la traçabilité comme un confort facultatif réservé aux équipes les plus avancées techniquement. Lorsque la loi exige qu’un système laisse un historique opérationnel utilisable, la question de conception devient pratique : quels événements, versions et autorités le journal doit-il relier pour qu’un examen ultérieur puisse déterminer ce qui s’est passé sans demander à l’équipe d’origine de s’en souvenir.

La décision publique est une pile

Imaginez que vous ouvriez un dossier vieux de deux ans. Le résultat y figure. Le dossier de la personne est désormais plus complet. La page de police a été révisée. Le modèle a été mis à jour deux fois. L’interface dispose d’un nouveau panneau de révision. Le fournisseur a modifié son arrangement d’hébergement. Un gestionnaire affirme que l’équipe a toujours effectué une vérification humaine. Chaque déclaration peut être exacte aujourd’hui. Aucune ne vous dit à quoi ressemblait le dossier lorsque la décision a franchi la frontière entre recommandation et action.

Un dossier défendable traite la décision comme une pile. À la base se trouve l’état source, avec l’identité, la validité, la provenance et les conditions d’accès. Au-dessus se trouvent les règles et seuils applicables. L’état du système identifie le logiciel, le modèle, l’invite, l’index et la configuration. L’état du flux de travail capture le routage, les autorisations, la position dans la file et le rôle humain. Le reçu de décision relie le résultat, la raison, la notification, l’action et la référence en aval. Une correction ultérieure peut alors remonter à travers la pile pour trouver quelles décisions dépendaient de la couche modifiée.

La pile n’a pas besoin d’exposer chaque détail interne à chaque lecteur. Un avis public peut être concis tandis qu’un réviseur autorisé peut inspecter un enregistrement plus profond. Ce qui importe, c’est que l’institution n’ait pas réduit des significations distinctes à un seul champ appelé version. Une version source n’est pas une version de police. Une version de modèle n’est pas une version de flux de travail. Le rôle d’un réviseur n’est pas une raison d’approbation. Les garder séparés permet à l’organisation de partager la bonne explication avec la bonne personne et d’éviter d’inventer une histoire unique qu’aucun système n’a réellement enregistrée.

Cela clarifie également la propriété. Le gestionnaire des données possède la voie de correction de la source. Le propriétaire de la police possède la règle en vigueur. L’équipe technique possède l’artefact de publication. L’équipe des opérations possède le flux de travail et la formation. Le décideur possède l’acte. La gouvernance relie les enregistrements et fixe les limites de conservation et d’accès. Si personne ne peut dire qui possède une couche, l’historique des versions ne sera qu’une liste d’étiquettes sans voix responsable.

Le temps a plus d’une horloge

Les dates sont nécessaires et souvent trompeuses. Une police peut être publiée lundi, prendre effet vendredi et atteindre un service particulier le mardi suivant. Une source peut être collectée à 09:10, corrigée à 11:00 et retraitée à 14:00. Un paquet de modèle peut être approuvé dans un environnement et déployé dans un autre. Un réviseur peut ouvrir un dossier avant un changement et le soumettre après. Un seul horodatage ne peut pas porter toutes ces significations sans aide.

Une bonne historique distingue au moins le moment où un artefact a été créé, le moment où il est devenu effectif, le moment où il a été observé ou capturé, et le moment où il a été utilisé. Elle peut aussi avoir besoin du moment où il a été retiré, corrigé ou découvert comme étant erroné. Ce ne sont pas des distinctions pédantes. Un appel peut dépendre de savoir si un nouveau seuil s’appliquait à une demande soumise avant sa date d’effet, ou si une correction devait modifier un avis déjà émis. La réponse appartient à la loi et à la politique de l’institution, mais les faits exigent des horloges capables de montrer la séquence.

La validité a aussi une portée. Un flux de travail régional peut avoir une version à Rotterdam et une autre à Lyon. Un pack linguistique peut changer selon un calendrier différent de celui d’une règle de décision. Un modèle peut être disponible pour la rédaction mais interdit pour l’action finale. Un enregistrement qui dit actif sans dire où et à quelle fin est une carte qui omet les panneaux de signalisation. La portée transforme une version générique en un fait utilisable.

Les horloges doivent être compréhensibles pour les personnes qui ne maintiennent pas le pipeline de déploiement. Une personne concernée ne devrait pas avoir à apprendre un système de construction pour demander quelle règle a été appliquée. L'enregistrement technique peut conserver des identifiants précis tandis que l'explication publique les traduit en une date d'effet, une politique nommée et une déclaration claire de ce que l'organisation peut encore faire. La précision et le langage simple ne sont pas des adversaires. La précision donne au langage simple quelque chose de solide à dire.

La relecture est une méthode, pas un bouton

Le mot relecture crée une attente dangereuse. Il donne l'impression que l'organisation peut appuyer sur un bouton et regarder le passé se dérouler à nouveau, exactement comme il s'est produit. Parfois, un système limité peut s'en approcher. Le plus souvent, la relecture signifie reconstruire l'état pertinent à partir des entrées, versions, règles, autorisations et actions enregistrées, puis montrer où la reconstruction est exacte et où l'incertitude demeure.

Un enregistrement de relecture authentique sépare ce qui a été observé de ce qui est reconstruit. L'entrée d'origine peut être scellée. Les identifiants de règle et de modèle peuvent être connus. La réponse exacte du service externe peut ne pas avoir été conservée. Une correction ultérieure de la source peut être disponible mais non valide à l'époque. Un examen humain peut avoir un résultat signé mais pas un enregistrement complet de l'écran. La relecture ne doit pas combler ces lacunes avec un nouveau paragraphe confiant. Elle doit les signaler. Un historique partiel honnête est plus utile qu'une fiction complète.

La relecture n'est pas non plus la même chose que la régénération. Demander au système actuel de répondre à l'ancienne question peut démontrer comment le système se comporte aujourd'hui. Cela ne prouve pas ce qu'il a fait à l'époque. Le nouveau résultat peut utiliser un modèle, une source, une politique, une invite, une décision d'acheminement ou une représentation linguistique différents. Cela peut être précieux comme comparaison, à condition que l'enregistrement précise qu'il s'agit d'une comparaison. Une analyse ultérieure ne doit pas se faire passer pour une raison contemporaine.

La relecture est une fenêtre de preuves. Elle montre ce qui peut être récupéré, ce qui a changé et où une correction peut encore circuler.

Un historique rejouable change la qualité d'un recours. La question cesse d'être pourquoi l'organisation croit que cela s'est produit et devient quelles parties de l'historique pouvons-nous vérifier. C'est un point de départ plus sain. Cela donne à l'institution la permission de dire que l'enregistrement est complet sur la règle et le résultat mais incomplet sur une réponse externe. Cela donne à l'examinateur un moyen de décider si la partie manquante est substantielle. Cela donne aux ingénieurs un défaut précis à corriger plutôt qu'une demande vague de plus de transparence.

La transparence a des limites, pas des excuses

Le droit de savoir ce qui a changé n’est pas un droit de recevoir chaque document interne sous sa forme brute. Les organismes publics ont toujours l’obligation de protéger les données personnelles, les informations sensibles pour la sécurité, les informations commerciales confidentielles et l’intégrité des enquêtes. Un historique détaillé peut exposer les données d’une autre personne ou faciliter le contournement d’un contrôle. Une explication publique utile peut donc prendre la forme d’un dossier à plusieurs niveaux : un compte rendu clair de la règle et du calendrier applicables, une référence à un ensemble de preuves vérifiable, et un parcours contrôlé pour un examen plus approfondi.

La superposition ne fonctionne que si le dossier plus profond existe. La rédaction ne remplace pas la conservation de l’original. Si une institution publie un résumé et se débarrasse du matériel qui permettrait à un examinateur autorisé de le vérifier, le résumé devient une affirmation permanente. Le public n’a peut-être pas droit à toutes les pièces jointes, mais une personne ayant un rôle légitime doit pouvoir examiner la base. Le contrôle d’accès peut limiter qui voit un dossier. Il ne peut pas rendre sûr un dossier absent.

Il existe une deuxième limite autour du sens de la transparence. Une étiquette de version n’est pas une explication. Montrer qu’un modèle a changé ne dit pas à une personne concernée si le changement aurait pu modifier le résultat. Montrer une différence de politique ne dit pas quelle partie a été appliquée. Une bonne explication relie le changement à l’acte, indique ce qui a été utilisé et précise le recours disponible. Le but n’est pas de donner à l’institution une apparence de compétence technique. C’est de permettre à une personne de comprendre sa situation.

Les registres publics peuvent aider en rendant visibles des états importants du système avant qu’une personne ne soit obligée de demander. Le règlement sur l’IA inclut des obligations d’enregistrement et de documentation dans des contextes définis, tandis que la pratique nationale des archives traite l’accès et l’utilisabilité future comme faisant partie de la gestion des documents. Ces mécanismes ne remplacent pas l’historique au niveau des cas. Ils constituent la carte environnante. Une carte est précieuse, mais elle ne doit pas être confondue avec la route qu’une personne particulière a parcourue.

L’enquête arrive après que l’interface a changé

L’enquête du Médiateur de 2024 sur l’utilisation de l’IA par la Commission est un exemple utile de la question à laquelle les institutions seront de plus en plus confrontées. La description publique demande comment la Commission décide d’utiliser l’IA, quelles tâches sont automatisées, comment la décision d’utiliser l’IA est prise et comment la responsabilité est maintenue. Elle ne suppose pas qu’un résultat algorithmique constitue la décision entière. Elle interroge le choix administratif entourant le système.

Ce choix a aussi un historique. Une institution peut commencer par un essai, définir un objectif, restreindre un rôle, changer une source, élargir une charge de travail, modifier un parcours de révision et publier une explication ultérieure. Si le dossier ne contient que la politique actuelle et l’interface actuelle, un examinateur doit déduire la limite antérieure. L’institution peut agir de bonne foi et être tout de même incapable de montrer ce qu’elle savait, approuvait ou permettait à l’époque. La bonne foi est une qualité précieuse. Ce n’est pas une machine à remonter le temps.

Les enquêtes montrent aussi pourquoi la tenue des dossiers doit inclure les canaux informels. Les décisions peuvent être façonnées par des documents de travail, des messages, des suiveurs de problèmes, des examens de configuration et des conversations qui ne deviennent jamais une politique formelle. Toutes les phrases n’ont pas besoin d’être conservées en permanence. L’organisation a besoin d’une règle pour identifier quels échanges portent un acte ou un engagement institutionnel, et d’un moyen de préserver ce matériel lorsque sa pertinence devient claire. Sinon, l’historique commence au premier document soigné, après que le choix important a déjà eu lieu.

La réponse n’est pas de transformer l’administration publique en une archive de surveillance de son propre personnel. C’est de rendre explicite l’état conséquent du travail. Une décision doit avoir un propriétaire, une raison, une portée, une date d’entrée en vigueur et un enregistrement du changement qui l’a rendue différente. La discussion informelle peut rester une discussion. Dès qu’elle modifie l’autorité, les données, la politique ou l’action, le résultat pertinent appartient au dossier institutionnel.

Les explications anciennes deviennent particulièrement fragiles avec l’IA

Les explications générées créent un risque particulier, car elles sont suffisamment fluides pour masquer leur date. Un système peut produire un récit cohérent d’une décision ancienne en utilisant le modèle et la politique actuels. Le récit peut ne contenir aucune phrase manifestement fausse. Il peut néanmoins être faux en tant que compte rendu, car l’explication n’existait pas au moment où la décision a été prise et n’a pas été dérivée de l’état qui l’a produite.

La séparation la plus sûre se situe entre les preuves contemporaines et l’interprétation ultérieure. Le dossier contemporain indique ce que le système a reçu, quelle version a agi, quel résultat a été produit, ce que l’humain a fait et quel avis a été envoyé. Un analyste ultérieur peut ajouter une reconstruction, un contrefactuel, une comparaison avec le comportement actuel ou une évaluation de la question de savoir si la règle aurait dû être différente. Ces ajouts sont précieux lorsqu’ils sont étiquetés comme un travail ultérieur. Ils deviennent dangereux lorsque l’étiquette disparaît.

Les scores de confiance présentent le même problème. Un nombre sans son étalonnage, sa population, son seuil et son objectif ne s’explique pas de lui-même. Le nombre a pu être utile pour classer l’attention et n’a jamais été autorisé pour une action finale. Il a pu être montré à un examinateur ou caché derrière une interface. Il a pu être réétalonné après l’événement. Préserver le score tout en perdant les conditions préserve la forme de la preuve et en supprime le sens.

C’est pourquoi l’historique des versions devrait inclure les modèles d’explication et les affichages des sources lorsqu’ils influencent une décision humaine. La formulation n’est pas simplement une couche de communication si elle indique à un examinateur pourquoi le système recommande une action. L’ordre des preuves peut avoir de l’importance. L’absence d’un avertissement peut avoir de l’importance. L’ensemble des boutons disponibles peut avoir de l’importance. Une décision publique est affectée par ce que les personnes peuvent voir et faire, et non seulement par le calcul caché.

La correction des données est là où l’historique prouve sa valeur

Tout système administratif finit par apprendre qu’un enregistrement source peut être erroné. Une adresse est corrigée, une catégorie est reclassée, un paiement est annulé, une mesure est recalculée, ou une personne fournit des informations manquantes. La correction peut améliorer l’enregistrement actuel sans corriger automatiquement les décisions qui dépendaient de la valeur antérieure. Cette seconde tâche nécessite un lien entre l’historique de la source et les décisions concernées.

Sans ce lien, une institution est confrontée à deux mauvais choix. Elle peut tout réexaminer, ce qui est coûteux et peut exposer des personnes qui n’ont jamais été concernées. Ou elle peut ne rien réexaminer, ce qui laisse l’erreur connue en place pour quiconque dont la décision en dépendait. Les références versionnées permettent une question plus ciblée : quelles décisions ont consommé cet état, sous quelle règle, et avec quelle conséquence. La réponse peut guider un examen proportionné.

La même logique s’applique aux changements juridiques et politiques. Une nouvelle règle peut être correcte pour les nouveaux cas sans rendre chaque ancien résultat erroné. Une interprétation d’un tribunal peut exiger un nouvel examen des décisions prises sous une compréhension antérieure. Un processus de correction doit savoir quand l’ancienne règle était en vigueur, quels cas elle couvrait, et si le remède est la réouverture, la notification, l’indemnisation, l’explication ou aucune action. L’historique transforme une question morale en une question opérationnellement répondable sans réduire la question morale à une requête.

La correction devrait également laisser sa propre trace. L’organisation devrait enregistrer ce qui a été trouvé, quels cas ont été examinés, quelle action a été prise et pourquoi certains cas étaient hors du champ d’application. Cette trace protège la personne concernée et l’institution. Elle empêche que le même problème soit discrètement redécouvert par chaque nouvel examinateur. Une correction sans trace est des excuses qui ne peuvent pas se souvenir de qui elles ont aidé.

L’examen humain a besoin d’une version aussi

La supervision humaine est souvent présentée comme si la présence d’une personne suffisait à rendre la décision stable. Il n’en est rien. Le relecteur agit dans un contexte : un ensemble de documents, un écran, une file d’attente, un délai, un rôle, une note de politique, une alerte et une liste d’actions disponibles. Si le contexte change, le sens de la validation du relecteur peut changer avec lui. Enregistrer uniquement un nom et un horodatage ne respecte ni le relecteur ni la personne concernée.

Versionner la supervision humaine ne nécessite pas de consigner chaque pensée. Il faut suffisamment de contexte pour montrer l’autorité et les éléments de preuve de l’acte. Quels documents ont été présentés. Lesquels ont été exclus ou indisponibles. La sortie était-elle une suggestion, une exigence ou un déclencheur. Le relecteur pouvait-il la remplacer. Un chemin d’escalade était-il visible. Le relecteur a-t-il ajouté une raison. L’action a-t-elle été appliquée ou simplement rédigée. Ces champs créent un enregistrement du jugement sans prétendre que le jugement est un nombre lisible par une machine.

Cette distinction protège les travailleurs. Si une organisation attend des relecteurs qu’ils assument un résultat, elle ne devrait pas ensuite les juger sur une interface différente et un ensemble de preuves différent. Elle protège aussi les citoyens. Une personne contestant une décision ne devrait pas entendre qu’un humain anonyme était dans la boucle pour découvrir ensuite que cet humain ne pouvait que cliquer sur « approuver ». La supervision a du sens lorsque l’enregistrement montre ce que la personne était autorisée à faire et ce qui s’est passé lorsqu’elle a exprimé son désaccord.

Il y a aussi un bénéfice culturel. Lorsque le désaccord est consigné comme une partie normale du flux de travail, il devient une source d’apprentissage plutôt qu’un signe de déloyauté. Les organisations peuvent examiner si les dérogations se concentrent autour d’un problème de données, d’une ambiguïté de politique ou d’une pression liée à l’interface. Elles peuvent améliorer le système sans blâmer les personnes qui ont remarqué que le système était erroné. Un historique donne au dissentiment un lieu où aller autre que le couloir.

Mémoire sans thésaurisation

Une fois qu’une organisation comprend la nécessité de l’historique, la tentation est de tout conserver. Chaque invite, capture d’écran, valeur de fonctionnalité, message, enregistrement, exportation et fichier intermédiaire est conservé pour toujours, juste au cas où. Ce n’est pas de la responsabilité. C’est une archive qui a oublié pourquoi elle existe. Cela augmente l’exposition à la vie privée, accroît les coûts de sécurité et rend les preuves pertinentes plus difficiles à trouver.

La conservation doit suivre la conséquence, le besoin juridique et la possibilité de remédiation. Une décision à fort impact peut nécessiter un ensemble de preuves plus complet et une période de protection plus longue. Un brouillon à faible risque peut nécessiter un reçu compact. Un contenu sensible peut être référencé par un identifiant et conservé dans un système restreint. Une représentation dérivée peut expirer tandis que le fait qu’elle ait existé, et la raison de sa suppression, demeure. La conception doit préciser ce qui est conservé, qui peut y accéder, comment cela est corrigé et quand cela est détruit.

La mémoire sélective est plus facile à défendre lorsque l’enregistrement est structuré. Des identifiants stables peuvent relier une décision à une source sans copier des données personnelles dans chaque journal. Des intervalles effectifs peuvent empêcher qu’une valeur actuelle soit lue comme la valeur passée. Des codes de raison peuvent rendre une correction découvrable sans préserver une conversation privée. Un contrôle d’intégrité peut montrer qu’un enregistrement n’a pas changé sans exposer son contenu à tous ceux qui le demandent. Une bonne protection des données ressemble souvent à une meilleure ingénierie, car les deux disciplines n’aiment pas l’ambiguïté.

Il n’existe pas de période de conservation universelle cachée dans l’expression « historique des versions ». La période dépend de la tâche, du secteur, de la voie de recours, de l’obligation contractuelle et de la loi. Ce qui devrait être universel, c’est l’exigence de décider délibérément. Si l’organisation ne peut pas indiquer pourquoi un composant doit être conservé, elle ne comprend peut-être pas son rôle dans la décision. Si elle ne peut pas indiquer pourquoi un composant peut être supprimé, elle conserve peut-être un risque plutôt qu’une preuve.

Concevoir l’historique sans créer de théâtre

Une implémentation utile commence par des questions, pas par des champs. Quelle décision pourrait être contestée. Quelles versions pourraient en changer le sens. Qui doit pouvoir l’inspecter. Quel est le moment le plus précoce où l’enregistrement peut être scellé. Quel est le plus petit ensemble de preuves permettant à un examinateur de tester l’affirmation concernée. Quels changements doivent déclencher un nouvel examen. Quels événements doivent être visibles pour une personne et lesquels relèvent du détail opérationnel.

Les réponses mènent généralement à quelques schémas durables. Donnez à chaque politique, modèle, définition de source et version de workflow une identité stable. Enregistrez les intervalles d’effet séparément des moments de publication et de déploiement. Reliez la décision aux identités exactes utilisées, et non à ce qui est en vigueur au moment où quelqu’un ouvre le dossier. Conservez un compte rendu lisible par un humain en plus des références lisibles par machine. Faites en sorte que les modifications s’ajoutent à un historique ou créent un nouvel état immuable. Si une correction remplace une valeur antérieure, conservez la relation entre les deux.

Testez l’historique comme une fonctionnalité opérationnelle. Prenez une décision connue et demandez à un ingénieur, un responsable de politique et un examinateur indépendant de la reconstituer. Arrivent-ils au même état. Peuvent-ils dire ce qui est confirmé et ce qui manque. Peuvent-ils identifier qui détenait l’autorité. Peuvent-ils trouver les décisions affectées par une correction de source. Peuvent-ils expliquer pourquoi une relecture actuelle diffère sans qualifier le passé d’erroné par défaut. Un système qui réussit seulement un test de schéma a un enregistrement soigné. Un système qui réussit un test d’examen a une chance d’être responsable.

Enfin, répétez le changement. Remplacez une règle dans un environnement de test, mettez à jour une définition de source, déployez un paquet de modèle, retirez une permission et corrigez un enregistrement. Puis inspectez l’historique. Montre-t-il la transition, sa portée et son propriétaire. L’ancien état peut-il encore être lu par un examinateur autorisé. Le point de décision en aval pointe-t-il vers la bonne version. Si la réponse est non, le système compte sur un incident futur pour lui apprendre le contrôle de version. Les incidents futurs sont des professeurs coûteux.

Ce qu’un journal des modifications public ne peut pas vous dire

Un journal des modifications public peut dire qu’un seuil a été révisé, qu’un modèle a été mis à jour ou qu’un workflow a été amélioré. Il ne peut pas dire à une personne si le changement a touché son dossier, à moins que l’enregistrement de décision ne fasse ce lien. Il peut dire quand une version est devenue disponible. Il ne peut pas vous dire si une région l’a reçue plus tard. Il peut dire qu’un bug a été corrigé. Il ne peut pas vous dire quels résultats passés ont été revérifiés. Les journaux des modifications sont utiles précisément parce qu’ils sont sélectifs. Les preuves sont utiles lorsque leur règle de sélection est visible.

La distinction importe aussi pour la supervision démocratique. Un organisme public peut publier un registre des modèles et une description générale de leur objectif. Le Parlement, un tribunal, un auditeur ou une personne exerçant un droit peuvent encore avoir besoin de savoir ce qui s’est passé à une date précise. Un registre donne à la société une vue d’ensemble. L’historique des décisions donne à une personne un chemin à travers elle. Les deux sont nécessaires. Le premier est une information publique. Le second est une mémoire institutionnelle qui peut répondre d’un acte.

Il y a un danger discret à présenter un journal des modifications comme une forme de responsabilité, car cela récompense la perspective de l’éditeur. L’éditeur choisit ce qui compte comme matériel, utilise le vocabulaire courant et décrit l’effet prévu. Une personne affectée par le système part d’ailleurs. Elle demande quelle règle a touché ma demande, quelles preuves ont été examinées, si le rôle du système relevait de son autorité et ce que je peux faire maintenant. L’enregistrement doit pouvoir répondre à cette question, même lorsque la réponse est gênante.

Un bon registre public des modifications comporte donc deux directions. Il explique les changements au public dans un langage clair et offre aux réviseurs autorisés un chemin vers les preuves au niveau du dossier. Il indique ce que le changement n'a pas modifié. Il signale les corrections ultérieures. Il renvoie aux responsables politiques, système et exploitation. Il précise quand un registre est incomplet. La confiance ne se crée pas en prétendant que chaque historique est sans faille. Elle se crée lorsque les failles sont visibles et que quelqu'un en est responsable.

Notre modeste intérêt dans la question

Chez Dweve, nous revenons sans cesse à cette distinction parce que notre propre travail sur Ledger traite l'historique opérationnel comme un registre typé et rejouable plutôt que comme un tas de messages consultables. Notre travail sur les registres opérationnels suit la même question : qu'est-ce qui est conservé comme historique, et qu'est-ce qui est dérivé comme vue actuelle. Ce sont des choix d'ingénierie, pas une preuve qu'une institution publique ou qu'un fournisseur a rempli ses obligations. La leçon plus large appartient à tous ceux qui construisent des systèmes responsables : garder le registre près de l'événement, garder sa portée honnête, et ne pas laisser une vue actuelle se faire passer silencieusement pour le passé.

Ce n'est qu'un petit paragraphe dans un argument bien plus vaste. L'argument ne dépend pas d'un produit Dweve. Il est déjà présent dans la gestion des documents européenne, la responsabilité en matière de protection des données et les exigences du cycle de vie de l'AI Act. Nous nous intéressons à ce problème parce que le logiciel rend l'oubli facile et que les décisions publiques rendent l'oubli lourd de conséquences. La bonne réponse n'est pas d'ajouter notre logo au mot transparence. C'est de rendre l'historique inspectable, limité et utile à la personne qui devra vivre avec le résultat.

La question d'un citoyen est généralement au passé

Pourquoi cette décision a-t-elle été prise. Quelle règle s'appliquait. Quelles informations avez-vous utilisées. Une personne a-t-elle examiné la décision. Qu'est-ce qui a changé ensuite. Ce sont des questions au passé. Elles sont posées par les citoyens, les patients, les travailleurs, les étudiants, les clients, les journalistes, les auditeurs, les tribunaux et le personnel qui hérite d'un système qu'il n'a pas conçu. Un tableau de bord actuel peut montrer que le système est sain. Il ne peut pas répondre de la décision d'hier si hier a été écrasé.

La réponse n'exige pas d'une institution qu'elle conserve chaque détail pour toujours ou qu'elle publie chaque registre interne. Elle exige que l'institution sache quels faits rendent la décision intelligible, qu'elle conserve ces faits sous une forme vérifiable et qu'elle dise clairement quand un fait ne peut pas être récupéré. C'est la promesse modeste de l'historique des versions. Il ne rend pas une décision juste. Il rend une décision responsable.

La pratique archivistique européenne dit cela depuis longtemps dans un langage ordinaire : les informations importantes peuvent avoir des versions historiques, et les informations numériques restent des informations où qu'elles soient stockées. Le droit européen de la protection des données dispose que la responsabilité inclut la capacité de démontrer la conformité. L'AI Act fait de la documentation technique et de la journalisation du cycle de vie une partie des obligations pour les systèmes à haut risque définis. Les questions du Médiateur sur l'IA dans le secteur public vont dans le même sens. Les institutions seront jugées non seulement sur ce qu'elles déploient, mais sur ce qu'elles peuvent montrer du choix.

Alors, conservez le journal des modifications. Rédigez la note de version. Publiez le registre. Ensuite, construisez le registre moins glamour en dessous : celui qui sait quelle source, quelle règle, quel système, quel flux de travail et quelle autorité étaient actifs lorsqu'un dossier de personne est passé de la possibilité à la décision. Si l'organisation peut montrer ce qui a changé, elle peut aussi montrer ce qui n'a pas changé, ce qui a été appris et ce qui peut encore être réparé. Ce n'est pas de la nostalgie archivistique. C'est la mémoire minimale requise pour que le pouvoir public reste responsable.

Sources