Le registre des modèles est le nouveau tableau d'affichage public.

Un registre de modèles peut informer le public sur ce qu'est un système, qui le soutient, où il peut être utilisé et ce qui a changé. Il ne peut pas...

Le registre des modèles est le nouveau tableau d'affichage public.

The page that starts by admitting it is not magic

The first thing a useful model registry does is disappoint you. It does not say that a model is safe. It does not say that an organisation is competent. It does not turn a supplier's promise into a fact, or a green label into a reason to stop asking questions. It gives you a bounded record instead: this is the thing, this is the version, this is the owner, this is the declared purpose, this is the status, and this is where the supporting evidence is kept.

That modesty is the beginning of public trust. A registry is a noticeboard, not a shrine. A noticeboard tells a neighbourhood what is being built, who is responsible for it and which notices have been replaced. It does not certify the workmanship of every building on the street. It gives people a place to start looking, and a way to notice when the notice itself has gone stale.

Open the Dutch government's Algorithm Register and the design is unusually plain. Government organisations publish information about algorithms they use in their work. The register focuses on impactful algorithms, including high-risk AI systems, and gives visitors an explanation of how those systems work. The page also makes a useful distinction that many glossy AI catalogues avoid: an algorithm is a set of rules and instructions a computer follows to calculate an answer, not a personality with a product launch.

The page is public because the work is public. A citizen does not need a private account to discover that an authority uses an algorithm, what the authority says it is for, or where to ask the next question. That does not make every technical detail public. It does make the existence of the system, its declared role and its institutional owner harder to hide behind a procurement file.

Model registries are becoming the same kind of civic object. They sit between a technical catalogue and a public record. Engineers need a stable identity and a version to integrate. Operators need a status and an owner to run. Downstream providers need capabilities, limits and conditions. Auditors need a trail back to evidence. Affected people need to know that a system exists and how to challenge what it does. One page cannot answer all of those questions, but a well-designed registry can point each reader to the right layer.

The danger is that the word registry makes a document sound more complete than it is. A phone book is a registry, but it cannot tell you whether a number still works. A shipping manifest is a registry, but it cannot tell you whether the cargo survived the voyage. A model record is a registry, but it cannot carry the entire proof of performance, fairness, security, legality and social consequence. The useful question is not whether a model is in the registry. It is what the entry establishes, what it leaves open and what a reader can inspect next.

A noticeboard is a promise of selection

An inventory tries to count everything. A catalogue tries to help you choose. A register makes a more formal promise: these entries belong to a defined scope, they have an owner, and the information is maintained under a rule. The promise is about selection before it is about software. Without a stated scope, an attractive list is only a collection of things that happened to be remembered.

That is why every registry needs a sentence that says what it includes and what it deliberately leaves out. The EU AI Act's central database is not a list of every model circulating in Europe. Article 71 establishes an EU database for specified high-risk AI systems and the systems that are registered under the routes described in Article 49. The Dutch Algorithm Register is not a list of every calculation made in a government office. It focuses on impactful algorithms, including high-risk AI systems. The boundary is part of the record, not a footnote for lawyers.

A model registry should answer the same boundary question in ordinary language. Does it list foundation models, deployed AI systems, internal experiments, fine-tuned descendants, evaluation packages, or only models offered to external users? Does a new serving configuration receive a new entry, a new version or a linked deployment record? Does a captured state of an adaptive system count as the same model identity? If the registry does not decide these questions, every reader will decide them differently. That is how a short list becomes a long argument.

Selection also makes absence meaningful. If the scope says that all publicly accessible high-risk systems must appear, a missing entry is a governance problem. If the scope says that only models placed on a market are included, an internal experiment may be absent by design. The public cannot interpret an empty search result without knowing which of those two situations applies. Silence is not neutral when the register has not explained its vocabulary.

There is a small administrative virtue in saying this plainly. Registries do not need to pretend that they know everything. They need to tell the reader what they know, what they are responsible for and what sits outside the frame. A registry earns its authority by making the boundary of its scope explicit, not by decorating the cover. The technology is newer. The paperwork instinct is not.

What the European rule actually puts on the board

The AI Act gives the word registration a concrete legal shape, but not a single universal one. Article 49 requires a provider or authorised representative to register certain high-risk AI systems before placing them on the market or putting them into service. It also requires registration where a provider has concluded that a system is not high-risk under the conditions of Article 6(3). Public authorities and equivalent public bodies that deploy certain high-risk systems have their own registration duty, including registering their use.

The same article makes the public-private boundary explicit. Certain high-risk systems used in law enforcement, migration, asylum and border control management are registered in a secure non-public section. High-risk systems in the second point of Annex III are registered at national level. These are not implementation details that can be ironed out in a dashboard. They describe different audiences, different risks and different permissions to see the record.

Article 71 says the Commission, working with the Member States, shall set up and maintain the EU database. The information registered under Article 49 is to be accessible and publicly available in a user-friendly manner, and should be easily navigable and machine-readable, with exceptions for restricted sections. The database should contain personal data only as far as necessary. This is a useful definition of public transparency: a record people can find and process, without turning the record into a second personal-data problem.

Annex VIII is where the noticeboard becomes specific. For a provider registering a high-risk system, the record includes the provider's identity and contact details, an unambiguous trade name or reference, the intended purpose, a basic description of the information used and the operating logic, the status of the system, relevant certificates, Member States where it is placed on the market or put into service, the declaration of conformity, instructions for use and an optional URL for further information. These are not marketing fields. They are handles for identification and accountability.

Pour un déployeur public, les informations sont différentes. Le registre comprend l'identité du déployeur, la personne qui soumet les informations, l'URL de la fiche du fournisseur, ainsi que des résumés d'une évaluation d'impact relative aux droits fondamentaux et, le cas échéant, d'une évaluation d'impact relative à la protection des données. Cette distinction importe car un fournisseur de modèles et une autorité publique ne disposent pas des mêmes connaissances et n'assument pas la même responsabilité. Un registre qui les fusionne en une seule fiche fournisseur efface l'endroit où un système rencontre une institution.

La base de données juridique a donc un caractère stratifié. Elle enregistre une identité de système. Elle enregistre un fournisseur. Elle peut enregistrer un déployeur et une utilisation. Elle enregistre le statut et les déclarations à l'appui. Elle ne remplace pas la documentation technique, la gestion des risques, le système qualité ou la surveillance après mise sur le marché que l'Acte exige ailleurs. La base de données est un index public de faits imputables. Elle ne constitue pas l'intégralité du dossier de conformité.

Cette distinction est facile à perdre de vue car les gens aiment une URL unique qui semble contenir la réponse. La loi est moins sentimentale. Elle crée une surface publique, des surfaces restreintes et des voies de documentation contrôlées. La surface publique doit être utilisable. La surface restreinte doit rester restreinte. La documentation doit demeurer accessible à l'autorité compétente ou au fournisseur en aval qui en a besoin. Un registre sérieux est une interface entre ces obligations, et non un raccourci pour les contourner.

Un registre devient utile lorsque l'identité, le statut et le changement sont reliés. Une couleur sans transition n'est que décoration.

Il existe une autre limite importante. Les dispositions de l'Acte sur l'IA concernant les modèles d'IA à usage général ne sont pas la même chose qu'un catalogue public de tous les modèles à usage général. L'article 53 exige que les fournisseurs conservent une documentation technique, mettent des informations à la disposition des fournisseurs en aval de systèmes d'IA, maintiennent une politique en matière de droits d'auteur et publient un résumé suffisamment détaillé du contenu d'entraînement. Les orientations de la Commission expliquent que la documentation technique est destinée au Bureau de l'IA et aux autorités nationales compétentes sur demande, tandis que la documentation en aval aide les intégrateurs à comprendre les capacités et les limites. Seule une partie de ces éléments relève d'un tableau d'affichage public.

L'Acte exige également que la Commission publie et tienne à jour une liste des modèles d'IA à usage général présentant un risque systémique. Une liste de modèles à risque systémique est un signal public précieux, mais ce n'est pas le même objet qu'un registre complet de modèles. Elle a un objectif plus restreint et doit respecter les droits de propriété intellectuelle, les informations commerciales confidentielles et les secrets d'affaires. Qualifier chaque liste de registre est inoffensif jusqu'au moment où quelqu'un suppose qu'une liste prouve plus qu'elle ne le fait.

Un modèle n'est pas une ligne unique

Les gens parlent d'un modèle comme s'il s'agissait d'un bocal sur une étagère. Le nom est imprimé sur l'étiquette, la version est estampillée en dessous et le contenu reste inchangé jusqu'à ce que quelqu'un ouvre le couvercle. Cette image fonctionne pour un artefact statique. Elle devient peu fiable lorsqu'un modèle est adapté, affiné, intégré à des outils, servi par plusieurs voies ou modifié pendant son utilisation.

Un registre a besoin d'au moins deux identités : l'identité du modèle et l'identité de ce qui a réellement fonctionné. La première répond à la question de savoir quel modèle le fournisseur entend. La seconde peut identifier un état capturé, un paquet de déploiement scellé, une exportation locale ou un ensemble de relecture. Les relier évite deux erreurs opposées. Un service peut cesser de prétendre que chaque état en direct possède un hachage permanent unique, et un opérateur peut cesser de prétendre qu'un condensé de paquet décrit à lui seul toute la famille de modèles.

Version numbers are useful only when their change rule is visible. A version may mean a new set of learned parameters, a new constraint catalogue, a change in retrieval, a changed safety layer or a material change in the serving contract. If a provider uses one number for all of those, the number becomes a polite way of saying that something changed. A registry should link a successor to its predecessor and say which part of the contract moved.

Adaptive behaviour adds another wrinkle. If a system can change while in use, the record should say so. That is not an admission that the system is uncontrolled. It is an admission that the word version cannot do all the work. The registry can keep a stable model identity, attach time-bound captured states to it and record the conditions under which a state was made. The point is not to freeze a living system into a false photograph. It is to give every meaningful photograph a date and a frame.

Identity also has a social edge. A model name is not enough when several legal entities distribute similar artefacts, when a downstream provider changes the model, or when a product embeds a model behind its own name. The registry should make the chain visible: provider, distributor where different, deployer where relevant, and the system or route in which the model is used. A person affected by a decision should not have to perform forensic archaeology on a product logo to discover who can answer for it.

Status is a verb, not a colour

Status fields are often rendered as badges because badges fit neatly on cards. The badge is not the status. The status is a statement about an action and a time. Internal testing means one thing when access is controlled by the provider. Pre-release means something else when invited outsiders can use a route under defined conditions. On the market, in service, suspended, withdrawn and recalled each carry a different operational consequence.

A useful record states what the status permits and what it does not. If a system is internal-only, a reader should not infer public availability from a documentation page. If an external beta is planned, the date should be labelled as planned rather than presented as a release. If a system is withdrawn, the record should preserve the previous identity and say whether existing deployments may continue, must stop or are being migrated. A status without an effective date is a rumour wearing a uniform.

The status should also be owned. Who can move an entry from internal to external? Who can suspend a route? Who can declare a release date changed? Which evidence is required before the transition? Those questions belong in the operating process, but the public entry should make the resulting decision legible. A registry that shows the current badge while hiding the authority behind it is only a mood board for governance.

Illustrative example, not a real listing: a record might say that a model is in controlled evaluation, that no external route is open, that an invite-only trial is proposed for a later date, and that the proposal remains subject to a release gate. The example names no organisation, model or event. Its purpose is to show how a record keeps a plan separate from a fact. The same discipline applies to a withdrawal, a capability claim or a certification that has not yet been issued.

This separation protects readers from a familiar trick. A future intention is repeated often enough that it starts to sound like history. Registries should be the place where that trick stops working. The entry can show a plan, but the plan must keep its label. Europe has enough calendars already. A date is not a fact merely because it has been placed in a coloured rectangle.

The registry is not the evidence room

Une entrée publique doit être assez courte pour être lue et assez solide pour orienter une question sérieuse. La salle des preuves qui la sous-tend peut être bien plus vaste. Les obligations de documentation de l'article 53 de l'AI Act en illustrent la raison. Les fournisseurs de modèles d'IA à usage général doivent établir et conserver une documentation technique couvrant le développement, l'entraînement, les tests et l'évaluation. Ils doivent mettre des informations et une documentation à la disposition des fournisseurs en aval de systèmes d'IA afin que ceux-ci puissent comprendre les capacités et les limites. Ils doivent publier un résumé suffisamment détaillé du contenu d'entraînement et maintenir une politique relative au droit d'auteur de l'Union.

Ces obligations s'adressent à des lecteurs différents. Une autorité compétente peut avoir besoin du dossier technique complet. Un fournisseur en aval a besoin d'informations d'intégration et des limites. Le public a besoin d'un compte rendu clair de ce qu'est le modèle et de la manière dont le résumé de son contenu d'entraînement est délimité. Une entrée de registre peut relier ces surfaces sans prétendre qu'une page publique doit contenir chaque détail sensible pour la sécurité, chaque fichier de poids ou chaque échantillon de test contenant des données personnelles.

Les liens ne sont pas non plus des preuves par magie. Un registre qui pointe vers un rapport d'évaluation doit indiquer quelle version le rapport couvre, ce que l'évaluation a mesuré et quelles conditions limitent le résultat. Un lien vers un résumé d'entraînement doit préciser si le résumé couvre le pré-entraînement, l'ajustement fin ou un ensemble défini de catégories de contenu. Un lien vers un certificat doit montrer qui l'a délivré, ce qu'il certifie et quand il expire. Sinon, la page n'est qu'une étagère d'enveloppes non ouvertes.

La même règle s'applique aux déclarations de sécurité. Un registre peut indiquer qu'une évaluation des risques existe, qu'un plan de surveillance est lié ou qu'une procédure pour les incidents graves est publiée. Il ne doit pas laisser entendre que l'existence d'un document prouve que le système sous-jacent est sûr. La documentation est un moyen d'inspecter une affirmation. Elle n'en est pas le substitut.

C'est ici que l'écriture publique exige de la discipline. Une fiche de modèle, une page de transparence ou une entrée de registre peut décrire l'utilisation prévue et les limites connues. Elle ne peut pas utiliser le mot digne de confiance comme conclusion, à moins que les preuves et la portée ne rendent cette conclusion défendable. La phrase honnête est souvent plus utile : voici les conditions que nous avons évaluées, voici les limites que nous avons observées, et voici les cas que nous n'avons pas prétendu couvrir.

Le registre néerlandais montre la valeur d'une liste publique ordinaire

Le registre néerlandais des algorithmes est instructif précisément parce qu'il ne cherche pas à ressembler à une salle de contrôle futuriste. Il offre aux organisations gouvernementales un espace public pour décrire les algorithmes utilisés dans leur travail. Sa page en anglais avertit que les descriptions ont été traduites automatiquement et que la version néerlandaise originale fait foi pour la description. Cette petite note est une leçon de provenance. L'accès n'est pas la même chose que l'exactitude, et une interface traduite ne doit pas effacer la langue source.

L'objectif public du registre est également énoncé sans langage théâtral. Il se concentre sur les algorithmes à fort impact, y compris les systèmes d'IA à haut risque, et donne aux visiteurs un aperçu de leur fonctionnement. Le visiteur peut parcourir les algorithmes, les organisations et les modèles. L'objectif n'est pas d'attribuer un score à chaque algorithme. Il est de rendre l'utilisation des systèmes algorithmiques suffisamment visible pour que les personnes, les organisations et les médias puissent suivre, questionner et examiner les pratiques gouvernementales.

Le cadre néerlandais Algoritmekader qui l'accompagne transforme cet objectif en exigence. Il précise que, sauf exception, les organismes publics publient les algorithmes à fort impact et les systèmes d'IA à haut risque dans le registre. Il précise également qu'une publication incorrecte ou incomplète peut rendre plus difficile pour les personnes concernées et les autres parties prenantes de comprendre et de contester l'utilisation d'une technologie qui peut toucher à leurs droits. La transparence n'est donc pas seulement une courtoisie. La qualité de l'entrée peut affecter la qualité du contrôle public.

The same guidance is careful about scope. It describes the register as a tool within a wider set of laws and requirements, and warns that the framework is not complete and may not include sector-specific legislation. The fact that an algorithm appears in a register does not settle every legal or ethical question. The fact that it does not appear does not prove that it is harmless. A reader needs the register's inclusion rule and the surrounding framework to interpret the entry.

That is the useful pattern for model registries. A public list should be easy to find, written for people who were not in the procurement meeting, and connected to the records that carry more detail. It should expose uncertainty rather than hide it. It should say when an English description is machine-translated. It should explain which systems are included and which are not. It should make a missing or stale entry a visible governance issue instead of a private disappointment.

There is no need to invent a dramatic incident to see why this matters. A citizen trying to understand an automated government process already has a practical question: is a system being used, by whom, for what purpose and under which explanation? A registry gives that question an address. The answer may still be incomplete. At least the institution cannot pretend that there is nowhere to ask.

Public does not mean naked

Transparency becomes counterproductive when it is treated as a command to publish everything. Public records can expose personal data, security-sensitive information, proprietary details and attack paths. They can also create false confidence by publishing technical fragments that no ordinary reader can interpret. The public-private boundary must be designed, documented and reviewed, not improvised by whichever team happens to own the content-management system.

The AI Act gives a legal example. Article 49(4) places particular systems in a secure non-public section and limits access to the Commission and the relevant national authorities. Article 71 makes the information registered under Article 49 publicly available except for the restricted sections, while information registered under Article 60 is accessible only to market-surveillance authorities and the Commission unless the provider consents to public access. Publicity is therefore a rule with exceptions, not a universal default.

Article 53 makes a similar distinction for general-purpose models. Providers must make technical documentation available to the AI Office and national competent authorities on request, and they must provide downstream documentation to integrating providers. The obligations are explicitly subject to the need to observe and protect intellectual-property rights, confidential business information and trade secrets. A registry should not force a provider to publish the material that the law says should be controlled. Nor should confidentiality become a polite excuse for withholding the existence, purpose or status of a system that affects the public.

A practical model registry can use layers. The public layer identifies the model, provider, status, intended purpose, broad capabilities, known limits, access routes, release conditions, evidence links and change history. A controlled layer carries detailed technical documentation, threat models, restricted evaluation material, incident details and other information that authorised reviewers need. A private operational layer carries secrets, personal data and internal control information that should not be exposed at all. The layers are different records with links, not one page with an accordion labelled transparency.

Une bonne transparence a une limite. Elle publie ce dont les gens ont besoin pour comprendre le système et protège ce que les réviseurs autorisés doivent contrôler.

La couche publique doit rester précise. Elle peut indiquer qu’un modèle est adaptatif pendant l’utilisation sans exposer une représentation privée de son état. Elle peut indiquer qu’un itinéraire est sur invitation sans publier les jetons d’invitation. Elle peut décrire les modalités de sortie et une politique de marquage du contenu sans exposer les clés de signature. Elle peut indiquer qu’une évaluation des risques existe et préciser sa portée sans publier un schéma de sécurité qui rendrait le service plus facile à attaquer.

La couche contrôlée exige sa propre honnêteté. Un document marqué confidentiel n’est pas automatiquement complet, à jour ou exact. Il lui faut un propriétaire, une version, une règle d’accès et une règle de conservation. Si un registre public renvoie à un enregistrement contrôlé, le lien doit révéler son statut et l’itinéraire responsable, même lorsque le contenu est restreint. Sinon, le public voit un trou noir et on lui demande d’appeler cela de la gouvernance.

Le versionnage est ce qui rend un registre utile

La plupart des défaillances de registre ne sont pas spectaculaires. Ce sont de petits actes d’oubli. Un nouveau modèle remplace un ancien, mais l’entrée est modifiée sur place. Une politique change, mais le paragraphe sur l’usage prévu reste. Un fournisseur fait passer un itinéraire de test interne à une version bêta externe, mais le badge de statut change avant que la date d’entrée en vigueur soit enregistrée. Un déploiement est retiré, mais l’ancienne entrée disparaît, emportant l’historique avec elle. Le présent semble ordonné. Le passé devient impossible à répondre.

Un enregistrement versionné maintient au moins quatre dates distinctes. La version du contenu indique quel texte et quels champs de l’enregistrement sont à jour. La date d’entrée en vigueur indique à partir de quand la déclaration s’applique. La version du modèle ou du paquet indique quel objet technique est décrit. La date de vérification indique quand quelqu’un a contrôlé l’enregistrement. Ces dates peuvent coïncider. Elles n’y sont pas obligées. Les traiter comme une seule date est pratique et souvent faux.

Les versions précédentes doivent rester découvrables selon une règle de conservation appropriée. Le public n’a pas besoin de chaque modification interne, mais il doit savoir quand un objectif matériel, un statut, un itinéraire, une limitation ou une déclaration de propriété a changé. Un journal des modifications peut indiquer ce qui a bougé sans exposer d’informations privées. Un enregistrement lisible par machine peut relier la version précédente et un manifeste. Une page lisible par un humain peut expliquer la conséquence en langage ordinaire. Les deux surfaces doivent concorder.

Le versionnage rend aussi le retrait significatif. Si un modèle est retiré parce qu’un itinéraire est fermé, cela diffère d’un rappel dû à un défaut grave ou à une question juridique exigeant une action. Si un modèle reste dans des déploiements privés existants, le registre public doit le dire. Si un successeur n’est compatible que pour certaines intégrations, la limite de migration doit être visible. Un registre qui supprime un nom sans enregistrer pourquoi laisse chaque lecteur en aval inventer une raison.

L’historique des modifications est particulièrement important pour les systèmes adaptatifs. L’identité du modèle peut rester stable pendant que les états capturés, les ensembles de contraintes, les sources de récupération ou les contrôles de sortie changent. Le registre peut indiquer quels changements créent un nouveau paquet, lesquels exigent une nouvelle évaluation et lesquels restent dans la limite d’identité déclarée. Ce n’est pas un détail excessif. C’est la différence entre un système qui peut être rejoué et un système qui ne peut qu’être mémorisé.

Les propriétaires font partie de l’enregistrement

Une entrée de registre de modèles sans propriétaire est un bulletin météo. Elle vous indique à quoi ressemblait le ciel et vous laisse sans personne à appeler quand le toit fuit. Les rôles de fournisseur et de déployeur ne sont pas les mêmes, et aucun des deux ne devrait être autorisé à se dissoudre dans le mot « plateforme ».

Le fournisseur possède l'identité du modèle, l'historique de développement et la décision de publication dans son périmètre. Un déployeur possède la décision d'utiliser un système sous son autorité, y compris la finalité locale, les mesures de protection, l'évaluation d'impact et les contrôles opérationnels. Un fournisseur en aval peut intégrer un modèle à usage général dans un système d'IA et assumer des responsabilités que le fournisseur du modèle ne peut pas voir. Un registre public devrait exposer ces relations lorsque la loi et le risque l'exigent.

Les coordonnées ne sont pas un remplissage administratif. Elles offrent à une personne concernée un moyen de demander qui a pris une décision, quelle version a été utilisée ou comment demander une correction. Une boîte mail générique peut convenir, mais elle doit mener à un processus entretenu. L'entrée devrait également préciser si le contact concerne l'assistance technique, les demandes de droits, le signalement d'incidents, les achats ou la responsabilité publique. Une seule boîte de réception ne peut pas être toutes les institutions à la fois, malgré les meilleurs efforts des formulaires modernes.

La propriété devrait inclure l'autorité de modifier l'enregistrement. Si le propriétaire désigné ne peut pas suspendre un parcours, corriger un statut ou publier un retrait, l'entrée est décorative. L'organisation peut toujours avoir un propriétaire juridique ailleurs, mais l'écart opérationnel demeure. Un bon registre rend la responsabilité visible avant qu'un incident ne force les gens à dessiner l'organisation sur un tableau blanc.

Concevoir un registre que les gens peuvent réellement lire

Le premier lecteur d'un registre de modèles n'est pas toujours un régulateur ou un ingénieur. Il peut s'agir d'un journaliste, d'un responsable des achats, d'un élu local, d'un chercheur, d'un employé invité à utiliser le système, ou d'une personne qui tente de comprendre pourquoi un service automatisé a touché à son dossier. La page devrait répondre à la question courante avant de recourir au vocabulaire spécialisé.

Commencez par l'identité et la raison de l'entrée. Indiquez qui fournit le modèle, quelle version est décrite, de quel type d'objet il s'agit et s'il s'agit d'un modèle, d'un système d'IA intégré ou d'un enregistrement de déploiement. Précisez s'il est interne, disponible pour des utilisateurs invités, sur le marché, suspendu ou retiré. Le lecteur ne devrait pas avoir à deviner le statut à partir d'un bouton de téléchargement.

Ensuite, montrez la finalité et la limite. Énoncez ce que le modèle est censé faire, quelles utilisations sont hors du champ de la déclaration et quelles décisions il n'est pas autorisé à prendre. Expliquez si le modèle peut s'adapter pendant l'utilisation, si un état capturé est requis pour la relecture, et si un parcours en aval modifie les conditions. Une liste de capacités sans finalité est un menu sans cuisine.

Utilisez la divulgation progressive. Le haut de la page devrait être calme et lisible. Les sections plus profondes peuvent exposer l'enregistrement machine, les méthodes d'évaluation, le résumé du contenu d'entraînement, les documents juridiques et les preuves de publication. Un lecteur public peut s'arrêter après la première couche. Un auditeur peut continuer. Un ingénieur peut télécharger une représentation stable. Cacher les détails n'est pas la simplicité. C'est juste une surprise au chargement lent.

L'accessibilité fait partie de la crédibilité de l'enregistrement. La page et la représentation machine devraient utiliser des étiquettes claires, la navigation au clavier, des titres utiles et des alternatives textuelles pour les visualisations. Les dates ne devraient pas être encodées uniquement par la couleur. Un badge rouge n'est pas un statut pour un lecteur qui ne voit pas le rouge, et un graphique qui ne peut pas être lu sans souris n'est pas une explication accessible. Un panneau d'affichage sur la place du village ne devient pas public si la rampe s'arrête à la première marche.

La lisibilité par machine compte pour une autre raison. Elle permet aux chercheurs de comparer les entrées, aux organismes publics de constituer des inventaires, aux auditeurs de détecter les enregistrements obsolètes et à un outil en aval de vérifier que la page et l'enregistrement structuré se réfèrent à la même version. Lisible par machine ne signifie pas réservé aux machines. La page destinée aux humains et l'enregistrement machine doivent partager des identifiants, des statuts, des dates et des liens, avec une relation d'intégrité vérifiable.

Les champs du registre sont des décisions

Chaque champ indique au lecteur ce que l'organisation estime digne de préservation. Un champ fournisseur précise qui est derrière le modèle. Un nom de modèle et une version précisent comment le distinguer de son successeur. Un champ itinéraire indique où le joindre. Un champ finalité décrit le travail que le fournisseur est prêt à documenter. Un champ limitations précise où s'arrête la description. Le schéma est un document de gouvernance écrit en petits rectangles.

Les champs d'identité doivent être sans ambiguïté et stables. Ils peuvent inclure le nom légal du fournisseur, le nom du modèle, la version, une référence unique et des liens vers un enregistrement canonique. Si le modèle peut être servi via plusieurs produits, le registre doit distinguer l'identité du modèle de la surface d'intégration. Si un produit contient plusieurs modèles, l'entrée ne doit pas masquer ce fait derrière le nom du produit.

Les champs de statut doivent inclure la valeur, la date d'effet, la raison ou l'autorité de la transition, ainsi que tout successeur ou prédécesseur. Une date simplement planifiée doit être étiquetée comme telle. Un enregistrement qui n'a pas été vérifié récemment doit le mentionner. Le lecteur doit pouvoir déterminer si un modèle est disponible, proposé, en pause ou historique, sans interpréter un adjectif inventé par une équipe marketing.

Les champs de finalité et de portée doivent décrire le travail en des termes compréhensibles par un non-spécialiste. Ils doivent nommer les utilisateurs visés lorsque cela importe, les types d'entrées et de sorties concernés, ainsi que les décisions ou actions que le modèle peut soutenir. Ils doivent également indiquer les usages interdits ou non pris en charge. Un modèle capable de générer du texte n'est pas pour autant autorisé à rédiger une décision d'éligibilité, et un modèle capable de classer des documents n'est pas pour autant autorisé à classer des personnes.

Les champs de capacités nécessitent des conditions. Les modalités, les limites de contexte, l'accès aux outils, la couverture linguistique, le comportement d'adaptation et le marquage des sorties n'ont de sens que lorsqu'ils sont liés à un itinéraire et à une version. Une capacité qui existe dans une expérience interne mais pas dans l'itinéraire externe ne doit pas être présentée comme une fonctionnalité universelle. Le registre n'est pas une liste de souhaits.

Les champs de données doivent préciser ce que le modèle reçoit, ce qu'il stocke, ce qu'il apprend pendant l'utilisation et ce qui sert à l'évaluation, au niveau qui peut être rendu public sans exposer de données personnelles ou confidentielles. Les résumés du contenu d'entraînement et les politiques de droits doivent être liés lorsque requis. Une phrase vague comme entraîné sur des données diverses n'apprend presque rien au lecteur et lui demande de fournir une interprétation flatteuse.

Les champs d'évaluation doivent identifier la question, la méthode, la limite des données, la date, le résultat et les limitations. L'entrée n'a pas besoin de reproduire chaque tableau, mais elle ne doit pas afficher un score sans dénominateur ni un test sans objectif. Un bon lien d'évaluation permet au lecteur de voir si les preuves couvrent l'usage prévu, un usage voisin ou seulement une condition de laboratoire.

Les champs de supervision doivent identifier qui peut suspendre, outrepasser, examiner et enquêter sur le système. Si un modèle ne fait que recommander, précisez quelle action reste à l'humain. Si un itinéraire peut agir sur des systèmes externes, précisez quelles autorisations et quels garde-fous s'appliquent. Si le signalement d'incidents dispose d'un itinéraire dédié, publiez-le. La supervision n'est pas un paragraphe sur le maintien de l'humain dans la boucle. C'est une carte de qui peut faire quoi lorsque le système est incertain.

Les champs « preuve » et « intégrité » doivent relier l’entrée publique à un enregistrement machine versionné, à un paquet de publication, à une déclaration, à un ensemble d’évaluation ou à un journal de transparence. Une empreinte peut établir qu’un fichier a changé ou n’a pas changé. Elle ne peut pas établir que le fichier était véridique ; le registre doit donc maintenir la séparation entre la déclaration et le contrôle d’intégrité. La précision technique ne remplace pas le jugement, mais elle rend le jugement plus facile à situer.

Enfin, les champs de modification doivent expliquer l’historique. Qu’est-ce qui a changé, quand, pourquoi, qui l’a approuvé, quelles routes sont concernées et si une nouvelle évaluation est nécessaire. L’entrée doit permettre de répondre à la question la plus ordinaire qui soit : qu’est-ce qui diffère de l’enregistrement que nous avons lu le mois dernier ?

Ce qu’un registre peut établir

Un registre bien tenu peut établir qu’un objet défini est décrit par un fournisseur nommé sous une version d’enregistrement particulière. Il peut établir l’objectif déclaré, le statut, la route d’accès et la propriété. Il peut établir quels documents justificatifs et enregistrements d’intégrité un lecteur peut consulter, et quelles informations sont délibérément contrôlées. Il peut établir qu’un changement a été publié et qu’un enregistrement précédent reste disponible selon la règle de conservation énoncée.

Il peut également établir la position propre de l’organisation. Si un fournisseur déclare qu’un modèle est destiné à l’aide à la décision et non au refus automatique, cette déclaration constitue une limite publique. Si un déployeur déclare qu’une évaluation d’impact a été réalisée, la déclaration soulève la question de savoir où se trouve le résumé ou l’enregistrement contrôlé. Si un fournisseur marque une publication comme planifiée, l’étiquette empêche le plan de se faire passer pour un historique.

Ce sont des faits utiles. Ils rendent l’approvisionnement plus précis, l’intégration moins spéculative et les questions publiques plus faciles à orienter. Ils rendent aussi le désaccord plus net. Un lecteur peut dire que l’objectif déclaré est trop large, que le statut est obsolète, que la limitation manque ou que les preuves à l’appui ne couvrent pas la déclaration. Un registre justifie son existence lorsqu’il rend cette critique possible.

Ce qu’un registre ne peut pas établir

Une entrée de registre ne peut pas établir qu’un modèle est exact pour chaque utilisateur, sûr dans chaque environnement, équitable pour chaque groupe ou licite pour chaque déploiement. Elle ne peut pas établir qu’une autorité publique a suivi la bonne procédure du seul fait qu’un système est répertorié. Elle ne peut pas montrer qu’un examinateur humain a compris une sortie, qu’une personne concernée a disposé d’un recours effectif ou qu’un incident serait détecté à temps. Ces conclusions exigent des preuves concernant le système en usage, l’institution qui l’utilise et les personnes concernées.

Elle ne peut pas non plus établir qu’un modèle est indépendant de son fournisseur, qu’une route est souveraine parce qu’elle est hébergée en Europe, ou qu’une licence ouverte fait disparaître la responsabilité. La propriété, la juridiction, la chaîne d’approvisionnement, le contrôle opérationnel et la maintenance sont des questions distinctes. Un registre peut exposer les noms et les liens nécessaires pour les poser. Il ne peut pas y répondre par la typographie.

Un registre ne peut pas non plus prouver la négative. Une entrée absente peut signifier que l’objet est hors du champ d’application, qu’une exclusion s’applique, que la publication est en retard ou que quelqu’un a omis de publier. Le lecteur a besoin d’une déclaration de couverture claire et d’une voie pour signaler les erreurs. Un tableau d’affichage public n’est aussi fiable que le processus qui remarque lorsqu’un avis manque.

Un enregistrement illustratif, pas une étude de cas cachée

Ce qui suit est une conception d’enregistrement illustrative, et non un rapport sur une organisation, un modèle ou un événement réel. Elle n’utilise aucun client, aucune autorité publique, aucune date de déploiement ni aucun résultat mesuré. Son but est de montrer comment un lecteur peut passer d’une entrée publique à une voie de preuve contrôlée sans confondre les deux niveaux.

  • Identité : un nom de fournisseur, un nom de modèle, une version et un identifiant machine stable.
  • Statut : évaluation contrôlée, avec une date d'effet et une mention indiquant qu'aucune voie externe n'est ouverte.
  • Finalité : assistance à l'analyse documentaire pour le personnel formé, les décisions externes automatiques étant exclues du périmètre déclaré.
  • Entrées et sorties : les modalités représentées, les types de documents sources attendus et les types de sorties que la voie peut produire.
  • Limites : les frontières connues en matière de langue, de domaine, d'actualité, de sécurité et d'accès, chacune étant liée à l'évaluation ou à la politique concernée.
  • Supervision : le rôle pouvant suspendre la voie, le circuit de relecture pour les résultats incertains et le contact en cas d'incident.
  • Éléments probants : un résumé public, un dossier technique versionné pour les relecteurs autorisés et un manifeste d'intégrité pour les fichiers publiés.
  • Évolution : un lien vers l'enregistrement précédent, une déclaration de ce qui a changé et la condition qui exigerait une nouvelle évaluation.

Rien dans cet enregistrement ne dit que le modèle est bon. Il dit ce que le fournisseur est prêt à affirmer, où cette affirmation s'applique et comment une autre personne peut la tester ou la contester. Cela suffit pour un tableau d'affichage. Cela suffit aussi pour empêcher qu'une grande partie du langage de brochure ne s'infiltre inaperçue dans une décision juridique ou opérationnelle.

Pourquoi le statut de préversion mérite le respect

La préversion n'est pas une version affaiblie de la mise à disposition publique. C'est un état différent. Les tests internes peuvent soutenir le travail d'ingénierie et de sécurité tout en maintenant un accès contrôlé. Une bêta sur invitation peut exposer une voie à des personnes extérieures tout en préservant les conditions, le périmètre et le droit d'arrêt. Une mise à disposition publique change qui peut se fier au système et quelles obligations incombent au fournisseur, aux intégrateurs et aux déployeurs. Le registre devrait rendre ces transitions visibles au lieu de traiter la mise à disposition comme une seule note de trompette.

Un enregistrement de préversion peut encore être utile au public. Il peut identifier le modèle, le fournisseur, la voie prévue, le statut, les éléments probants qui existent et ceux qui restent en attente. Il peut indiquer qu'une date est planifiée et que l'accès n'a pas été ouvert. Il peut publier le portail de mise à disposition sans prétendre qu'il a été franchi. C'est un endroit particulièrement propice pour qu'un registre soit ennuyeux. Un statut ennuyeux est plus sûr qu'une ambiguïté excitante.

Chez Dweve, nous essayons d'appliquer cette discipline à notre propre dossier public. Dans notre Trust Centre, le registre des modèles est marqué comme étant en préversion et liste Dweve Loom 1.0 comme test interne exclusif en préversion au 1er août 2026. Il indique qu'aucune mise à disposition externe n'a eu lieu à cette date et liste le 1er septembre 2026 comme date planifiée d'accès au marché de l'Union pour une bêta externe sur invitation. Planifiée est le mot important : l'entrée ne transforme pas un plan en événement.

Notre dossier public précise également que Loom est le seul modèle qui y figure, qu'il est propriétaire plutôt que publié sous une licence de modèle open source, et que nos produits et nos outils open source sous licence séparée ne sont pas présentés comme des modèles supplémentaires. Cette frontière empêche qu'un catalogue de produits soit confondu avec un registre de modèles. Elle maintient également l'affirmation publique suffisamment restreinte pour être vérifiable.

C'est tout ce que nous avons besoin de dire sur Dweve ici. Un registre de modèles est utile lorsqu'il rend notre propre statut de mise à disposition moins flatteur mais plus précis. Il devrait faire de même pour quiconque.

La frontière entre public et privé est une décision de conception

Le registre le plus solide n'est pas celui qui compte le plus de champs. C'est celui dont les champs ont une raison d'être, un responsable et une limite. Les lecteurs publics ont besoin d'une identité stable, d'une finalité déclarée, d'un statut véridique, d'une organisation responsable, de liens utilisables et d'assez de limites pour comprendre la portée de la déclaration. Les réviseurs autorisés ont besoin de preuves plus approfondies, de détails techniques contrôlés et d'un moyen d'inspecter les incidents ou les tests sensibles. Les opérateurs ont besoin de secrets, d'autorisations et de manuels d'exploitation qui ne devraient pas du tout se trouver sur le tableau d'affichage.

Ces couches doivent s'accorder sur les faits qui franchissent la limite. Si la page publique indique qu'une route est suspendue, le dossier contrôlé doit indiquer qui l'a suspendue et pourquoi. Si un fichier technique est remplacé, l'entrée publique ne doit pas continuer à le présenter comme actuel. Si une évaluation est restreinte, la page publique doit tout de même préciser sa portée et son statut. La limite doit restreindre l'accès aux détails, non créer trois versions incompatibles de la réalité.

Les lecteurs doivent pouvoir poser cinq questions simples et recevoir cinq réponses stables. Qu'est-ce que cet objet ? Qui en est responsable ? Que peut-il faire ? Quel est son statut actuel ? Quelles preuves et quels recours existent lorsque la déclaration est contestée ? Un registre qui répond à ces questions fait déjà un travail institutionnel. Un registre qui ne peut pas y répondre ne devrait pas être sauvé par des badges animés ou un tableau de bord à douze filtres.

Il y a une façon optimiste de lire le mouvement européen vers les registres de modèles et d'algorithmes. Ce n'est pas qu'une base de données va résoudre la gouvernance de l'IA. C'est que les institutions publiques construisent des lieux où les déclarations ont des noms, des dates, des responsables et des limites. Ce sont les petites composantes à partir desquelles se construisent les grands systèmes de responsabilité.

Le tableau d'affichage doit survivre au changement

Un registre de modèles n'est le nouveau tableau d'affichage public que si les avis restent lisibles après que le temps a changé. La page doit survivre à une mise à jour du modèle, à un changement de fournisseur, à un nouveau déploiement, à une limitation corrigée, à une route retirée et à une question difficile posée par quelqu'un qui n'était pas dans la salle. Cela signifie conserver l'historique, étiqueter les plans, relier les preuves et dire ce que le dossier ne peut pas prouver.

Le travail est moins prestigieux qu'une page de lancement. Il est aussi plus durable. Un registre public qui distingue l'identité du modèle de l'état du déploiement, le statut de l'intention, la documentation de la preuve et les faits publics des preuves contrôlées donne aux gens mieux que des paroles rassurantes. Il leur donne un chemin à travers le système.

Les bons registres ne demandent pas aux lecteurs de se fier à une couleur, à un chiffre ou à un nom célèbre. Ils rendent la déclaration assez étroite pour être inspectée et la limite assez claire pour être contestée. Ils laissent une trace vers les personnes qui peuvent répondre, les dossiers qui peuvent être vérifiés et la décision qui peut être modifiée. C'est une très vieille idée civique, portant un format de fichier raisonnablement moderne.

Mettez l'avis sur le tableau. Mettez les preuves derrière. Conservez l'ancien avis là où quelqu'un peut encore le lire. Puis laissez le public décider ce que le dossier mérite.

Sources