SCDL - Données essentielles de Budget

Bonjour à tous,

je prépare actuellement les données issues du SCDL, et travaille donc sur les données essentielles de Budget.
Quelles sont les bonnes pratiques vous concernant ?

  • faut-il publier un seul et unique jeu de données, par année, qui contient toutes les étapes budgétaires ?
  • ou est-il préférable de publier à chaque étape budgétaire un jeu de données ?

Issues des flux totem, ces informations au CD53, semblent pouvoir être communiquées à chaque étape budgétaire : BP, BS, DM et CA.

Je ne sais donc pas par quel bout prendre ce sujet.

Par avance, merci pour vos retours,
Amélie
Chargée de gouvernance des données CD53

1 « J'aime »

Bonjour Amélie,

Je travaille aussi sur ce sujet actuellement, je pense que ça peut être intéressant que nous échangions ensemble. Mon adresse mail : [email protected]

Bien à toi,
Raphaël.

J’attaque aussi! J’avoue être un peu « aidé » (au sens de la contrainte est aussi une opportunité!) en l’espèce parce qu’on m’a demandé de commencer par le (seul) compte administratif soumis en conseil cette année…Pour l’instant, je fais en sorte de récupérer les fichiers xml correspondant aux comptes administratifs tels qu’ils ont été transmis au contrôle de légalité (version budgétaire) via Acte Budgétaire. Je vous tiens au courant au fur et à mesure de l’avancée de ce dossier, je suis optimiste!

Bonjour à tous,

De notre coté (Département de l’Hérault), nous utilisons des traitements de conversion des flux Totem XML (vers formats tabulaires) paramétrés depuis OpenDataSoft. Ca converti directement les flux dans une nomenclature SCDL.

Vous pouvez trouvez les jeux de données transformées pour les différentes étapes budgétaires (budgets primitifs, décisions modificatives, budgets supplémentaires, comptes administratifs) : Explore — Hérault Data.

Pour info, le portail Dataclic, propulsé par OpenDataFrance et Adrien Pavie, propose également une convertisseur : DataClic

Victor Kahn

1 « J'aime »

Cela fait malheureusement quelque temps que le convertisseur « budget locaux » de DataClic ne fonctionne plus.

Bonjour,

Désolé par avance de la longueur de ce message qui témoigne à la fois de notre intérêt pour le sujet et des problèmes rencontrés.

Nous avons mis en place, dans le cadre de la démarche DataGrandEst, un groupe de travail sur l’ouverture des données budgétaires des collectivités. L’objectif est de faciliter leur publication de façon mutualisée. A ce stade, nous avons 5 ou 6 collectivités représentatives d’à peu près tous les niveaux administratifs (commune, EPCI, PNR, Département et Région) qui testent la standardisation de leurs données. Nous rencontrons cependant plusieurs problèmes lors de la conversion et de la validation.

Nous avons par ailleurs des question d’ordre organisationnel du même type que celles soulevé par Amélie dans son message initial.

Nous sommes à la fois à la recherche de solutions et de retours d’expérience.

Voici les principales difficultés rencontrées :

1. La conversion des fichiers XML TOTEM via l’outil DataClic ne fonctionne pas correctement

Les fichiers résultants de la conversion ne peuvent être validés par Validata.

Pour les budgets de 2017, 2018 et 2019 nous ne rencontrons généralement pas d’erreur (excepté un problème de majuscule sur les intitulés de la première colonne – ex. : « Compte administratif » - erreur corrigée à notre demande dans la dernière version de DataClic mise en ligne il y a quelques semaines).

Par contre, pour les budgets récents de 2020, 2021 et 2022 certains codes des colonnes « BGT_CONTNAT » et « BGT_NATURE » n’ont visiblement pas de correspondance et les colonnes « BGT_CONTNAT_LABEL », « BGT_NATURE_LABEL » et « BGT_SECTION » sont donc vides.

D’après les retours des collectivités concernées, cela ne provient pas d’un problème de fichier XML TOTEM.

Nous considérons cela comme bloquant.

Sommes-nous les seuls à essayer de standardiser nos données via ces outils et à avoir rencontré ces problèmes ? Existe-t-il des alternatives ? Des solutions de contournement ?

2. Budget par nature et par fonction

Le budget de la Région Grand Est est un budget par fonction, or les outils proposés semblent être utilisables uniquement pour les budgets par nature.

Certains d’entre vous ont-ils déjà rencontré ce problème ?

3. Passage à la M57

Au 1er janvier 2023, la Région Grand Est va passer au plan comptable M57.

Savez-vous si les outils proposés sont-ils compatibles avec ce plan comptable ? Si non, des évolutions sont-elles envisagées dans les mois à venir ?

4. Le grand nombre de fichiers par collectivité rend l’organisation et la publication complexe

Une collectivité comme St Louis Agglomération a identifié 32 jeux de données de budget à publier par an selon les types de documents (BP, BS, CA et BA) et du fait qu’elle dispose de 8 budgets annexes.

Cela représente tout d’abord un travail conséquent. Ensuite cela pose la question de la capacité des utilisateurs à pouvoir s’y retrouver facilement. A terme dans un catalogue comme DataGrandEst cela représentera plusieurs centaines de fichiers par collectivité selon le budget, son type et son millésime, soit une base de plusieurs milliers de jeux de données à l’échelle du Grand Est.

Comment procéder pour faciliter la publication au niveau local et garder une certaine lisibilité dans ce travail ? Faut-il tout regrouper par année ? Par type de budget ? etc.

A noter également que certains fichiers issus de la conversion via DataClic sont vides. Faut-il les conserver dans la publication (pour montrer que ce n’est pas un oubli) ou les supprimer ?

Enfin nous nous interrogeons sur les acteurs impliqués dans ces outils, la gouvernance du projet, sa maintenance et sa pérennité. Il y a-t-il un portage (institutionnel) officiel de la démarche ?

Vous remerciant par avance, je reste à disposition pour échanger sur ces différents points.

Guillaume R.
Chef de projet données / Coordinateur DataGrandEst
Région Grand Est

Perso, je n’utilise pas dataclic car j’ai des besoins de traitement plus simples (uniquement les lignes budgétaires et pas les annexes), donc j’ai juste bidouillé un script tout bête en php (old school :rofl: ) et donc pas en mesure d’identifier précisément les pb…

Si le problème ne concerne pas que les budgets votés par fonction, difficile de cherche l’origine du problème sans les fichiers totems correspondant.

DataClic ne fonctionne effectivement que pour les budgets votés par nature, il faudrait faire évoluer le code du script totem2csv ( totem2csv · master · datafin / totem · GitLab) utilisé par dataclic de manière à ajouter une détection du paramètre « NatFonc » afin d’adapter les données à sortir (par exemple remplir BG_CONTNAT avec la valeur de contNat ou contFon) si la valeur de NatFonc est 2.
Et aussi modifier / variabiliser la ligne
<xsl:variable name="chapitre" select="$plan_de_compte/Nomenclature/Nature/Chapitres/Chapitre[@Code=$contNat]" />
en
" <xsl:variable name="chapitre" select="$plan_de_compte/Nomenclature/Fonction/Chapitres/Chapitre[@Code=$contFon]" />
Et probablement quelques autres ajustements du même type…

Je ne pense pas que le passage à la M57 pose de problème majeur spécifique puisque le script dataclic va chercher directement à la source les schémas des nomenclatures comptables sur Actes Budgétaires : TotEM, documents et maquettes (odm-budgetaire.org)

Par contre, à voir si les fichiers totems des collectivités ayant optées pour le CFU (compte financier unique) restent compatibles…

La charge de travail par collectivité (concernant la création des jeux de données) est quand même assez relative : s’il n’y a pas à « courir » après la récupération des fichiers totems, il faut moins d’une minutes par « conversion » donc moins d’une heure par an.
La vraie charge de travail est probablement la mise en ligne des jeux dans l’outil « portail open data ». Et avec autant de jeux, la mise en ligne devrait donc probablement être totalement automatisée et ne devrait pas demander d’autres actions que « déposer / uploader les jeux » à un emplacement spécifique, un script venant ensuite alimenter seul l’outil de mise en ligne.
Sinon, c’est vrai que cela peut vite devenir ingérable et représente vite un gâchis de temps… et l’assurance que la publication cesse au bout d’un ou deux ans !

Pour la mise à disposition, regroupement, etc… je pense qu’il n’y a pas de réponse simple : chaque éventuel ré-utilisateur aura sa préférence selon l’usage qu’il en attend.
Mais perso, mes données « pivots » de base et « d’interrogation » sont l’année et le code siret du budget, donc pour mon usage le plus simple serait une organisation hiérarchique sans « regroupement » régional nécessaire : siret du budget (nom du budget correspondant en affichage « public ») > année > étape budgétaire.
(et même idéalement avec des url standardisées pour permettre l’interrogation / le téléchargement automatisé des jeux de données)

Pourquoi sans regroupement régional : parce que ce regroupement serait compliquer / retarder la publication par les différences de date de vote (budget voté début décembre par certains, début avril pour d’autres) ou d’adoption des CA sans parler de la liberté totale quand aux DM / BS. Soit on devrait attendre le dernier budget voté pour avoir le jeu, soit le jeu serait complété au fur et à mesure des votes mais alors difficile de suivre les mises à jour. Et sauf pour les CA qui présentent un intérêt à long terme, la durée de vie l’intérêt des jeux de données « budget prévisionnel » est faible faible…

Le problème n’est peut-être pas vital mais effectivement, les conserver évite le questionnement potentiel sur un éventuel oubli.

Aucune gouvernance institutionnelle à ma connaissance donc aucune garantie sur la maintenance / pérennité des outils type dataclic qui repose sur la bonne volonté / motivation de leurs créateurs… Cela dit, comme ils sont en open source, en cas d’abandon, il pourront toujours être repris si des bonnes âmes s’y collent.
Et peut-être qu’un jour des institutionnels comme l’AMF ou l’OFGL s’intéresseront à ce type de sujet concret et utile (mais ce genre de problématique technique est-il suffisamment sexy pour qu’ils s’y intéressent?)

Bonjour,
Désolé pour mon délai de réponse, j’attendais de faire le point avec notre groupe de travail avant de revenir avec nos avis, commentaires et éléments d’analyse.
Merci pour ce retour très riche. Nous sommes d’ailleurs surpris qu’il n’y ait pas eu plus de réactions. Le sujet n’intéresse-t-il que peu de monde, ou sommes nous les seuls à rencontrer des problèmes ?

C’est une question que l’on se pose de savoir s’il n’existe pas d’autre outils disponibles sur la question du budget, pour convertir, transformer ou valider les données.
Vos scripts sont-ils spécifiques ? Seraient-ils éventuellement partageables ?

Nous partageons ce constat initial, mais dans les faits, quand la validation ne se passe pas comme prévue cela prend tout de suite des proportions plus importantes en termes temps.

On est tout à fait d’accord. Dans le cas de DataGrandEst, l’ensemble des budgets est stocké dans le même catalogue mais au-delà de ça chaque structure publie ses propres fiches de métadonnées et données associées. Le principe d’un URL standardisé est en effet idéal car il apporte de l’homogénéité dans l’accès à la donnée et se rapproche d’une pseudo notion d’API.

Par contre, ce qui inquiète grandement les acteurs souhaitant publier leurs données, c’est que la validation avec Validata renvoie des erreurs. L’analyse de base conduit à 3 hypothèses : soit c’est le convertisseur qui est bogué, soit c’est Validata, soit c’est une erreur dans les fichiers Totem (ce qui serait inquiétant…).
J’ai regardé le code du convertisseur, rien ne me semble très compliqué dans le formatage effectué… Bizarrement, dans la plupart des cas les erreurs analysées jusqu’à présent viennent d’un problème de correspondance à cause de « ContNat » non présents dans les chapitres du plan de compte.

Dans tous les cas, à ce stade, on se trouve proche d’une situation de blocage au niveau de DataGrandEst, aucun acteur du groupe de travail ne souhaitant publier des données qui pourraient s’avérer erronées.

Cela n’est pas non plus trop rassurant car les données budgétaires sont quand même politiquement sensibles surtout si on risque de publier des informations erronées. Ce n’est pas un sujet que technique contrairement à ce que l’on croit.
Une idée émise par le groupe de travail : ne faudrait-il pas pousser le ministère, via par exemple les instances nationales (OpenDataFrance ?) ou locales (élus ? DGFiP ?), à intégrer la conversion CSV directement dans l’application Totem ? Est-ce seulement envisageable ?

Merci d’avance pour les avis et retours d’expérience de chacun!

Non, pas partageables car effectivement trop spécifiques… je ne ressort pas toutes infos (écritures d’ordre, annexes, etc…) mais uniquement celles qui me sont nécessaires à mon application d’analyse financière rétrospective / prospective…

Effectivement, je viens de tester le flux xml d’un client généré par Berger-Levreault et effectivement, et la balise « contNat » est absente pour de nombreuses lignes budgétaire.

Tel qu’il est conçu, l’outil de conversion de dataclic présume que cette donnée est forcément présente dans les fichiers totem pour toutes les lignes budgétaires et donc retourne un champ vide dans BGT_CONTNAT, ce qui qui fait échouer la validation Validata.

Je ne sais pas si c’est une erreur de Berger-Levreault de ne pas renseigner systématiquement ContNat… (pas sûr car cela ne fait pas partie des contrôles de conformité totem : Contrôles sur les Documents Budgétaires (odm-budgetaire.org)

Je ne sais pas si ce problème est propre à Berger-Levreault ou si c’est aussi le cas avec les flux générés par d’autres logiciels comptables. Mais comme Berger-Levreault est probablement l’éditeur majoritaire…

Perso, je n’ai pas ce problème, car je ne récupère que le code de l’article, puis je vais chercher le chapitre non pas dans le fichier totem via ContNat mais dans le fichier xml de définition de la nomenclature comptable récupéré sur Actes Budgétaires : TotEM, documents et maquettes (odm-budgetaire.org) s’il ne s’agit pas d’une ligne « Opération budgétaire » ou j’utilise comme chapitre le numéro d’opération s’il s’agit d’une ligne rattaché à une « Opération budgétaire »…

Donc effectivement, tel qu’il est conçu, Dataclic ne peut pas actuellement produire de jeu de donnée complet et est donc forcément non valide…

Bonjour,
Merci, une fois de plus, pour l’analyse réalisée et ce retour très intéressant.

N’étant pas un fin connaisseur du budget, je ne suis pas sûr de tout comprendre de ces éléments et pouvoir les exploiter pleinement. Cela m’intéresse cependant d’essayer d’évaluer les modifications à apporter à DataClic et Validata. Je reste à disposition éventuellement pour convenir d’un échange téléphonique ou visio pour en discuter.
Je me suis par ailleurs permis d’attirer l’attention des développeurs de ces solutions et d’OpenDataFrance sur votre message.

Cela n’est pas très encourageant à ce stade, et donne finalement raison aux membres de notre groupe de travail qui s’est positionné pour ne pas diffuser leurs données budgétaires en open data à ce stade, sans garantie de la fiabilité et de la justesse des informations mises en ligne, qui restent très sensibles politiquement (d’autant plus si elles sont erronées !!!).

Encore merci pour votre appui dans la compréhension de ces éléments!

Message Supprimé

Bonjour à tous,

En tant qu’outsider du monde budgétaire, j’ai une question aux représentants de collectivités qui ont contribué à ce fil : « Que publiez vous en plus que ce que nous retrouvons sur le portail des données financières et de gestion du secteur public local ? »

Bonjour,

Merci pour ce partage. J’ai aussi pris connaissance de ce portail il y a peu de temps.
Il est certains qu’il pose la question de la stratégie nationale en terme d’ouverture et de diffusion des données locales. Une fois de plus ce n’ai pas clair…

  • Est ce que l’OFGL permet aux collectivités de répondre aux obligations de la loi pour une République Numérique ?
  • Qu’est-ce que l’on y trouve exactement ?
  • Est-il conforme au schema proposé dans le cadre du SCDL ? (J’ai l’impression que non…)
  • Va-t-on pouvoir y brancher les tableaux de bord mis en place et consommant les données au format SCDL ?
  • Faut-il revoir ou abandonner les outils et processus de publication mis en place au niveau local ?
  • Quel avenir pour le schéma du SCDL relatif aux données budgétaires des collectivités porté par OpenDataFrance et schema.gouv.fr ? Faut-il l’abandonner, le re mettre en question?
  • Quel avenir pour les outils mis en place par OpenDataFrance ?
  • Etc.

Si quelqu’un a des éléments de réponse ont est preneur pour savoir dans quelle direction aller.

Bonne journée à tous !

Guillaume

Oh… quand même… il manque au moins un champs ici:

Bonjour,

Pour répondre à vos questions, une piste serait d’échanger avec les financiers territoriaux et l’équipe de l’OFGL. Ce que fait régulièrement l’AFIGESE au travers, notamment, de ses groupes de travail dont j’anime l’un d’entre eux. N’hésitez-pas à nous contacter.

Je précise…

Dans ce superbe jeu de données, on a le nom de la commune (deux fois tant qu’à faire), mais pas de code INSEE, ni même de numéro de département (ce qui ne suffirait pas vu qu’il existe des communes homonymes au sein d’un même département, si si !).

Devinette: Il y a quand même un moyen très alambiqué de retrouver ses petits… lequel ?

Pourtant j’ai aperçu ceci dans le modèle de données :

Sinon pour la devinette : en passant par le SIREN de l’EPCI ? :slight_smile:

Mea culpa (ou presque)… la présentation « tableau » n’affiche pas toutes les colonnes, quelle idée !

Donc oui, il y a bien plus d’infos que ce qui est visible sur l’interface web. Si le code INSEE avait vraiment manqué, on avait la population qui aurait permis de s’en sortir :wink:

Bonjour,
Par ailleurs, il semble d’après des échanges récents que j’ai eus avec une collectivité que certains comptes natures peuvent être subdivisés par l’ordonnateur et être spécifiques à la collectivité, d’où l’impossibilité de récupérer le libellé…
Le constat que je fait à ce stade est donc que ce n’est pas tant DataClic qui pose problème que le schéma lui-même qui rend obligatoire des champs dont on ne peut pas connaître intrinsèquement la valeur. En témoigne le ticket suivant : Écarts constatés avec le schéma de données TotEM au format XML. (#5) · Issues · SCDL / Schéma Budget · GitLab