Plateforme de données de la commande publique

Le Service Marché recevait les données des marchés sous la forme d'une volumineuse extraction en tableur, exploitée à la main. J'ai conçu et réalisé seul la chaîne qui transforme cette extraction en données fiables pour la Direction : un ETL Python organisé en couches bronze, silver et gold, un catalogue de 35 règles qualité avec quarantaine, un entrepôt SQL Server en étoile, un modèle sémantique Power BI traçable à la ligne, et des métadonnées DDI publiées dans un catalogue à accès contrôlé.

Le point distinctif est la vérifiabilité. Chaque exécution se termine par un certificat d'intégrité : un arbre de Merkle sur toutes les empreintes de ligne, recalculé depuis la source, les données nettoyées et l'entrepôt. Tout chiffre du tableau de bord se rattache à son exécution, à son fichier et à sa ligne de tableur, et un tiers peut le vérifier sans accès au poste.

La Direction du Contrôle Financier contrôle les engagements de dépense publique, dont les marchés. Le Service Marché avait besoin d'une vue fiable des volumes, des modes de passation, de l'exécution et de la qualité des données, alignée sur le Code des marchés publics (ordonnance n° 2019-679).

Je n'exploite pas le système d'information source : je travaille à partir de l'extraction des marchés demandée par le Service. L'outil a été réalisé à la demande de la cheffe du Service Marché et constitue aussi le sujet de mon mémoire de fin de formation.

• Une analyse manuelle et non reproductible d'un tableur de plusieurs milliers de lignes.
• Des doublons, des montants incohérents et des champs en texte libre, sans trace de ce qui avait été corrigé.
• Aucun moyen de prouver qu'un chiffre du tableau de bord correspondait à la source, ligne à ligne.
• Des personnes nommées dans les données : toute publication devait séparer le public, le réservé et l'interne.

• Reproductible : la même extraction donne toujours le même entrepôt, et une exécution est refusée si un contrôle échoue.
• Traçable jusqu'à la ligne source, depuis n'importe quel visuel du rapport.
• Documentée selon un standard international (DDI), sans statistique saisie à la main.
• Confidentielle par construction : aucun nom de personne dans une sortie publique.
• Contraintes : un seul poste, SQL Server en édition d'évaluation, Power BI sans Premium, aucune donnée hors de l'administration.

Une source : l'extraction des marchés et contrats, reçue en classeurs Excel. Le pipeline impose un contrat d'entrée de 24 colonnes, relit à chaque exécution tous les classeurs du dossier brut, ignore les fichiers temporaires et archive une copie exacte de chaque source sous un nom qui porte son empreinte SHA-256. Les sources ne sont jamais déplacées ni modifiées.

• Étoile stricte de Kimball : segments et axes sur les seules dimensions ; la table de faits porte les clés, montants, indicateurs et attributs propres au marché.
• Dix relations à sens unique des faits vers les dimensions, aucun filtre bidirectionnel.
• Codes de section budgétaire rattachés à des sigles uniques par un référentiel tenu par l'ETL et garanti par une contrainte UNIQUE, à la place d'une colonne DAX qui devinait le sigle par mots-clés et donnait le même sigle à 17 des 39 sections.
• Dimension de l'exercice budgétaire comme table de temps ; tables de dates automatiques désactivées.
• Pour les extensions analytiques, une dimension d'audit par exécution de modèle : chaque résultat porte son exécution, son certificat et ses versions logicielles.

• Bronze : classeurs bruts, lus dans un ordre déterministe, et archive horodatée par empreinte.
• Silver : libellés et montants normalisés, durées interprétées avec conservation de la saisie d'origine, empreinte calculée pour chaque ligne, doublons stricts mis en quarantaine.
• Gold : tables recréées et chargées dans SQL Server, une ligne de journal par exécution, export consolidé en CSV et Parquet, et rapport qualité listant chaque ligne signalée.
• Dernière étape : le certificat d'intégrité, écrit dans un registre et dans une table de l'entrepôt lue par le rapport.
• Chaque modification du projet Power BI passe par un script Python idempotent, essayé d'abord sur une copie, avec un vérificateur qui contrôle chaque champ et chaque filtre des visuels contre le modèle.

• Un catalogue versionné de 35 règles, chacune avec un identifiant cité dans le rapport à côté du constat qu'elle produit.
• Six contrôles d'anomalie présentés aux utilisateurs (anomalies de montant et de forme), et des règles rattachées aux articles du Code des marchés, comme les avenants au-delà de 30 % du montant.
• Comparabilité explicite : une évolution annuelle n'est affichée que si l'exercice précédent est exactement N-1, si chaque exercice compte au moins 30 enregistrements et si le plus petit volume atteint 25 % du plus grand. Sinon, le rapport indique « Aucun N-1 fiable ».
• Taux d'exécution affiché avec sa base : sous 10 % du montant engagé, il est grisé, dit indicatif et exclu des classements et des alertes.
• Certificat de Merkle (RFC 6962) : les feuilles sont les empreintes de ligne, la racine est recalculée depuis la source, le silver et le gold ; modifier un franc dans une copie est détecté et localisé à sa ligne de tableur.
• Boucle de retour métier : un échantillon stratifié de lignes signalées examiné par le Service (corrigé, justifié, à revoir), avec la précision de chaque règle et son intervalle de Wilson.

• Champs nominatifs (agents, contrôleurs financiers) documentés mais jamais publiés : ils n'apparaissent que dans des fichiers réservés et dans une annexe à diffusion restreinte.
• Quatre profils d'accès au catalogue : visiteur, compte standard, compte habilité et administrateur, avec journal des téléchargements.
• Stockage du catalogue sorti de la racine web, API d'administration réservée aux administrateurs, et un défaut de configuration des rôles du logiciel de catalogue découvert par les tests puis corrigé.
• Secrets lus dans des variables d'environnement, jamais écrits dans les notebooks ; tous les calculs restent sur le poste de l'administration.

• Traçabilité entre couches : les numéros de ligne de la source, du silver et du rapport qualité suivent des règles différentes ; ils ont été déduits de l'ordre de lecture déterministe et vérifiés sur des lignes témoins avant affichage.
• Les identifiants de l'entrepôt sont réattribués à chaque rechargement : la traçabilité repose donc sur l'empreinte de ligne, stable tant que la ligne n'est pas modifiée.
• L'export du logiciel de métadonnées perd les statistiques des variables sans le signaler : la source de publication a été fixée au fichier du notebook et comparée rubrique par rubrique à la fiche publiée.
• Les animations et étiquettes de Power BI ne se comportent pas de la même façon à l'écran et à l'export PDF : les alertes ont été conçues pour rester lisibles une fois imprimées.

• Un pipeline exécuté en production sur le poste, refusé automatiquement si un contrôle échoue.
• Un rapport Power BI de plusieurs pages, avec pages d'impression A4, fiche de traçabilité par extraction et annexe à diffusion restreinte.
• Une fiche DDI 2.5 de 65 variables publiée dans le catalogue interne, avec le certificat d'intégrité joint comme document.
• Six documents de gouvernance (politique de confidentialité, conditions d'utilisation, politique de sécurité, guides), rédigés pour validation par la Direction.

• Les seuils d'alerte et les sigles de section attendent une validation formelle de la Direction.
• L'extraction ne contient ni l'attributaire, ni son numéro de compte contribuable, ni les dates d'étape : concentration des titulaires, fractionnement et délais ne peuvent pas encore être analysés de façon fiable.
• L'historique antérieur à l'exercice en cours est mince : la plupart des comparaisons annuelles sont volontairement neutralisées.
• Déploiement sur un seul poste avec SQL Server en édition d'évaluation : une édition supportée et un environnement partagé sont des préalables à un usage élargi.

• Étendre le contrat d'entrée à l'attributaire, au numéro de compte contribuable et aux dates d'étape, puis ajouter des indicateurs de concentration et de délai.
• Passer à une édition supportée de SQL Server, avec exécutions planifiées et espace de rapports partagé.
• Intégrer au catalogue de règles les contrôles forensiques validés (procédure au-dessus de son plafond, fractionnement présumé).
• Réinjecter les décisions examinées dans le score de risque, puis évaluer un modèle supervisé.