Pourquoi cette mesure ?
Un citoyen ne devrait pas découvrir par hasard qu’une administration utilise un système d’IA dans une procédure qui le concerne. Les parlementaires ne devraient pas non plus reconstituer les projets à partir de marchés dispersés et de communiqués. La mesure 9.13 crée un registre public de transparence. Il ne s’agit pas de publier les données personnelles, le code complet de chaque outil ou les paramètres de sécurité, mais de rendre visibles les éléments nécessaires au débat : finalité, responsable, technologie, fournisseur, coût, statut juridique, métriques, incidents et voies de recours.
État des lieux en 2026 : partir de ce qui existe vraiment
La France possède déjà des portails de données ouvertes et, depuis 2026, un portail des chartes IA dans l’administration. Plusieurs administrations publient leurs cadres d’usage. La réforme doit réutiliser ces briques au lieu de créer une plateforme isolée supplémentaire. Le registre IA doit aussi être alimenté par les indicateurs de 9.11 : une seule source de données produit les vues parlementaire, Cour des comptes et grand public. Cette conception répond directement à la doctrine du site : une information n’est pas recopiée dans trois systèmes qui divergent après six mois. [source]
Source au point d’usage : Portail des chartes IA ↗
Concevoir, financer et sécuriser la mise en œuvre
Architecture, fonctionnement et conditions techniques
Chaque système reçoit un identifiant. La fiche publique décrit la finalité, l’administration responsable, le fournisseur, la famille de modèle, l’hébergement, le niveau de risque, les données utilisées par grandes catégories, la présence de contrôle humain, les dates de déploiement, le budget et les indicateurs. Les informations sensibles disposent d’un niveau de publication réduit avec justification. Les mises à jour sont historisées afin qu’un système ne puisse pas effacer un incident ou un ancien fournisseur en remplaçant simplement sa fiche.
Démonstration financière : séparer coût, capacité et économie
La plateforme est un investissement de transparence, pas une économie autonome. Son coût doit rester faible en réutilisant les données déjà produites par les projets. Le poste principal est l’intégration des systèmes et la qualité des données, plus que le développement d’une interface. Une économie évoquée — par exemple une réduction du reporting manuel — n’entre dans le total que si son calcul séparé publie la base de référence, le temps réellement supprimé, le coût complet et la part effectivement matérialisée. Le registre peut toutefois éviter une dépense importante indirecte : la création de portails sectoriels parallèles. Ce coût évité n’est comptabilisé que si des projets prévus sont réellement fusionnés ou abandonnés.
Droit applicable et limites à ne pas franchir
La transparence doit être conciliée avec les secrets protégés : sécurité, défense, secret fiscal, médical, secret des affaires ou procédures en cours. Le RGPD interdit évidemment de transformer le registre en base de personnes concernées. Le cadre doit donc définir les informations minimales obligatoires et les exceptions motivées. Pour certaines décisions automatisées, des obligations d’information existent déjà ; le registre les complète mais ne remplace pas l’information individuelle adressée à la personne concernée.
Plans A, B et C : l’objectif survit au blocage d’une voie
registre public national connecté au référentiel 9.11, avec obligation pour les projets significatifs.
si l’intégration complète prend du temps, publier d’abord un catalogue des systèmes et fournisseurs puis ajouter coûts et métriques.
lorsque certaines informations ne peuvent pas être publiques, publier l’existence du système, l’autorité responsable et la catégorie d’exception, tandis que les détails sont accessibles aux organes de contrôle. L’absence de publicité intégrale ne doit pas signifier absence de contrôle.
Risques, objections et garde-fous
Le risque est de produire un catalogue obsolète. La mise à jour doit donc provenir des systèmes de pilotage et non d’une campagne annuelle de saisie manuelle. Autre risque : la publication de détails techniques exploitables par un attaquant ; une politique de sécurité de publication est nécessaire. Enfin, une administration peut être tentée de ne pas qualifier un outil comme IA pour éviter le registre. Le périmètre doit être défini par la fonction et le type de système, pas par le marketing du fournisseur.
Indicateurs, audit et preuve de réussite
Indicateurs : taux de projets enregistrés ; délai de mise à jour ; fiches incomplètes ; incidents publiés ; consultations du registre ; corrections ; fournisseurs et concentration ; coûts cumulés ; projets sans évaluation ; projets avec contrôle humain ; exceptions de publication. Le registre doit offrir un export machine afin que journalistes, chercheurs et parlementaires puissent analyser les tendances sans copier manuellement les pages.
Définir précisément ce qui doit être public pour chaque système
La fiche publique doit au minimum indiquer la finalité, l’administration responsable, le statut du système, la famille de technologie, le fournisseur principal, le type d’hébergement, les grandes catégories de données, la présence d’une intervention humaine, le coût connu, les dates, les indicateurs et les voies de recours lorsqu’elles existent. Les informations techniques dont la publication créerait un risque peuvent être omises avec une catégorie de justification.
Cette liste minimale évite que chaque administration publie une charte incomparable. Elle permet au citoyen de comprendre si un système le concerne et au Parlement de comparer les dépenses. Les champs sont structurés afin que le registre puisse être téléchargé et analysé sans extraction manuelle de centaines de pages HTML.
Réutiliser les données existantes plutôt que créer un nouveau formulaire annuel
Les projets disposent déjà d’informations dans les systèmes d’achat, de pilotage, de sécurité et de protection des données. Le registre doit les agréger autant que possible. Le responsable complète seulement les informations manquantes ou valide celles qui seront publiques. Les changements de version, fournisseur ou coût sont historisés automatiquement.
Cette conception réduit la charge et améliore l’actualité. Un registre alimenté une fois par an par un questionnaire manuel deviendrait rapidement obsolète et créerait précisément la bureaucratie que la réforme veut supprimer. La source technique de 9.11 peut alimenter plusieurs vues : une vue publique synthétique, une vue parlementaire plus détaillée et une vue d’audit. Une donnée n’est donc produite qu’une fois puis gouvernée selon les droits d’accès.
Publier les incidents de manière proportionnée
Un incident significatif doit apparaître dans le registre avec date, nature générale, conséquences, mesures correctives et statut. Il ne s’agit pas de publier des détails permettant de reproduire une attaque ni des données personnelles. Les incidents mineurs peuvent être agrégés.
Les critères de significativité sont définis afin d’éviter que seules les administrations les plus transparentes semblent avoir des problèmes. La publication montre aussi les corrections, ce qui transforme le registre en outil d’apprentissage plutôt qu’en tableau de honte. Les organes de contrôle accèdent à davantage de détails lorsque la loi le permet. Cette politique aide à mesurer la maturité : un système sans incident déclaré peut être excellent, ou simplement ne pas disposer d’un mécanisme sérieux de détection et de remontée.
Rendre visibles les coûts sans confondre contrat et coût complet
La fiche doit distinguer montant du marché, dépenses d’infrastructure, coût de développement interne et coûts de fonctionnement lorsqu’ils sont disponibles. Un grand contrat multi-services ne doit pas être attribué intégralement à un seul outil. À l’inverse, déclarer zéro coût parce que le projet utilise des agents existants masque la mobilisation de ressources.
La méthode peut donc publier une fourchette ou une ventilation avec niveau de confiance. Les économies annoncées sont affichées séparément avec leur méthode de preuve. Cette transparence permet de comparer les choix techniques et d’identifier les concentrations de fournisseurs, sans créer une fausse précision comptable. Elle facilite aussi l’audit des doubles comptes entre les différentes mesures du Plan.
Relier le registre à une vraie capacité de correction citoyenne et parlementaire
Chaque fiche doit indiquer un contact ou une procédure de signalement d’erreur. Un chercheur peut repérer un fournisseur mal identifié ; un agent peut constater qu’une fiche n’est plus à jour ; un parlementaire peut demander le détail d’une dépense. Les corrections sont historisées avec date.
Les données publiques disposent d’un mécanisme de version afin que les analyses puissent être reproduites. Le registre devient ainsi un bien documentaire durable plutôt qu’une vitrine. Le succès se mesure au taux de fiches à jour, aux délais de correction, à la couverture des systèmes et à l’utilisation des données par les organes de contrôle. Une plateforme réellement consultée et corrigée vaut davantage qu’un portail exhaustif le jour de son lancement puis abandonné.
Approfondissement opérationnel et conditions de réussite
Définir précisément ce qui doit être public et ce qui doit rester protégé
La transparence ne consiste pas à publier du code source, des clés, des données personnelles ou des informations facilitant une attaque. Le registre distingue les informations obligatoires — finalité, administration responsable, base juridique, grandes catégories de données, fournisseurs, coût, indicateurs, mécanisme de contrôle humain et voies de recours — des éléments dont la divulgation créerait un risque de sécurité ou violerait un secret protégé. Toute exemption est motivée et réexaminée. Un résumé public reste disponible même lorsqu’une annexe technique est restreinte. Cette méthode permet un contrôle démocratique réel sans transformer le portail en inventaire exploitable par un attaquant.
Faire du registre un outil d’inventaire interne autant qu’un outil citoyen
Une administration ne peut gouverner ce qu’elle ne sait pas recenser. Le même identifiant de projet est utilisé dans le registre public, le suivi budgétaire, les audits et les contrats importants. Les responsables doivent déclarer l’entrée en production, les changements de fournisseur, les évolutions majeures et l’arrêt du système. Les projets inactifs sont conservés dans l’historique plutôt que supprimés. Cette cohérence réduit le risque d’applications locales invisibles aux fonctions de sécurité ou de protection des données. Elle facilite aussi les audits transversaux : le contrôleur peut relier un coût, un incident, une version et une décision à un même objet sans reconstituer manuellement plusieurs bases administratives incompatibles.
Définir un schéma de registre commun à toutes les administrations
Chaque entrée du registre contient un identifiant, la finalité, l’administration responsable, le statut du projet, les principales catégories de données, le fournisseur ou composant important, l’environnement d’hébergement, le coût lorsqu’il est significatif, les indicateurs, la date de mise en production et le mécanisme de contrôle humain. Les champs techniques évolutifs sont séparés des informations stables afin d’éviter de réécrire toute la fiche à chaque changement de version. Le schéma est machine-readable et documenté. Des extensions métier restent possibles mais le noyau commun garantit la comparaison. Cette normalisation transforme le registre en infrastructure de gouvernance : les autres outils peuvent le réutiliser au lieu de demander une nouvelle saisie aux équipes.
Encadrer les exemptions de publication par une justification et une date de réexamen
Certaines informations peuvent relever de la sécurité, de la défense, du secret fiscal, médical ou commercial. L’exemption ne doit pas supprimer toute trace du système. La fiche publique peut indiquer qu’un projet existe, sa finalité générale, l’autorité responsable et la catégorie de motif qui limite le détail. Une date de réexamen est fixée car la sensibilité peut diminuer. Les contrôleurs habilités disposent d’un niveau d’information supérieur. Cette méthode évite une transparence dangereuse tout en empêchant la création d’une zone invisible où les projets les plus sensibles seraient aussi les moins gouvernés. Les motifs d’exemption sont harmonisés pour éviter qu’une administration qualifie systématiquement de confidentiel ce qu’une autre publie sans difficulté.
Suivre les événements du cycle de vie plutôt qu’une photographie annuelle
Le registre enregistre les étapes : expérimentation, décision de passage en production, changement majeur de modèle ou fournisseur, incident significatif, suspension et arrêt. Chaque événement possède une date et, lorsque nécessaire, un lien vers une décision ou un rapport. L’historique permet de comprendre qu’un projet aujourd’hui arrêté a néanmoins coûté de l’argent ou produit des enseignements. Il facilite aussi l’audit d’un système qui a beaucoup évolué. Cette logique d’événements est plus utile qu’un formulaire annuel qui écraserait l’état précédent. Elle peut être alimentée automatiquement à partir du portefeuille national et des plateformes techniques, réduisant la charge déclarative tout en améliorant la fraîcheur de l’information.
Permettre la correction publique et la réutilisation par une interface documentée
Les citoyens, chercheurs ou administrations doivent pouvoir signaler une erreur factuelle dans une fiche : statut obsolète, fournisseur changé, lien cassé ou définition incohérente. Le signalement suit une procédure et la correction reste historisée. Une interface de programmation permet aussi de réutiliser les données du registre pour l’index de recherche, le contrôle parlementaire ou des analyses externes. Les limites d’usage et la fréquence de mise à jour sont documentées. Cette ouverture réduit la tentation de construire plusieurs portails concurrents. Elle transforme la transparence en écosystème de données plutôt qu’en site vitrine. Les informations sensibles restent évidemment filtrées au niveau de la source commune, et non protégées seulement par l’interface graphique.
Registre public des IA : informer sans publier le mode d’emploi d’une attaque
Définir un socle de champs publics
Chaque système peut afficher administration responsable, finalité, population concernée, type d’IA, fournisseur ou solution, base juridique lorsque nécessaire, statut pilote ou production, date de dernière évaluation et contact. Ces informations permettent au citoyen de savoir où l’IA intervient.
Les détails susceptibles de compromettre la sécurité ou la lutte contre la fraude peuvent être réservés à un registre de contrôle non public.
Relier transparence et résultats
Le registre ne doit pas devenir un catalogue promotionnel. Pour les projets en production, il doit afficher au moins un indicateur de performance ou d’impact et signaler les audits disponibles. Un projet abandonné reste visible avec son motif afin que l’administration apprenne aussi de ses échecs.
Cette mémoire évite de recommencer le même prototype dans plusieurs ministères.
Automatiser l’actualisation depuis les portefeuilles de projets
Si chaque équipe doit remplir manuellement une nouvelle fiche, le registre risque de devenir obsolète. Les informations communes peuvent être importées des outils de gestion de projet et de sécurité, avec validation par le responsable.
Un indicateur de fraîcheur signale les fiches non mises à jour depuis plus de six mois.
Sources primaires et institutionnelles
Les affirmations de droit ou d’état de l’art ci-dessus sont rattachées à des sources publiques. Les hypothèses propres au Plan Delta-Sierra sont signalées comme propositions et ne sont pas présentées comme des chiffres officiels.
Date de vérification : 12 août 2026. Le cadre de l’IA évolue rapidement ; les dates d’application du règlement européen sont vérifiées contre le règlement (UE) 2026/1744.