Extraire les demandes d'achat BTP vers Excel et ERP

En BTP, la demande d'achat (DA) est le document interne d'autorisation qui précède le bon de commande dans la chaîne procure-to-pay : demande d'achat → bon de commande → bon de livraison → bon de réception → facture fournisseur. Elle naît sur le chantier ou au bureau d'études, porte un code chantier, des lignes article, et une cascade de visas d'approbation, mais elle n'engage encore personne vis-à-vis du fournisseur. C'est le premier document de la chaîne qui mérite d'être structuré, et c'est celui qu'aucun guide pratique n'aborde.

Extraire une demande d'achat BTP vers Excel ou un ERP suppose, en pratique, trois choses : capturer le chantier (code et nom de site), capturer les visas d'approbation dans l'ordre où ils ont été apposés, et restituer ligne article par ligne article la référence, la désignation, la quantité, le prix unitaire HT et le montant HT. La sortie doit ensuite porter, ligne par ligne, un SKU canonique conforme à la convention interne — typiquement code chantier + code fournisseur + référence brute — pour que l'ingestion en aval n'ait plus à mapper. Tout l'enjeu de la digitalisation tient dans cette opération de préfixage faite une bonne fois au moment de l'extraction, plutôt qu'à coups de RECHERCHEV en aval.

Le marché auquel s'adresse cette mécanique a une taille connue. D'après les chiffres clés du bâtiment publiés par la FFB, le secteur du bâtiment en France comptait en 2024 environ 440 000 entreprises affichant un chiffre d'affaires positif, dont 94 % de taille artisanale, pour 208 milliards d'euros de travaux réalisés. Concrètement, cela veut dire que la dérive de format entre une DA émise par une entreprise générale, par une PME du second œuvre et par un artisan en sous-traitance n'est pas l'exception : c'est la norme statistique. Une DA reçue d'un sous-traitant artisan ne ressemblera pas à une DA imprimée depuis l'ERP d'un majeur, et toute extraction qui prétend tenir doit composer avec cette dispersion.

Anatomie d'une DA : chantier, fournisseur, lignes article, visas

Une DA porte plusieurs blocs distincts. Le bloc d'en-tête identifie l'opération, le bloc lignes liste ce qui est demandé, les totaux et la TVA récapitulent les montants quand ils figurent, le bloc visas trace qui a autorisé. L'extraction doit savoir nommer ces blocs séparément parce que l'ERP de destination, lui, les traite séparément.

Bloc d'en-tête. Il porte d'abord le code chantier, qui est rarement un identifiant simple. La forme la plus courante combine une racine projet et des extensions d'affaire : un code court mémorable du type "SYNERGIES", ou bien une composition lettre projet + numéro affaire + sous-affaire (par exemple "B-2024-0421-03"). À côté du code, le nom du site permet à l'humain de reconnaître l'opération sans aller chercher la table de référence. Le fournisseur demandé apparaît avec son nom commercial, et selon les entreprises avec un code fournisseur interne — un identifiant que les achats attribuent indépendamment du SIREN, souvent une abréviation à trois ou quatre lettres. Suivent la date de besoin (date à laquelle le matériel doit être sur site, à ne pas confondre avec la date de commande), le demandeur (chef de chantier ou conducteur de travaux qui rédige la DA, parfois un automaticien ou un méthodiste pour les lots techniques) et un service ou un centre de coût quand l'organisation comptable l'exige.

Bloc lignes article. Pour chaque ligne demandée, on attend la référence article — souvent une référence fournisseur abrégée, parfois préfixée par classe d'article (un préfixe lot électricité, lot CVC ou lot gros œuvre selon la nomenclature interne) — la désignation libre rédigée par le demandeur, le conditionnement (à l'unité, au lot, au mètre linéaire, à la palette, au mètre cube), la quantité, le prix unitaire HT, le montant HT calculé pour la ligne, et la marque ou le fabricant lorsqu'ils sont précisés. Le détail marque/fabricant n'est pas systématique, mais quand il est présent il pèse en aval pour le rapprochement BC/BL et pour les contrôles qualité de chantier.

Totaux et TVA. La DA est interne et la TVA n'y figure pas systématiquement. Quand elle figure, on attend un total HT, un taux et un montant de TVA, et un total TTC indicatif. Quand elle ne figure pas, l'extraction doit savoir laisser les colonnes vides plutôt qu'inférer un taux par défaut, parce que la responsabilité de la TVA bascule sur la facture fournisseur, pas sur la DA.

Bloc visas d'approbation. La cascade typique va du chef de chantier au conducteur de travaux puis au directeur des achats, avec un visa supplémentaire de directeur financier au-delà d'un seuil interne — souvent quelques milliers d'euros, mais le seuil est propre à chaque entreprise et il faut le connaître pour savoir si une DA arrive à l'extraction visa complet ou visa en attente. Le visa lui-même peut prendre quatre formes selon l'outil d'origine : signature manuscrite, tampon humide, nom dactylographié dans une case "visa par", mention "visa électronique" suivie d'un identifiant. L'extraction doit pouvoir distinguer un visa apposé d'une case visa attendue mais vide — la différence n'est pas anecdotique, elle conditionne le statut d'autorisation que recevra l'ERP.

Obligatoire vs conventionnel. Code chantier, au moins une ligne article complète et identité du demandeur sont obligatoires. Centre de coût, code fournisseur interne et visa au-delà du seuil sont conventionnels : l'extraction doit pouvoir les laisser vides sans signaler d'erreur quand l'organisation ne les renseigne pas.

Trois formats de DA en circulation : PDF d'ERP, formulaires Word ou Excel, photos de chefs de chantier

Une fois les champs DA posés, la difficulté se déplace : ces champs n'arrivent pas sous une forme unique. Trois familles de format coexistent dans une même entreprise, parfois à l'intérieur d'une même semaine, et chacune impose sa contrainte propre au prompt d'extraction. Elles correspondent assez fidèlement aux profils de rédacteur : l'acheteur ou le contrôleur travaille depuis l'ERP, le conducteur de travaux depuis le formulaire Excel, le chef de chantier ou le sous-traitant depuis le papier photographié.

Première famille : DA imprimées en PDF depuis un ERP. Quand la DA sort d'un module achats d'Apibâtiment, d'Optim'BTP, d'iXbat, de Codial, d'Onaya, de Sage 100c BTP ou de ProGBat, la mise en page est constante à l'intérieur d'une même entreprise. Les blocs d'en-tête sont au même endroit d'une DA à l'autre, les libellés ne bougent pas, les polices et les tailles de caractères sont stables. Cette stabilité rend l'extraction robuste : un prompt calibré sur trois exemples tient pour les centaines suivantes. La complication arrive quand l'entreprise reçoit aussi des DA d'agences régionales, de filiales, ou de sociétés sœurs dont le modèle ERP diffère — même éditeur dans certains cas, mais paramétrage maison qui décale les en-têtes. La logique d'extraction doit alors être paramétrée par société émettrice plutôt que par modèle de document figé : le même prompt, lu avec le contexte "voici une DA sortie de l'ERP de l'agence X", produit la bonne sortie sans nécessiter un prompt par agence.

Deuxième famille : formulaires Word ou Excel maintenus en interne. Beaucoup d'entreprises BTP, surtout celles qui n'ont pas migré sur un ERP intégré, gèrent leurs DA via un modèle Word ou un classeur Excel partagé. Le format est théoriquement constant, mais en pratique chaque demandeur le fait dériver. Un conducteur de travaux ajoute une colonne "marque préférée" pour ses lots techniques. Un acheteur fusionne deux lignes parce que le fournisseur les facture ensemble. Un chef de chantier recalcule à la main un total HT que la formule Excel n'a pas suivi après une insertion de ligne. Le bloc visas est étiré ou supprimé selon que la DA passe ou non un seuil interne. Une extraction qui s'appuierait sur la position des cellules tomberait à la première dérive. Une extraction qui s'appuie sur les libellés de champs — "Référence", "Désignation", "Quantité" — tient quel que soit l'endroit où ils se trouvent, parce que c'est l'étiquette sémantique qui guide la lecture, pas la coordonnée.

Troisième famille : DA manuscrites photographiées depuis le chantier. Les chefs de chantier et les sous-traitants soumettent fréquemment leurs DA sur papier, photographiées au smartphone, parfois rédigées sur un carnet de chantier ou sur un bon préimprimé qu'ils ont sous la main. L'éclairage est inégal, la perspective est inclinée, l'écriture est rapide, les ratures s'empilent. Il est normal de voir une quantité corrigée par-dessus une valeur précédente, une référence griffonnée puis barrée et réécrite à côté, un visa apposé en travers d'une case prévue ailleurs. L'extraction doit lire l'écriture manuscrite sur photo et savoir laquelle de deux valeurs superposées est la valeur active : par convention chantier, c'est la dernière apposée. Cette lecture des surcharges est précisément ce que les outils à modèle figé, qui attendent un champ propre à une coordonnée propre, ne savent pas faire.

Ce que ces trois familles imposent au prompt. Le prompt doit indiquer à l'outil que les champs apparaissent sous plusieurs étiquettes synonymes — "Réf.", "Référence article", "Code article", "Article" désignent la même donnée — que la position des blocs n'est pas garantie, que les visas peuvent être typographiés, manuscrits ou absents, et que sur les photos manuscrites les valeurs raturées ou surchargées doivent être interprétées comme remplacées par leur dernière version. Cette tolérance de format n'est pas une option de luxe : c'est la condition pour que le même prompt traite la DA imprimée du PDF ERP, le formulaire Excel du conducteur de travaux et la photo du chef de chantier sans qu'il faille trier les documents en amont.

L'import ERP figé rejette tout ce qui n'a pas son format. Le modèle Excel à compléter à la main consomme du temps de chef de chantier ou d'assistante achats. Le prompt, lui, lit ce qui est devant lui.

Concevoir le prompt d'extraction et le préfixe SKU chantier

Le prompt est la configuration. Plutôt que paramétrer un template, charger une grammaire de champs ou maintenir une grille de règles dans un outil tiers, on rédige en français une instruction qui décrit ce que le tableau de sortie doit contenir et comment composer ses colonnes. Le résultat tient en trois blocs : la liste des champs à extraire, les règles de format, le motif de composition du SKU.

Structure générale du prompt. Le bloc d'extraction énumère les champs : code chantier, nom du site, fournisseur demandé et code fournisseur interne, date de besoin, demandeur, et pour chaque ligne article la référence brute, la désignation, le conditionnement, la quantité, le prix unitaire HT, le montant HT, la marque ou le fabricant. Pour chaque champ, on précise les libellés synonymes acceptés ("Réf.", "Référence article", "Code article", "Article" pour la référence ; "PU HT", "Prix unitaire", "P.U." pour le prix unitaire) — c'est ce qui permet à l'outil de retrouver le champ quel que soit l'en-tête utilisé par le rédacteur. Le bloc format fixe la sortie : une ligne par ligne article, code chantier répété sur chaque ligne pour permettre le tri par chantier sans pivot, montants en deux décimales, dates au format ISO YYYY-MM-DD. Le bloc cas particuliers traite les ambiguïtés : un visa attendu mais manquant remonte comme "manquant" plutôt que silencieux, une ligne sans prix unitaire indique la quantité et la désignation et marque le PU comme absent, un conditionnement implicite (la photo manuscrite qui dit "10" sans préciser l'unité) hérite par défaut de l'unité.

Le préfixe SKU chantier comme cœur de la mécanique. Préfixer la référence article par le code chantier et le code fournisseur, au moment de l'extraction, est ce qui transforme la DA d'une pièce documentaire en donnée directement ingérable. Le motif est concret : un chantier nommé "SYNERGIES", un fournisseur abrégé "MET-", une référence article brute "12345" donnent un SKU canonique SYNERGIES-MET-12345. La règle est composable : {code chantier}-{préfixe fournisseur}-{référence brute}. Cette opération a sa place au moment de l'extraction plutôt qu'en aval, parce que l'allocation de coût par chantier est un besoin métier fondamental en BTP — toute la comptabilité analytique est calée sur le code chantier — et que préfixer dès la sortie supprime une étape RECHERCHEV ou un mapping ERP qui se ferait sinon dans Excel ou dans l'ETL. La référence brute reste conservée dans une colonne séparée pour la traçabilité ; ce qu'on ajoute, c'est la colonne SKU canonique.

Forme du prompt pour le préfixe. L'instruction donnée à l'outil prend une forme directe : "compose une colonne SKU comme {code chantier}-{préfixe fournisseur}-{référence article brute}". Deux règles de fallback sont indispensables. Si le code fournisseur n'apparaît pas sur le document, l'outil utilise l'abréviation interne associée au fournisseur — l'entreprise tient en général une table "Sika → SIK", "Rexel → REX", "Würth → WUR" qui se passe en complément de prompt ou s'apprend par exemples. Si le code chantier n'est pas reconnu (typo manuscrite, code partiel sur photo), la ligne est marquée pour relecture plutôt que perdue : on préfère un SKU vide et une ligne flaggée à un SKU mal composé qui passerait silencieux dans l'ERP.

Généraliser le motif au-delà de SYNERGIES + MET-. La convention de préfixage varie d'une entreprise à l'autre. Certaines entreprises préfixent par centre de coût plutôt que par code chantier, parce que leur comptabilité analytique consolide plusieurs chantiers sous un même CC. D'autres préfixent par classe d'article — lot électricité, lot CVC, lot gros œuvre — parce que leur ERP gère les achats par lot avant de les ventiler par chantier. Les groupes multi-entités préfixent souvent par code société pour distinguer les achats d'une filiale française de ceux d'une filiale belge ou luxembourgeoise. Le principe est identique dans les trois cas : composer le SKU canonique au moment de l'extraction, selon la convention interne. Le lecteur adapte le motif sans réécrire le prompt depuis zéro — il change simplement la formule de composition.

Mise en place pratique. L'application qui exécute ce prompt est, dans notre cas, un outil d'extraction de documents par IA qui présente un champ unique pour la rédaction du prompt et une zone de dépôt de fichiers pour les DA, sans templates à configurer, sans grammaire de champs à paramétrer, sans assistant multi-étapes. Le lecteur dépose ses fichiers DA — PDF d'ERP, photos de chantier en JPG ou PNG, classeurs Excel — et récupère un Excel, CSV ou JSON en quelques minutes. Les volumes vont jusqu'à 6 000 fichiers par lot ou 5 000 pages dans un seul PDF, ce qui couvre largement les flux d'une entreprise BTP. Le prompt, une fois calibré, s'enregistre dans une bibliothèque réutilisable, ce qui est exactement le bon pattern pour un flux DA récurrent : on le rappelle pour chaque nouveau lot, on l'ajuste à la marge quand un nouveau format apparaît, on le partage avec les autres acheteurs ou conducteurs de travaux qui rejoignent l'organisation.

Calibrer le prompt sur des cas réels. En pratique, on prend trois ou quatre DA représentatives — idéalement une par format : un PDF imprimé d'ERP, un formulaire Excel interne, une photo manuscrite d'un chef de chantier — on exécute le prompt, et on regarde la sortie. Les écarts constatés indiquent les ajustements à faire : un libellé synonyme à ajouter parce qu'un demandeur écrit "Article" là où d'autres écrivent "Référence", une règle de fallback à préciser parce qu'une photo manuscrite avait son code chantier abrégé d'une lettre, une règle de format à durcir parce qu'un PDF ERP rendait les montants avec une virgule là où le tableau de sortie attend un point. Le prompt n'est pas figé une fois pour toutes ; il s'enrichit au rythme où de nouveaux formats arrivent.

Structurer le tableau de sortie et l'ingérer dans l'ERP BTP

Le prompt produit un fichier ; ce fichier doit être conçu pour la suite. La forme tabulaire qui sert le mieux la saisie des demandes d'achat fournisseurs dans un ERP BTP est plate : une ligne par ligne article, en-tête de colonnes alignée sur ce que le module achats de l'ERP de destination attend.

Structure de sortie standard. Le code chantier est répété sur chaque ligne, parce que l'ingestion ERP comme l'analyse Excel ont besoin de pouvoir trier et agréger par chantier sans construire de pivot. Le SKU canonique préfixé occupe une colonne dédiée, distincte de la référence brute qui est conservée dans une colonne séparée pour la traçabilité — au moindre litige avec le fournisseur, c'est la référence brute qui sert de pièce, et le SKU canonique qui sert d'identifiant interne. Les montants apparaissent en deux décimales, les dates au format ISO. Les visas occupent une colonne d'état (apposé, manquant, illisible) plutôt qu'une colonne par approbateur, ce qui aplatit la sortie et reste suffisant pour la plupart des contrôles d'autorisation en aval. Quand l'ERP cible exige le détail visa par visa — chef de chantier, conducteur, directeur des achats — on ouvre les colonnes correspondantes, mais c'est un cas particulier plutôt que la règle.

Colonnes minimales utiles. Pour un ERP BTP de destination, la liste minimale est : code chantier, SKU canonique, référence brute, désignation, fournisseur, code fournisseur interne (quand l'entreprise en attribue un), conditionnement, quantité, prix unitaire HT, montant HT, date de besoin, état des visas. À cela s'ajoutent deux colonnes qui ne servent pas l'ingestion mais la vérification : le nom du fichier source et le numéro de page. Le lecteur en aura besoin au moindre écart constaté entre la sortie et la DA d'origine — sans ces deux colonnes, retrouver la pièce justificative dans un lot de plusieurs centaines de DA devient un travail manuel.

Format pivot vers Excel ou ERP. Le même fichier sert deux usages. Il se charge directement dans Excel pour analyse — suivi du volume de DA par chantier, agrégation des achats par fournisseur, contrôle des seuils de visa, anticipation des engagements avant émission des bons de commande. Il se transforme aussi pour ingestion dans l'un des principaux ERP BTP du marché : Apibâtiment, Optim'BTP, iXbat, Codial, Onaya, Sage 100c BTP, ProGBat. La stratégie d'ingestion reste la même quel que soit l'ERP : aligner le nom des colonnes et la convention SKU sur ce que le module achats attend, puis alimenter via import CSV pour les ERP qui acceptent un import direct, ou via une intégration ad hoc pour ceux qui exposent une API d'achats. Le mapping de colonnes se règle une fois pour l'ERP cible — Optim'BTP, iXbat, Codial ou Sage 100c BTP selon l'entreprise — puis se rejoue à l'identique pour chaque nouveau lot. Cet article ne compare pas ces ERP et ne recommande aucun en particulier : ils sont la cible d'ingestion, pas le sujet.

Lecteur sans ERP intégré. Pour les PME BTP et artisans qui gèrent leurs achats sur Excel sans ERP intégré, le fichier d'extraction est l'outil final, pas une étape intermédiaire — suivi du volume de DA par chantier, agrégation des achats par fournisseur, comparaison DA/facture une fois la facture arrivée. Le prompt reste identique aux deux usages.

Cette logique d'extraction tabulaire vers Excel n'est pas spécifique à la DA. Elle s'applique aux factures fournisseurs du même chantier en aval, et à tout document financier que la comptabilité reçoit ; le même blog la documente vertical par vertical, par exemple sur une extraction de factures vers Excel pour un expert-comptable en immobilier locatif meublé, ou sur la digitalisation des factures fournisseurs en restauration vers un Excel ventilé par taux de TVA pour les achats Metro, Brake, Transgourmet et Pomona. Le principe — un prompt, des fichiers, un tableau structuré — reste celui-ci.

Ce qui suit la DA dans la chaîne procure-to-pay BTP

Une fois la DA structurée, la chaîne continue : bon de commande, bon de livraison, bon de réception, facture fournisseur. La dématérialisation obligatoire des factures interentreprises en France change le format dans lequel les factures arriveront en aval — Factur-X et UBL via plateforme de dématérialisation partenaire — mais elle ne touche pas la DA. Le détail figure sur le workflow de réception des factures électroniques en 2026.

Le BTP ajoute un régime spécifique côté facture : l'autoliquidation de TVA en sous-traitance, qui concerne la facture du sous-traitant et non la DA. Les obligations de mention sont décrites dans l'article dédié à l'autoliquidation de TVA en sous-traitance BTP.