Portail national de transparence publique : suivre budgets, dépenses, contrats et résultats depuis un point unique

1. La mesure existe-t-elle déjà ? Des briques existent, pas le portail unifié proposé ici

Le contrôle du corpus Delta-Sierra montre que plusieurs mesures de transparence sont déjà prévues dans la catégorie 11 : publication des rémunérations publiques, publication des marchés, déclarations d’intérêts, contrôle des marchés suspects et renforcement de la HATVP. Il existe aussi des mesures de transparence dans le numérique, les régimes dérogatoires et la rémunération. En revanche, aucune de ces lignes ne crée à elle seule une infrastructure publique unique couvrant l’exécution des budgets, les dépenses, les contrats, les subventions et leurs corrections. T.01 est donc ajoutée comme mesure transversale, sans renuméroter artificiellement le corpus historique des 155 mesures.

La France dispose déjà de nombreux systèmes publics et portails utiles. Chorus assure les fonctions budgétaires et comptables de l’État ; Budget.gouv publie des jeux de données et des visualisations ; les données essentielles de la commande publique sont diffusées en open data ; l’OFGL met à disposition des données financières locales. La proposition ne consiste donc pas à recommencer tous ces systèmes, mais à construire une façade publique fédératrice et un contrat de données commun qui évitent au citoyen de devoir connaître l’organisation interne de l’administration pour retrouver une information.

3. Ce qui serait publié : suivre la chaîne publique, pas seulement afficher un total

Le portail doit permettre de comprendre ce qui s’est passé. Pour une dépense, le citoyen doit pouvoir distinguer l’autorisation budgétaire, l’engagement, le service fait lorsqu’il est publiable, l’ordonnancement ou l’étape équivalente, le paiement, l’éventuelle annulation et la correction comptable. Pour un marché, il faut relier la procédure, le titulaire, le montant initial, les avenants, les échéances et les paiements effectivement rattachables. Pour une subvention, il faut relier la décision, le bénéficiaire lorsque la loi permet sa publication, l’objet, le montant, le programme budgétaire et, lorsque le dispositif le prévoit, le résultat ou le compte rendu d’utilisation.

La notion « tout publier » doit être traduite juridiquement : publier par défaut toute information administrative et financière qui est légalement communicable et techniquement exploitable, et documenter explicitement ce qui est masqué, agrégé ou différé. Une transparence crédible se mesure autant à la qualité des métadonnées qu’au volume brut de fichiers mis en ligne.

4. « Temps réel » : publication au fil de l’eau, sans confondre événement et compte certifié

Dans un système financier, un chiffre peut exister à plusieurs états. Une opération saisie n’est pas nécessairement validée ; une dépense engagée n’est pas encore payée ; une écriture peut être corrigée ; les comptes annuels ont leur propre processus de clôture et de certification. Afficher chaque événement comme s’il s’agissait immédiatement d’un chiffre définitif créerait une fausse précision.

T.01 retient donc un principe de fraîcheur qualifiée. Les événements communicables seraient publiés dès qu’ils franchissent le niveau de validation défini par le système source. Chaque valeur afficherait son statut : « provisoire », « rapprochée », « clôturée », « corrigée » ou « certifiée » lorsque cette qualification existe réellement. Le portail publierait également la date et l’heure de dernière synchronisation. L’objectif opérationnel serait une alimentation proche du temps réel pour les événements, mais aucune interface ne devrait transformer cette vitesse en prétention à une certification instantanée.

5. Périmètre : une porte d’entrée commune sans nier les différences entre administrations

Le portail doit donner une expérience cohérente tout en respectant les chaînes comptables différentes. L’État et ses ministères ne sont pas les collectivités locales ; les organismes de sécurité sociale ne sont pas les opérateurs de l’État ; un établissement public industriel peut être soumis à des règles de concurrence que ne connaît pas un service administratif. La centralisation de l’accès ne doit donc pas devenir une centralisation artificielle des responsabilités.

• État : ministères, programmes budgétaires et services dont les données financières passent par les systèmes de l’État.
• Opérateurs et établissements publics : intégration par connecteurs normalisés et obligations de publication adaptées à leur statut.
• Collectivités territoriales et établissements locaux : fédération avec les données financières locales, sans effacer la responsabilité de chaque collectivité.
• Organismes sociaux et autres personnes publiques : intégration progressive selon la disponibilité, la base juridique et la sensibilité des données.
• Commande publique : réutilisation des données essentielles déjà publiées et enrichissement par les liens d’exécution lorsque ceux-ci peuvent être établis de façon fiable.

6. Transparence maximale ne signifie pas exposition des données personnelles ou des secrets protégés

Le portail ne doit pas publier l’adresse privée d’un agent, une donnée médicale, une information couverte par le secret de la défense nationale, un élément compromettant une enquête, ni un secret des affaires lorsque le droit le protège. La bonne règle est une publicité par défaut des informations communicables, avec motifs de restriction codifiés et auditables. Une donnée non publiable au niveau individuel peut parfois être diffusée après anonymisation, agrégation ou délai.

Ce point est essentiel pour éviter une promesse juridiquement impossible. L’ambition n’est pas « tout montrer sans exception », mais faire de la transparence la règle et de la restriction une exception justifiée, traçable et proportionnée.

7. Architecture : fédérer les systèmes sources plutôt que construire une nouvelle comptabilité parallèle

Le portail ne doit pas devenir un second système comptable où des agents ressaisiraient manuellement des chiffres déjà présents ailleurs. Une telle architecture multiplierait les erreurs et les coûts. La cible est un système de publication alimenté par connecteurs, qui prend chaque information dans son système maître, la transforme selon un schéma public commun, lui associe un identifiant et conserve les versions successives.

Chaque enregistrement public devrait comporter au minimum : un identifiant stable, l’organisme responsable, le système source, la date de création, la date de dernière modification, l’état de validation, le millésime ou exercice, l’unité, le périmètre, le lien vers l’objet juridique ou budgétaire auquel il se rattache et l’historique des corrections. Quand une correction est nécessaire, l’ancienne valeur ne doit pas disparaître sans trace : elle est remplacée dans la vue courante mais reste présente dans le journal de versions avec la raison de la modification lorsque celle-ci est communicable.

8. Alertes et contrôle : détecter des anomalies sans créer un tribunal algorithmique

Une plateforme de cette taille permettrait de repérer des incohérences : doublons, ruptures de série, prix très éloignés de références comparables, contrats fractionnés, avenants nombreux, délais anormaux, données manquantes ou exécution très différente du budget voté. Ces signaux sont utiles pour orienter un contrôle, mais ils ne prouvent ni fraude ni faute. Le portail public doit donc séparer clairement signal statistique, contrôle administratif et constat juridiquement établi.

La même règle vaut pour les classements. Un « score de transparence » peut devenir trompeur si un organisme paraît mauvais uniquement parce qu’il publie une donnée complexe avec davantage de corrections. Les indicateurs pertinents sont plus concrets : taux de couverture des flux, délai de publication, taux d’erreurs de rapprochement, proportion de données dotées de métadonnées complètes, nombre de corrections expliquées et disponibilité effective de l’API.

9. Droit : consolider le principe d’accès et créer une obligation de publication financière structurée

Le projet s’inscrit dans une tradition juridique déjà forte : l’article 15 de la Déclaration des droits de l’homme et du citoyen affirme le droit de la société à demander compte à tout agent public. Le Code des relations entre le public et l’administration prévoit déjà la publication en ligne de catégories de documents, de bases de données mises à jour régulièrement et de données présentant un intérêt économique, social, sanitaire ou environnemental, tout en maintenant les secrets et protections prévus par la loi.

La réforme pourrait donc prendre la forme d’une loi ordinaire sur la transparence financière publique et la réutilisation des données d’exécution, complétée par décrets et référentiels techniques. Elle fixerait le périmètre, la fréquence minimale, les catégories obligatoires, les formats ouverts, la conservation des versions, les motifs de restriction, le responsable de chaque source et les voies de signalement des erreurs. Les règles propres aux finances publiques, à la commande publique, à la protection des données et aux secrets protégés resteraient applicables.

10. Déploiement : d’abord la qualité des données, ensuite le spectaculaire

Un portail graphique peut être construit rapidement ; une donnée publique fiable, reliée à sa chaîne comptable et publiée de manière régulière, demande davantage de travail. La réussite doit donc être mesurée par la couverture et la qualité, pas par le nombre de graphiques.

1. 0–6 mois : contrat de données et inventaire. Cartographier les systèmes, définir les champs communs, identifier les secrets et produire les premiers jeux fédérés.
2. 6–12 mois : pilote État. Brancher les principaux flux structurés, rendre visibles les statuts de validation et publier l’API avec documentation complète.
3. 12–18 mois : commande publique, opérateurs et subventions. Relier les objets juridiques aux flux d’exécution et étendre la couverture.
4. 18–24 mois : collectivités et généralisation. Fédérer les données locales avec l’OFGL et les chaînes comptables disponibles, sans imposer une ressaisie.
5. En continu : audit. Mesurer fraîcheur, complétude, erreurs, indisponibilités, corrections, performance et accessibilité.

Le coût de la mesure doit être chiffré séparément lorsqu’un dossier d’architecture et une trajectoire de raccordement auront été établis. Il serait trompeur d’annoncer dès maintenant un montant unique sans inventaire des systèmes sources, des interfaces déjà disponibles et des obligations existantes. De la même manière, d’éventuelles économies liées à la détection d’anomalies ou à la réduction des demandes manuelles d’accès ne doivent pas être comptabilisées comme certaines avant mesure.