Le guide complet de l'extraction
de données AIA G702 & G703

Que sont les formulaires AIA G702 et G703 ?

Le formulaire AIA G702 — officiellement intitulé Demande et certificat de paiement — est le document standard de facturation d'avancement pour pratiquement tous les projets de construction commerciale aux États-Unis. Son complément, la feuille de continuation G703, fournit la ventilation détaillée par poste qui justifie les montants récapitulatifs. Ensemble, ils constituent ce que le secteur appelle un dossier de demande de paiement. Développés et protégés par l'American Institute of Architects (AIA), ces formulaires créent une structure uniforme pour demander des paiements d'avancement : le même format est utilisé, que le projet soit un aménagement de 200 000 $ ou un hôpital de 200 millions de dollars.

Le G702 est un récapitulatif d'une page qui présente la situation financière au niveau du projet. Il enregistre le montant initial du contrat, les ajustements issus des ordres de modification approuvés, la valeur totale des travaux exécutés et des matériaux stockés à ce jour, la retenue de garantie, les paiements antérieurs reçus et le montant net actuellement dû. L'architecte ou le maître d'ouvrage certifie le formulaire, et le paiement suit — en théorie sous 30 jours, en pratique souvent plus longtemps lorsque des erreurs déclenchent des cycles de nouvelle soumission.

La feuille de continuation G703 est là où se trouve le détail. Chaque ligne représente un poste du tableau de valeurs (SOV) du projet, et chaque colonne suit une dimension différente de l'avancement financier de ce poste : valeur prévue, travaux exécutés au cours des périodes précédentes, travaux exécutés au cours de la période en cours, matériaux stockés, totaux cumulés, pourcentage d'avancement, solde à terminer et retenue de garantie. Un G703 avec 30 postes contient environ 270 points de données individuels, et chacun de ces chiffres alimente le récapitulatif du G702. Les deux formulaires ne sont pas des documents indépendants — ils forment une structure de données parent-enfant où les totaux du G702 doivent correspondre aux totaux généraux du G703. S'ils ne correspondent pas, la demande est retournée impayée.

L'extraction des données G702/G703 suscite un intérêt croissant depuis quelques années pour trois raisons interdépendantes. Premièrement, le volume de demandes de paiement qu'un entrepreneur général traite augmente avec chaque projet, et le nombre de sous-traitants sur un projet commercial typique a augmenté à mesure que la spécialisation s'est approfondie. Deuxièmement, les plateformes de comptabilité de construction et de gestion de projets comme Procore, Viewpoint, Sage 300 CRE et CMiC attendent des données structurées — elles ne peuvent pas ingérer un formulaire PDF rempli et alimenter automatiquement leurs registres de coûts de chantier. Troisièmement, les outils d'IA capables de lire ces formulaires en comprenant leur sémantique, plutôt qu'en faisant correspondre des positions de modèles, n'ont atteint des niveaux de fiabilité acceptables qu'au cours des 18 à 24 derniers mois. Les formulaires n'ont pas changé. La capacité à en extraire les données, si.

Pourquoi le traitement des G702/G703 coûte plus cher que vous ne le pensez

Le coût visible du traitement des demandes de paiement est le temps nécessaire pour ouvrir un PDF, lire les chiffres et les saisir dans un tableur. Pour une demande unique avec un G703 de 30 lignes, un comptable de projet compétent effectue cette tâche en 30 à 45 minutes environ. Les coûts cachés sont ce qui se passe autour de cette tâche : la date limite mensuelle de demande de fonds concentre toutes les demandes sur une fenêtre de trois jours, les erreurs de retenue de garantie imposent des cycles de resoumission qui réinitialisent le délai de paiement de 30 jours, les incohérences entre formulaires nécessitent des appels de rapprochement avec les sous-traitants, et le formulaire AIA lui-même coûte de l'argent à chaque nouveau projet. Individuellement, ces coûts sont faibles. Ensemble, ils équivalent au salaire d'un employé à temps plein pour de nombreuses entreprises générales de taille moyenne.

Le cycle mensuel de demande de fonds. Les demandes de paiement dans la construction commerciale suivent un rythme mensuel fixe. Les sous-traitants soumettent leurs demandes avant une date limite — généralement le 20 ou le 25 du mois. L'entreprise générale examine, vérifie et consolide ces demandes en une demande de fonds au propriétaire avant la fin du mois. Le paiement du propriétaire, s'il est approuvé, arrive 30 à 45 jours plus tard. Manquer la date limite signifie que le paiement du sous-traitant est retardé d'un cycle de facturation entier — une attente de 60 jours au lieu de 30. Lorsqu'un comptable de projet traite manuellement 40 demandes de paiement en quatre jours, le risque de manquer la date limite pour une ou deux d'entre elles n'est pas théorique. Le Financial Benchmarker 2025 de la Construction Financial Management Association, basé sur les données fiscales de 2024 de 1 558 entreprises, indique que l'entreprise de construction typique fonctionne avec une marge bénéficiaire nette avant impôt de 6,7 %. Chaque demande retardée, chaque cycle de correction, chaque resoumission érode directement cette marge.

Erreurs de calcul de la retenue de garantie. La retenue de garantie — le pourcentage de chaque paiement retenu jusqu'à l'achèvement du projet — est la source la plus courante de litiges sur les demandes de paiement. La plupart des contrats spécifient un taux fixe, généralement 5 ou 10 %, appliqué à la valeur totale des travaux achevés et des matériaux stockés. Mais le calcul est rarement aussi simple que « prendre 10 % de la ligne 4 du G702 ». De nombreux contrats utilisent une retenue de garantie variable : le taux passe de 10 % à 5 % une fois que les travaux atteignent 50 % d'achèvement, ou la retenue sur les matériaux stockés est calculée à un taux différent de celui sur les travaux installés. Certains États imposent des limites légales de retenue de garantie — la Californie plafonne la retenue à 5 % après 50 % d'achèvement sur les projets privés — qui prévalent sur le taux contractuel. Un sous-traitant qui calcule la retenue à 10 % alors que le contrat spécifie 5 % a soumis une demande de paiement surestimée, et l'ensemble du dossier est renvoyé pour correction. L'erreur est généralement faible — quelques milliers de dollars — mais le retard de resoumission coûte à tous les intervenants du projet deux à quatre semaines.

Validation croisée G702-G703. Le récapitulatif G702 tire ses montants des totaux de postes du G703. Le « Total des travaux achevés et stockés à ce jour » à la ligne 4 du G702 doit correspondre au total général de la colonne G du G703. La retenue de garantie à la ligne 5 du G702 doit correspondre au total général de la colonne I du G703 (ou au calcul à taux fixe appliqué aux totaux du G703). Lorsqu'un comptable de projet saisit manuellement ces chiffres, l'erreur la plus fréquente est de reporter un total cumulé du G703 sur une mauvaise ligne du G702 — le total des travaux achevés saisi dans le champ de la retenue, ou les certificats antérieurs saisis comme montant dû en cours. Les formulaires intègrent leur propre arithmétique : ligne 6 moins ligne 7 égale ligne 8, et ligne 3 moins ligne 6 égale ligne 9. Une erreur de transcription dans un seul champ se répercute sur toutes les lignes dérivées, produisant un G702 dont l'arithmétique est incohérente. Un architecte examinant la demande repère l'incohérence en quelques secondes et rejette l'ensemble du dossier.

Coût des formulaires AIA. Contrairement aux bons de commande ou aux bons de livraison standard, les formulaires AIA sont des documents protégés par le droit d'auteur. Un ensemble G702/G703 acheté à l'unité via AIA Contract Documents coûte environ 49,99 $ — soit environ 15 à 25 $ par lot lorsqu'il est acheté en gros via l'abonnement logiciel AIA, qui commence à environ 500 $ par an pour un accès illimité. Pour une entreprise générale gérant 50 sous-traitants actifs sur cinq projets, le coût annuel des formulaires se situe entre 750 et 2 500 $ — un montant non négligeable, mais une dépense opérationnelle récurrente qui n'ajoute aucune valeur au-delà de la standardisation du format des données de facturation que l'entreprise générale doit déjà traiter.

Structure parent-enfant G702/G703 : page récapitulative et feuille de continuation

Pour comprendre pourquoi l'extraction de données de ces formulaires exige plus qu'une simple lecture indépendante de chaque page, il faut d'abord comprendre leur relation structurelle. Les G702 et G703 ne sont pas deux formulaires déposés ensemble. Ce sont deux vues des mêmes données financières, liées par un ensemble de contraintes arithmétiques qu'un outil d'extraction fiable doit à la fois lire et vérifier.

Le G702 est le parent : neuf lignes de synthèse financière couvrant l'ensemble du contrat. Ses lignes sont :

Trois de ces neuf lignes sont reportées du G703 (Ligne 4, et par extension les Lignes 5 à 9). Quatre sont des dérivations arithmétiques (Lignes 3, 6, 8, 9). Deux sont des données fixes du contrat (Lignes 1 et 2). Un outil d'extraction qui ne lit que la page de couverture du G702 capture les chiffres récapitulatifs mais ne peut pas les vérifier par rapport à leur source. Il manque également le seul endroit où les données peuvent être désagrégées : le G703.

Le G703 est l'enfant : un tableau à longueur variable où chaque ligne correspond à un poste du détail estimatif, et chaque colonne suit la progression financière de ce poste d'une période de facturation à l'autre. Une feuille de continuation G703 standard organise les données dans ces colonnes :

Chaque ligne du G703 est un mini état financier pour ce lot de travaux spécifique. Le total général de la colonne G doit correspondre à la Ligne 4 du G702. Le total de la colonne I doit correspondre à la Ligne 5. Ces contraintes inter-formulaires sont ce qui différencie l'extraction d'une demande de paiement de l'extraction d'une facture : vous ne lisez pas simplement des champs sur un seul document. Vous lisez une structure de données en deux parties et validez la cohérence arithmétique entre ces deux parties. Pour un guide pas à pas de cette extraction en pratique, consultez le guide détaillé sur l'extraction des données de demande de paiement AIA G702 vers un tableur.

Les défis cachés de l'extraction de données des demandes de paiement

Même lorsque les formulaires sont correctement remplis, l'extraction de données des ensembles G702/G703 présente des défis inexistants avec d'autres types de documents de construction. Ces défis ne sont pas immédiatement évidents pour quiconque n'a pas traité des demandes de paiement à grande échelle.

Ordres de modification et quantités manuscrits. Malgré la disponibilité généralisée des formulaires AIA numériques, une part importante des demandes de paiement des sous-traitants arrive avec des écritures manuscrites. Les G703 annotés sur le terrain sont courants : le chef de projet d'un sous-traitant imprime le tableau des valeurs, inscrit à la main les quantités de la période en cours, calcule le pourcentage d'avancement dans la marge, puis numérise la feuille annotée en PDF. Un sous-traitant travaillant sur plusieurs projets peut préparer un seul journal d'ordres de modification annoté à la main et le joindre à la demande de paiement plutôt que d'utiliser le tableau récapitulatif des ordres de modification AIA. Les outils traditionnels d'OCR et d'extraction basée sur des modèles — qui localisent les champs de données par leurs positions en pixels sur la page — échouent sur ces documents car les valeurs manuscrites décalent la mise en page. Un « 1 247 » manuscrit dans la colonne Quantité pousse le montant en dollars adjacent d'une cellule vers la droite, et l'extraction par modèle renvoie la mauvaise valeur sans aucun signal d'erreur. L'extraction par IA basée sur la vision, en revanche, lit chaque valeur dans son contexte sémantique : elle identifie les nombres dans la colonne « Travaux exécutés cette période » en comprenant qu'ils se trouvent dans une colonne dont l'en-tête dit « Travaux exécutés cette période », et non en mesurant des décalages en pixels depuis le haut de la page.

Codes CSI MasterFormat. La plupart des feuilles de continuation G703 organisent les postes en utilisant les numéros de division CSI MasterFormat — le système de classification standardisé géré par le Construction Specifications Institute. Un G703 typique peut lister des postes comme « 03 30 00 — Béton coulé en place », « 08 11 00 — Portes et cadres métalliques », « 23 31 00 — Réseaux de gaines CVC » et « 26 10 00 — Électricité moyenne tension ». Ces codes sont significatifs pour le calcul des coûts de chantier — un comptable de projet doit savoir que 47 000 $ de travaux de béton appartiennent au code de coût 03 30 00, et non à « Béton » comme catégorie générique. Un outil d'extraction qui capture les descriptions des postes comme du texte non structuré perd le code de coût structuré. Un outil conscient de la hiérarchie MasterFormat peut produire le numéro de division dans une colonne séparée, préservant la correspondance entre la facturation par poste et l'allocation des coûts de chantier. L'édition actuelle MasterFormat 2026, publiée par CSI en coordination avec Construction Specifications Canada, organise les spécifications de construction en 50 divisions — de la Division 00 (Exigences d'approvisionnement et de contrat) à la Division 49 — avec environ 2 185 nouvelles entrées ajoutées dans la mise à jour 2026.

Suivi du montant du contrat via les ordres de modification. Un projet de construction se termine rarement à son montant contractuel initial. Les ordres de modification ajoutent des travaux, en déduisent ou ajustent les prix au fur et à mesure de l'avancement du projet. Le G702 suit cela via les lignes 1, 2 et 3 : le montant initial, la variation nette et le total ajusté. Mais le récapitulatif des ordres de modification sur le G702 n'est qu'un seul chiffre — il ne liste pas les ordres de modification individuels ni leur statut (approuvé, en attente, contesté). Les sous-traitants joignent souvent des journaux d'ordres de modification séparés ou des feuilles de transmission d'ordres de modification à leurs dossiers de demande de paiement. Un flux d'extraction qui ne capture que les champs du G702 manque les détails justificatifs dont le comptable de projet a besoin pour vérifier que le montant de la variation nette est correct. La leçon plus large pour l'extraction de données contractuelles s'applique ici : l'extraction structurée fonctionne mieux lorsqu'elle lit non seulement le document récapitulatif, mais aussi les documents justificatifs qui l'alimentent.

Complexité de la validation inter-formulaires. Les contraintes arithmétiques entre les G702 et G703 vont au-delà d'une simple concordance des totaux de colonnes. La colonne D du G703 (Travaux exécutés lors de la demande précédente) pour la demande de paiement en cours doit être égale à la colonne G du G703 (Total exécuté et stocké à ce jour) de la demande précédente, moins la colonne F de la période précédente (Matériaux stockés). Si un sous-traitant modifie son échéancier des valeurs en cours de projet — en scindant un poste en deux ou en réaffectant la valeur entre des lots — ce report est rompu et l'entrepreneur général doit concilier manuellement l'écart. Un outil d'extraction qui traite chaque demande de paiement comme un document indépendant ne signalera pas cette discordance. Un outil qui lit les demandes de paiement séquentielles et compare leurs valeurs de report le fera.

Approche traditionnelle vs IA : deux méthodes d'extraction des demandes de paiement

La différence entre l'extraction traditionnelle et l'extraction par IA des demandes de paiement n'est pas une question de rapidité — les deux peuvent traiter une page en quelques secondes. La différence réside dans leur gestion des variations, des erreurs et des relations inter-formulaires.

Saisie manuelle avec recherche dans un tableur. L'approche traditionnelle : ouvrir le PDF du G702 du sous-traitant, lire la ligne 4 (Total exécuté et stocké), la saisir dans le tableur de suivi du projet sous le nom du sous-traitant. Ouvrir le G703, commencer par le premier poste, saisir le numéro, la description, la valeur prévue, le montant déjà exécuté, la période en cours, le stocké, le total, le pourcentage, le solde, la retenue — 10 champs par ligne pour 30 lignes. Répéter ce processus pour chacun des 40 sous-traitants soumettant des demandes de paiement ce cycle. La méthode est simple et ne nécessite aucun investissement logiciel. Elle garantit également au moins quelques erreurs de transcription par cycle de facturation — une étude sur la précision de la saisie de données dans le secteur de la construction, publiée dans le Journal of Construction Engineering and Management, a révélé que la transcription manuelle de données numériques de construction produit des taux d'erreur de 0,5 à 2,5 % par champ. Pour 300 valeurs par demande et 40 demandes, cela représente 60 à 300 erreurs par cycle de facturation. La plupart sont mineures. Certaines ne le sont pas.

OCR basé sur des modèles. Les outils d'extraction basés sur des modèles comme Docparser et les plateformes OCR traditionnelles résolvent le problème de transcription mais en introduisent un de maintenance. Vous créez un modèle pour la page récapitulative du G702 : définissez une zone à la position (x=200, y=150) qui capture le montant initial du contrat, une autre zone à (x=200, y=180) pour le montant net des avenants, et ainsi de suite pour les neuf lignes. Vous créez un second modèle pour le tableau du G703 : définissez des zones de colonnes qui capturent les cellules du tableau par leurs coordonnées en pixels par rapport aux bordures du tableau. Les modèles fonctionnent parfaitement pour le premier formulaire soumis numériquement par le sous-traitant. Ils échouent lorsque le second sous-traitant soumet un G703 scanné dont le tableau s'est décalé de 3 millimètres vers la gauche lors de l'impression. Ils échouent lorsque le troisième sous-traitant utilise un éditeur PDF différent qui positionne les champs du formulaire légèrement différemment. Ils échouent complètement lorsqu'un G703 manuscrit arrive et que la structure du tableau est irrégulière. Chaque échec nécessite un nouveau modèle ou un ajustement du modèle existant — et l'ajustement rompt la couverture des formulaires qui fonctionnaient auparavant.

Extraction personnalisée de colonnes par IA sémantique. L'extraction visuelle moderne lit les formulaires G702/G703 en comprenant la signification de chaque champ, et non son emplacement sur la page. C'est l'extraction personnalisée de colonnes : vous définissez les colonnes souhaitées dans votre tableur de sortie — « Montant initial du contrat », « Total réalisé et stocké », « Pourcentage de retenue », « Numéro d'article », « Description », « Valeur prévue », « Travaux réalisés cette période », « Total réalisé à ce jour », « Solde à terminer » — et l'IA lit l'intégralité du document, identifie les valeurs correspondant à chaque colonne selon leur rôle sémantique dans le formulaire, et les restitue sous forme de ligne structurée. Le G702 numérique du premier sous-traitant et le scan manuscrit du second produisent les mêmes colonnes de sortie — car l'IA sait ce qu'est une « retenue », et non où elle apparaît habituellement.

Pour une comparaison pratique de différents outils d'extraction sur les formulaires AIA G702 et autres documents de construction, l'article meilleur logiciel d'extraction de documents pour la construction en 2026 a testé huit plateformes sur un ensemble commun de 35 documents de construction et fournit des benchmarks de précision par champ spécifiques aux demandes de paiement.

Colonnes calculées : boucler le calcul arithmétique

L'une des fonctionnalités les plus utiles pour l'extraction G702/G703 est la possibilité de définir des colonnes qui calculent des valeurs dérivées pendant l'extraction, sans nécessiter de formules post-extraction dans le tableur. C'est le domaine des colonnes calculées — des colonnes où l'IA effectue un calcul spécifié sur d'autres valeurs extraites et restitue le résultat dans la ligne de données.

Trois colonnes calculées sont particulièrement utiles pour l'extraction des demandes de paiement :

• Vérification de la retenue — définissez une colonne calculée qui multiplie le « Total réalisé et stocké à ce jour » extrait par le pourcentage de retenue contractuel. Si le montant de retenue indiqué sur le G702 diffère de cette valeur calculée de plus d'une faible tolérance (disons 1,00 $), l'extraction signale un écart que le réviseur peut examiner avant d'approuver la demande.
• Validation croisée des formulaires — définissez une colonne calculée qui additionne la colonne G du G703 (Total réalisé et stocké à ce jour) sur tous les postes et compare le résultat à la ligne 4 du G702. C'est le contrôle arithmétique le plus important de la demande de paiement, et son automatisation élimine la source la plus fréquente de resoumission.
• Calcul du solde à terminer — calculez la valeur contractuelle restante en soustrayant les montants cumulés gagnés plus la retenue du montant du contrat à ce jour. Cela donne à l'équipe de projet une vue en temps réel du budget restant pour chaque lot de travaux, sans attendre la prochaine demande de paiement du sous-traitant.

Ces colonnes calculées ne nécessitent pas que l'utilisateur saisisse des formules après extraction. Elles sont spécifiées dans la configuration d'extraction — soit dans le nom de la colonne (ex. « Vérification retenue (Total réalisé x 10 %) »), soit comme règle JSON dans le format de règles de l'outil pour une logique multi-étapes — et l'IA effectue le calcul pendant l'extraction. Le résultat est un tableur de sortie où les colonnes qui vérifient l'exactitude de la demande de paiement sont renseignées avant même que le réviseur n'ouvre le fichier.

Traitement par lots : de 30 demandes de paiement à un seul tableau consolidé

Extraire un seul dossier G702/G703 est une preuve de concept. Extraire 30 à 50 dossiers en une seule passe, c'est là que la valeur opérationnelle apparaît. Le flux de travail par lots pour les demandes de paiement suit une logique différente de celui des factures ou des reçus — car le résultat n'est pas une simple liste de lignes, mais une consolidation structurée qui préserve la hiérarchie projet-sous-traitant-périmètre.

Le tableau de bord consolidé des demandes de paiement d'un entrepreneur général — le tableur maître qui suit l'état des paiements de tous les sous-traitants sur tous les projets actifs — organise généralement les données sur trois niveaux : projet, sous-traitant et ligne. Une extraction par lots de 40 dossiers G702/G703 provenant de sept projets différents doit produire un seul tableur où la première colonne identifie le projet, la deuxième le sous-traitant, et les colonnes restantes capturent les données de la demande de paiement pour chaque ligne. Si les 40 demandes incluent un mélange de formulaires numériques et de scans manuscrits, l'extraction par lots doit gérer les deux via le même flux, sans nécessiter de configuration distincte par fichier.

L'approche par lots rend également la validation croisée des formulaires plus puissante. Au lieu de vérifier isolément que le total G703 du sous-traitant A correspond à son total G702, le tableur consolidé permet de comparer les montants de paiement entre sous-traitants réalisant des périmètres similaires sur le même projet — signalant une situation où le sous-traitant en cloisons sèches facture 80 % d'avancement tandis que le sous-traitant en peinture, qui ne peut commencer avant la fin des cloisons, facture 90 % d'avancement. Ces anomalies de motif sont invisibles lorsque chaque demande est traitée indépendamment. Pour un flux de travail détaillé sur le traitement par lots, consultez le guide dédié sur le traitement par lots des demandes de paiement AIA G702 sur l'ensemble d'un portefeuille de projets.

Export et intégration : acheminer les données là où elles doivent aller

Extraire les données d'une demande de paiement n'est utile que si elles parviennent au système où s'effectue le traitement des paiements. Pour la plupart des entrepreneurs généraux, ce système est l'un des trois suivants : une plateforme de gestion de projet (Procore, Viewpoint, CMiC), un logiciel de comptabilité de construction (Sage 300 CRE, Foundation), ou un ensemble de feuilles de calcul qui alimentent l'un ou l'autre.

Export Excel. Le chemin de sortie le plus courant et le plus flexible. Une extraction bien structurée d'un G702/G703 produit un fichier Excel avec des onglets séparés ou des colonnes clairement étiquetées pour les champs récapitulatifs du G702 et les lignes du G703. L'onglet G702 contient une ligne par sous-traitant et par projet, avec des colonnes pour le montant initial du contrat, les avenants nets, le montant du contrat à ce jour, le total réalisé et stocké, la retenue de garantie, les paiements antérieurs, le montant dû actuel et le solde à terminer. L'onglet G703 contient une ligne par poste, avec des colonnes pour les identifiants du projet et du sous-traitant, ainsi que les dix colonnes de postes. Un comptable de projet peut ensuite utiliser des tableaux croisés dynamiques, des formules SOMME.SI ou Power Query pour consolider les données dans le format requis par ses flux de travail spécifiques de reporting et de traitement des paiements.

Intégration Google Sheets. Pour les équipes qui gèrent leurs échéanciers de demande dans Google Sheets, le résultat de l'extraction peut atterrir directement dans la feuille de calcul active via un module complémentaire Google Sheets. Cela élimine complètement l'étape d'export-import : les PDF de demande de paiement téléchargés sont traités, et les données structurées résultantes sont ajoutées à la feuille désignée en temps réel, les en-têtes de colonne correspondant au modèle de suivi existant de l'utilisateur. Pour une compréhension plus approfondie de la différence fondamentale entre l'extraction sémantique et les approches basées sur des modèles, le guide complet de l'extraction des COI couvre le même changement de paradigme appliqué aux données des certificats d'assurance.

Intégration Procore et Viewpoint. Les capacités d'IA de Procore, alimentées par son acquisition de Datagrid, se concentrent sur les soumissions, les RFI et la révision des contrats — pas sur l'ingestion de données de documents externes dans son module de traitement des paiements. Viewpoint (Trimble) offre des fonctionnalités de facturation AIA au sein de ses plateformes ERP Vista et Spectrum, mais exige que la demande de paiement soit générée dans le système plutôt que reçue d'un sous-traitant sous forme de PDF rempli. En pratique, la voie d'intégration la plus fiable pour les ensembles G702/G703 reçus de l'extérieur reste l'exportation Excel ou CSV suivie d'une importation dans la plateforme de gestion de projet ou de comptabilité — et la qualité de cette intégration dépend entièrement de la propreté avec laquelle l'outil d'extraction structure sa sortie.

Comment évaluer un outil d'extraction de demandes de paiement

Tous les outils d'extraction de documents ne sont pas adaptés aux exigences spécifiques des données G702/G703. Les critères suivants permettent de distinguer les outils capables de traiter les demandes de paiement de ceux qui produiront des résultats inutilisables sur tout autre document qu'un PDF numérique parfaitement formaté.

Capacité de validation inter-formulaires. Le critère le plus important : l'outil comprend-il que les formulaires G702 et G703 sont liés ? Un outil qui traite chaque page indépendamment extraira les chiffres récapitulatifs du G702 et les lignes du G703 comme des données distinctes et non reliées. Un outil adapté aux demandes de paiement produira les données du G702 liées à celles du G703, ou mieux encore, signalera les écarts entre les deux formulaires lors de l'extraction. Sans cette capacité, l'extraction génère deux ensembles de données que l'utilisateur doit rapprocher manuellement — ce qui est précisément le travail que l'extraction était censée éliminer.

Vérification du calcul de la retenue de garantie. L'outil doit soit extraire le pourcentage et le montant de la retenue comme des champs structurés, soit permettre à l'utilisateur de définir une colonne calculée qui estime la retenue attendue à partir des totaux extraits. Un outil qui renvoie « 5 % » comme une chaîne de texte dans une colonne Notes n'a pas vraiment extrait les données — il a transféré la responsabilité de l'interprétation à l'utilisateur.

Tolérance à l'écriture manuscrite. Si l'outil ne peut pas lire les entrées manuscrites sur une feuille de continuation G703, il échouera sur environ 30 à 50 % des soumissions réelles de sous-traitants, selon le type de projet et les sous-traitants impliqués. Le seul moyen fiable de tester cela est de soumettre un échantillon comprenant au moins trois demandes de paiement manuscrites ou annotées à la main — et non des formulaires de démonstration fournis par le vendeur — et de comparer la précision au niveau des champs entre les documents numériques et manuscrits de l'échantillon.

Extraction de tableaux pour les G703 de longueur variable. Les tableaux G703 varient en nombre de lignes de 10 à 100 postes ou plus. Un outil qui gère les mises en page de tableaux fixes mais échoue sur les tableaux où un poste s'étend sur deux lignes, ou lorsque le sous-traitant a inséré une ligne dessinée à la main entre deux lignes imprimées, produira des résultats incomplets. Testez avec un G703 contenant au moins 40 lignes et incluant au moins un poste avec une description sur plusieurs lignes.

Préservation des codes CSI MasterFormat. Si le projet utilise les codes de division CSI pour le calcul des coûts, l'outil d'extraction doit produire le code et la description dans des colonnes séparées ou, à tout le moins, préserver la description complète du poste sans tronquer ni concaténer les champs adjacents. Un outil qui tronque « 03 30 00 — Béton coulé en place » en « 03 30 00 » a déjà perdu des informations nécessaires au système de codification des coûts.

Aucune configuration de modèle. L'outil doit extraire un ensemble G702/G703 sans exiger que l'utilisateur dessine des zones, entraîne un modèle ou crée un gabarit. Si le vendeur demande des documents d'exemple lors de la configuration, l'outil utilise une architecture basée sur des modèles ou un apprentissage qui nécessitera une maintenance lorsque les formulaires changeront ou qu'un nouveau sous-traitant soumettra des demandes de paiement dans un format différent.

Questions fréquentes

Quelle est la différence entre les formulaires AIA G702 et G703 ?

Le G702 est la Demande et Attestation de Paiement — un récapitulatif d'une page qui présente la situation financière au niveau du contrat : montant initial du contrat, avenants, total réalisé à ce jour, retenue de garantie, paiements antérieurs et montant dû actuel. La Feuille de Continuation G703 fournit le détail par poste à partir du Tableau des Valeurs, en suivant la valeur prévue, les travaux achevés par période, les matériaux stockés et la retenue par poste. Les totaux du G703 alimentent directement les lignes récapitulatives du G702.

Comment la retenue de garantie est-elle calculée sur les formulaires AIA G702 et G703 ?

La retenue sur le G702 est généralement calculée comme un pourcentage fixe — habituellement 5 ou 10 % — de la Ligne 4 (Total des Travaux Achevés et Stockés à ce Jour). Sur le G703, la retenue peut être calculée par poste (Colonne I) lorsqu'un taux de retenue variable s'applique, ou laissée vide lorsqu'un taux fixe pour l'ensemble du projet est utilisé. Les colonnes calculées dans un outil d'extraction peuvent automatiser cette vérification en calculant la retenue attendue à partir des totaux extraits et en signalant les écarts.

L'IA peut-elle extraire des écritures manuscrites des feuilles de continuation G703 ?

Oui, mais la précision dépend de la lisibilité de l'écriture et de l'architecture de l'outil d'extraction. L'IA basée sur la vision qui lit les caractères dans leur contexte sémantique — comprenant qu'une valeur dans la colonne « Travaux Achevés Cette Période » est un montant en dollars, et non une date ou un numéro d'article — atteint une précision nettement supérieure sur les G703 manuscrits que l'OCR basé sur des modèles. Pour des écritures manuscrites lisibles, l'IA de vision moderne atteint une précision au niveau du champ d'environ 85 à 92 % ; pour une écriture difficile ou des formulaires avec de nombreuses annotations, la précision tombe entre 70 et 80 %. La solution pratique consiste à concevoir la sortie d'extraction avec une colonne de Score de Confiance et à ne vérifier que les valeurs signalées en dessous d'un seuil.

Puis-je traiter par lots les G702 de plusieurs sous-traitants à la fois ?

Oui. Le traitement par lots est le scénario où l’extraction par IA offre le meilleur rendement pour les entreprises générales. Importez tous les PDF de demandes de paiement — numériques ou manuscrits, de n’importe quel sous-traitant, sur n’importe quel chantier — en un seul lot. L’IA lit chaque formulaire indépendamment, extrait les données G702 et G703, et produit un tableur consolidé avec une colonne identifiant le fichier source. Le flux par lots gère automatiquement les formats mixtes : certains fichiers peuvent être des formulaires AIA numériques, d’autres des scans papier, d’autres encore des exports Excel en PDF. Pour une présentation complète de ce flux, voir traitement par lots des demandes de paiement AIA G702 sur un portefeuille de projets.

Les formulaires AIA G702 sont-ils payants ?

Oui. AIA Contract Documents détient les droits d’auteur sur les formulaires officiels G702 et G703. Un jeu G702/G703 à usage unique coûte environ 49,99 $ sur le site de l’AIA. Un abonnement annuel pour un accès illimité à tous les documents AIA coûte environ 500 $ par an. De nombreux entrepreneurs créent des versions tableur reproduisant la mise en page G702/G703 sans utiliser le formulaire protégé, mais celles-ci nécessitent une saisie manuelle et ne bénéficient pas de la même acceptation par les architectes et les propriétaires. L’extraction de données ne remplace pas le formulaire lui-même — elle automatise le transfert des données du formulaire rempli vers vos systèmes de suivi.

Procore prend-il en charge l’extraction de données G702/G703 ?

Les fonctionnalités d’IA de Procore, issues de l’acquisition de Datagrid, se concentrent sur l’analyse des documents contractuels, des soumissions et des RFI — pas sur l’extraction de données structurées des PDF de demandes de paiement entrants. Procore propose bien une fonctionnalité de facturation AIA pour générer des formulaires G702/G703 dans la plateforme, mais il s’agit d’un outil de création de documents, pas d’un outil d’extraction pour les formulaires reçus des sous-traitants. La voie d’intégration la plus courante consiste à extraire les données G702/G703 avec un outil dédié, puis à importer le résultat structuré dans Procore via un fichier Excel ou CSV.

Comment les codes CSI MasterFormat affectent-ils l'extraction G702/G703 ?

La plupart des feuilles de continuation G703 identifient les postes par leur code de division CSI MasterFormat — un système de numérotation normalisé géré par le Construction Specifications Institute. Ce système est structuré sous forme d'un nombre à six chiffres (par exemple, 03 30 00 pour le Béton coulé en place, 08 11 00 pour les Portes et cadres métalliques, 23 31 00 pour les Réseaux de gaines CVC). Pour les workflows de comptabilité de projet et de calcul des coûts qui utilisent ces codes, l'outil d'extraction doit conserver le code complet et la description, sans tronquer ni fusionner les champs adjacents. L'édition actuelle, MasterFormat 2026, ajoute environ 2 185 nouvelles entrées dans le cadre des 50 divisions.

Comment fonctionne le suivi des avenants dans l'extraction G702/G703 ?

Le G702 capture les avenants sous la forme d'un montant net unique sur la ligne 2 — le total de tous les ajouts et déductions approuvés par rapport au montant initial du contrat. Il ne liste pas les avenants individuels, leur statut ou leurs pièces justificatives. Un workflow d'extraction complet doit capturer non seulement le montant net des avenants du G702, mais aussi tout journal des avenants ou bordereau de transmission d'avenant que le sous-traitant inclut dans le dossier de demande de paiement. Cela donne au comptable du projet les détails nécessaires pour vérifier que le montant net est exact par rapport au registre des avenants du projet.

Quelle précision puis-je attendre de l'extraction G702/G703 ?

Sur des formulaires numériques propres avec du texte imprimé, la précision au niveau des champs pour l'extraction par IA basée sur la vision se situe généralement entre 92 et 98 % pour tous les champs G702 et G703. Sur les formulaires avec des écritures manuscrites, la précision varie de 80 à 92 % selon la lisibilité de l'écriture et l'état du formulaire. La mesure opérationnelle la plus importante n'est pas la précision brute, mais le taux de détection des erreurs : un workflow d'extraction bien conçu, avec des colonnes calculées et des validations croisées entre formulaires, signale les valeurs qui sortent des plages attendues, de sorte que le relecteur sache exactement quels champs inspecter plutôt que de devoir tout revérifier manuellement.

Quelle est la meilleure façon d'intégrer l'extraction G702/G703 avec Viewpoint ou Sage 300 CRE ?

Viewpoint (Trimble Vista et Spectrum) et Sage 300 CRE proposent des modules de facturation AIA pour les demandes de paiement créées dans le système, mais aucun n'ingère directement les données structurées des PDF G702/G703 reçus de l'extérieur. La voie d'intégration standard consiste à exporter les résultats d'extraction vers Excel ou CSV, puis à les importer dans le module de comptabilité clients ou de calcul des coûts des projets via les fonctions d'importation intégrées de la plateforme. Certains entrepreneurs généraux utilisent des outils intermédiaires comme Acumatica ou RabbitMQ pour automatiser le transfert, mais pour la plupart des entreprises, une exportation Excel bien structurée avec des colonnes mappées au modèle d'importation de la plateforme reste la solution la plus pratique.

Les formulaires G702 et G703 sont aussi standardisés que possible dans le domaine de la construction — conçus par l'AIA pour uniformiser la facturation d'avancement dans tout le secteur. Mais la standardisation du formulaire ne standardise pas le processus de saisie des données qui s'ensuit. Chaque demande de paiement est un instantané de la situation financière d'un projet à un moment donné, et cet instantané contient les informations nécessaires pour suivre les budgets, vérifier l'avancement et libérer les paiements. La couche d'extraction qui relie l'instantané au système de suivi n'est pas un luxe pour les entrepreneurs généraux qui traitent des dizaines de demandes par mois — c'est le seul moyen fiable de gérer le volume sans accepter le taux d'erreur qu'implique la saisie manuelle.

Téléchargez une seule demande de paiement pour voir comment l'extraction sémantique traite les formulaires de vos sous-traitants — ou lancez un lot complet de 30 demandes et regardez le tableur consolidé se remplir en quelques secondes. Les formulaires sont standardisés. L'extraction devrait l'être aussi.