--- tags: ["note"] type: "note" nature: lieu, portrait, info... ressource: false univers: PRO projects: - "PROJET" date: "2026-08-04" priority: 10 --- # Pilotage budget analyse v2 Pour l’implémentation Grist voir : [[04_NOTES/PILOTAGE-BUDGET_Mistral_Gestion_Grist]] Je pilote plusieurs projets en parallèle d'un point de vue opérationnel. J'ai besoin d'optimiser la gestion financière de ces projets. Ces projets sont basés sur des marchés Chaque MARCHE peut avoir un ou plusieurs LOTS. Chaque lot a un montant maximal de dépense qui correspond généralement au budget global Chaque lo peut avoir un ou plusieurs titulaires (cotraitants) et un ou plusieurs sous-traitants liés au titulaire par DC4 qui défini la somme que le sous-traitant peut dépenser sur l'ensemble du marché. D'un point de vue financier, une fois le marché attribué, le workflow est le suivant: 1. Émission d'un bond de commande sur la base d'un BPU. Le bond de commande précise les prestations attendues et les coûts. 2. Réalisation et validation des prestations. 3. Facturation des prestations. Elle peut être totale ou partielle (soit en pourcentage de réalisation - ex. étape 1 uniquement, soit en temps - ex.: hébergement annuel avec facturation tous les 3 mois, soit couvrir qu'une partie des lignes du bon de commande). 4. Validation du service fait. 5. Paiement. Mon objectif n'est pas de reproduire l'ensemble de la comptabilité et du suivi financier du projet, mais de disposer d'un outil de pilotage permettant de savoir ce qui est attribué à réaliser, payer, solder, programmer, etc. Je souhaite ainsi conserver une vision globale facilitant le suivi des opérations et me permettant de réaliser un état des lieux à tout moment. Peux-tu me conseiller et m'aider dans la réalisation et la mise en œuvre d'un tel système ? ![[04_NOTES/Budget_2026-08-04_15-24-29.webp]] ![[04_NOTES/Budget_2026-08-04_15-25-03.webp]] ![[04_NOTES/Budget_2026-08-04_15-25-37.webp]] # Système de pilotage financier — marchés multi-lots ## 1. Choix d'outil | Critère | Excel/Sheets | Airtable / Baserow / NocoDB | Appli sur mesure | |---|---|---|---| | Relations réelles entre tables | Non (à base de RECHERCHEV fragiles) | Oui, natif | Oui | | Calculs automatiques (cumuls, soldes) | Manuel, casse facilement | Rollups/lookups automatiques | Oui | | Multi-utilisateur simultané | Limité | Natif | Natif | | Tableau de bord visuel | Basique | Bon (mode "Interfaces") | Illimité | | Coût / délai de mise en œuvre | Faible | Faible à modéré (jours) | Élevé (semaines/mois) | | Adapté à 10-50 lots, équipe 2-5 pers. | Sous-dimensionné au-delà de 20 lots | **Cible idéale** | Surdimensionné | **Recommandation : Airtable** (ou Baserow/NocoDB si vous voulez de l'open-source auto-hébergé, le modèle ci-dessous est identique). Le modèle relationnel proposé reste portable vers une base SQL classique si le besoin grandit. --- ## 2. Modèle de données Voir le diagramme ERD affiché dans la conversation. Détail des tables : ### MARCHE- Référence, objet, date d'attribution, statut (en cours / clos) - Montant global estimé (informatif, la vraie limite est portée par les lots) ### LOT - N° de lot, objet, **montant maximal** (budget plafond) - Statut : actif / soldé / clos - Rollup : total engagé (somme des BC), total facturé, total payé, solde disponible = montant max − engagé ### TITULAIRE (cotraitant) - Lié à un lot, nom, rôle (mandataire / cotraitant), % de répartition le cas échéant ### SOUS\_TRAITANT - Lié à un titulaire, nom - **Champ DC4** : montant plafond autorisé **sur l'ensemble du marché** (attention : ce n'est pas au niveau du lot — un même couple titulaire/sous-traitant peut apparaître sur plusieurs lots du même marché, il faut alors cumuler) - Rollup : montant déjà facturé par ce sous-traitant sur tous les lots du marché / solde DC4 restant ### BON\_COMMANDE (BC) - Lié à un lot et à un titulaire, n° de BC, date d'émission - Montant total du BC (somme des lignes) - Statut : émis → en cours de réalisation → réalisé → facturé partiellement → soldé ### LIGNE\_BC - Lié au BC, désignation (référence BPU), quantité, prix unitaire, montant ligne - % réalisé (mis à jour à la validation du service fait) ### FACTURE - Liée à un BC, n° de facture, date, montant HT/TTC - Type : totale / partielle (% avancement) / partielle (période) - Statut : émise → service fait validé → payée ### LIGNE\_FACTURE - Lien vers la ligne de BC couverte, montant facturé sur cette ligne - Permet de suivre précisément le reste-à-facturer par ligne, même en cas de facturation étalée (ex. hébergement trimestriel) ### PAIEMENT - Lié à la facture, date, montant payé, référence de virement --- ## 3. Statuts et cycle de vie **BC** : \`Émis\` → \`En cours\` → \`Service fait validé\` → \`Facturé (partiel)\` → \`Facturé (total)\` → \`Soldé\` **Facture** : \`Émise\` → \`Service fait validé\` → \`En attente de paiement\` → \`Payée\` Règle clé : un BC passe à \`Soldé\` uniquement quand la somme des \`LIGNE\_FACTURE\` couvre 100% de chaque \`LIGNE\_BC\` **et** que toutes les factures associées sont payées. --- ## 4. Indicateurs de pilotage (champs calculés à créer) Au niveau **Lot** : - \`Montant engagé\` = Σ montant des BC du lot - \`Montant facturé\` = Σ montant des factures liées aux BC du lot - \`Montant payé\` = Σ montant des paiements liés - \`Solde disponible\` = Montant max − Montant engagé - \`Taux de consommation\` = Montant engagé / Montant max (alerte si > 90%) - \`Reste à facturer\` = Montant engagé − Montant facturé Au niveau **Marché** (rollup depuis les lots) : - Budget total, engagé total, facturé total, payé total Au niveau **Sous-traitant** (agrégation sur tous les lots du marché) : - \`Cumul facturé sous-traitant\` vs \`Plafond DC4\` → alerte si dépassement imminent (ex. > 85%) Au niveau **BC** : - \`Reste à réaliser\`, \`Reste à facturer\`, \`Reste à payer\` --- ## 5. Vues / tableau de bord à construire 1. **Vue synthèse par marché** : budget / engagé / facturé / payé / solde, en cartes ou barres de progression 2. **Vue par lot** : liste avec taux de consommation, code couleur (vert < 70%, orange 70-90%, rouge > 90%) 3. **Vue "à traiter"** (Kanban par statut de BC) : BC à réaliser / à facturer / service fait à valider / à payer 4. **Vue sous-traitants** : suivi des plafonds DC4, alerte si seuil approché 5. **Échéancier de facturation** : pour les prestations récurrentes (ex. hébergement trimestriel), une vue calendrier des prochaines factures attendues 6. **Vue "état des lieux"** exportable : photo instantanée de tous les indicateurs à une date donnée (utile pour vos reportings) --- ## 6. Plan de mise en œuvre (4 phases) **Phase 1 — Structure (1-2 jours)** Créer les 10 tables dans Airtable, définir les champs et les liens (linked records). **Phase 2 — Calculs (1 jour)** Ajouter les rollups/lookups pour les montants engagés/facturés/payés à chaque niveau. **Phase 3 — Reprise des données existantes (variable selon volume)** Importer marchés/lots/titulaires actuels, puis les BC et factures en cours. **Phase 4 — Vues et automatisations (1-2 jours)** Construire les vues listées ci-dessus, créer une interface de tableau de bord (Airtable Interfaces), et éventuellement une automatisation d'alerte (email/Slack) quand un seuil de consommation ou de DC4 est franchi. --- ## 7. Points d'attention particuliers - **DC4 au niveau marché, pas lot** : bien agréger sur l'ensemble des lots où le couple titulaire/sous-traitant intervient. - **Facturation partielle multiforme** (avancement, période, lignes partielles) : la table \`LIGNE\_FACTURE\` est la clé — elle seule permet de savoir précisément ce qui reste à facturer ligne par ligne, quel que soit le mode de facturation. - **Ne pas dupliquer la comptabilité** : cet outil ne remplace pas la facturation/comptabilité fournisseur, il en est le reflet de pilotage — les montants doivent rester alignés avec les documents sources (BC, factures, PV de service fait), sans réinventer la génération de ces documents.