Exigences de soumission du code du bâtiment,
Enfouies dans 1 000 pages

L'erreur qui ne se révèle que trois semaines plus tard

Une exigence de soumission manquée est rarement détectée au moment où elle est omise. Elle refait surface plus tard, lorsqu'un article à délai de livraison long atteint le stade de la fabrication sans que personne n'ait approuvé le plan d'atelier, ou lorsqu'un examinateur demande un certificat qui n'a jamais été soumis. Sur un projet commercial, les soumissions constituent la porte d'entrée qui ouvre l'approvisionnement et l'installation pour chaque corps de métier. Un seul élément omis peut bloquer un corps de métier jusqu'à ce que son dossier soit approuvé en revue.

Le coût de ce schéma est mesuré, pas anecdotique. Une enquête conjointe de PlanGrid et FMI auprès de près de 600 professionnels de la construction, Construction Disconnected, a attribué 48 pour cent des reprises aux États-Unis, et 52 pour cent à l'échelle mondiale, à de mauvaises données de projet et à des erreurs de communication, un chiffre qu'elle évalue à 31,3 milliards de dollars aux États-Unis pour une seule année. Les informations de projet manquantes ou inaccessibles se situent du côté des données de cette répartition. Une liste d'exigences assemblée à la main et censée être complète est exactement le type de document que l'enquête décrit.

Où se trouvent réellement les exigences de soumission

Dans un manuel de projet standard, les règles relatives aux soumissions se trouvent dans une section, mais la liste de ce qui doit être soumis ne s'y trouve pas. Ce sont deux documents différents qui remplissent des fonctions différentes, et assembler l'ensemble complet des exigences de soumission du code du bâtiment implique de lire les deux.

Les règles se trouvent dans la Division 01 du CSI MasterFormat, Section 01 33 00, « Procédures de soumission », qui contient les exigences administratives et procédurales pour les plans d'atelier, les données produit, les échantillons, les certificats et les transcriptions de soumissions (CSI MasterFormat). Le calendrier se trouve dans la Section 01 32 19, « Calendrier des soumissions », qui fixe la date d'échéance de chaque dossier. Aucune de ces sections ne liste chaque élément. Les éléments réels se trouvent dans la Partie 1, Généralités de chaque section de spécifications techniques des Divisions 02 à 49, où un article « Soumissions » vous indique quels plans d'atelier, données produit et échantillons ce corps de métier doit fournir. Une section sur le béton renvoie à la section 01 33 00 pour le processus, puis nomme ses propres produits. Ce schéma se répète dans chaque section, et les dessins ajoutent des exigences que les spécifications ne réitèrent jamais.

La chaîne d'outils reflète cette séparation. Adobe Acrobat ouvre et recherche dans un seul fichier, Bluebeam Revu annote les documents pour une revue collaborative avec ses Studio Sessions, et Procore Submittals suit les dossiers et leur statut sur l'ensemble du projet. Le registre lui-même vit toujours dans un tableur, et chacun de ces outils l'alimente.

Un code du bâtiment est une espèce différente de document long. Le code international du bâtiment 2024 compte 35 chapitres et plus de 750 pages (ANSI), et il ne contient pas toutes ses propres exigences. Le chapitre 35, Références normatives, délègue une grande partie de l'obligation à des documents externes tels que l'ASCE 7, l'ACI 318 et la NFPA 13 (ICC), et l'adoption est locale, de sorte que la version en vigueur est modifiée État par État et ville par ville. Ce qu'un praticien appelle « le code » est une union à travers un ensemble de documents, et non un fichier unique. Lorsque cet ensemble arrive relié en un seul PDF énorme, le diviser selon ses propres limites de section est un travail distinct, traité dans comment gérer un PDF de plusieurs milliers de pages.

L'ensemble des exigences n'est jamais stocké à un seul endroit. C'est l'union des règles de la Division 01, d'un article sur les soumissions dans chaque section technique, des notes de dessin et des normes de référence, ce qui explique pourquoi tout trouver se comporte comme un problème de recherche sur un corpus plutôt que comme une consultation dans un fichier.

Pourquoi Ctrl+F échoue : c'est un problème de rappel

L'échec est mécanique, pas personnel. Ctrl+F renvoie chaque occurrence de la chaîne exacte que vous avez saisie, de sorte que la précision est élevée et que le rappel se limite à la seule formulation que vous avez devinée. Une exigence de soumission apparaît rarement sous un seul nom. La même obligation peut être rédigée comme « soumission », « plan d'atelier », « données produit », « échantillon », « certificat », « rapport d'essai » ou un simple « soumettre ... pour revue ». Extrayez les exigences de soumission avec un seul mot-clé et vous ne trouvez qu'un sous-ensemble.

La recherche d'information a formulé cette tension depuis des décennies. Robert Fairthorne a décrit deux types de systèmes : « Only-But-Not-All », qui privilégie la précision, et « All-But-Not-Only », qui privilégie le rappel. Une recherche web veut le premier, car personne ne lit au-delà de la première page. Le travail de conformité veut le second, car un faux positif coûte un coup d'œil et un faux négatif coûte un calendrier. Les outils auxquels les gens recourent sur un cahier des charges, de Ctrl+F à la barre de recherche d'un lecteur PDF, sont des instruments de précision destinés à un travail de rappel.

Lire tout le document à la main est l'alternative à rappel élevé, et elle se dégrade avec le volume. Un fil sur r/ConstructionManagers s'ouvre sur « pourquoi les soumissions sont-elles un tel cauchemar », et la première réponse est « Toujours pénible, chaque chantier a des spécifications différentes ». Cette variation est le problème de rappel en langage clair. Lorsqu'une équipe tente de l'automatiser, le manque de confiance apparaît aussi. Sur un autre fil demandant un logiciel qui lit une spécification et renvoie une liste Excel des soumissions requises, un gestionnaire a rapporté que le registre automatique de Procore « aboutit généralement à beaucoup d'erreurs » et a conseillé à un autre de « passer la journée à le faire manuellement. Ensuite, vous saurez que c'est juste » (r/ConstructionManagers). L'objection n'est pas que l'automatisation est lente. C'est qu'une liste non vérifiée ne peut pas être digne de confiance.

Étape 1 : définir l'ensemble de colonnes avant d'extraire

Pour extraire de manière fiable les exigences d'un code, il faut d'abord décider à quoi ressemble une exigence, puis ne récupérer que ces champs. C'est l'inverse de l'ordre habituel de traitement des documents. Au lieu de demander à un outil de résumer 1 000 pages, vous nommez les cinq colonnes souhaitées et laissez l'outil localiser chacune d'elles par le sens.

Dans ImageToTable.ai, il s'agit de Custom Column Extraction. Vous saisissez des noms de colonnes, et l'IA trouve les valeurs correspondantes n'importe où dans le document en comprenant ce que chaque champ signifie plutôt que sa position, sans modèle par document ni ensemble d'apprentissage. Pour une liste d'exigences de soumission, un ensemble de colonnes fonctionnel est le suivant :

• Spec Section, le numéro et le titre de la section qui impose l'exigence, par exemple 05 12 00 Structural Steel.
• Requirement, l'élément à soumettre, dans les termes du document.
• Submission Type, issu d'une liste contrôlée telle que Shop Drawing, Product Data, Sample, Certificate, Test Report ou Mockup.
• Deadline, la date ou le délai que la section ou le Submittals Schedule y associe.
• Responsibility, le corps de métier ou la partie qui en est redevable.

Deux de ces colonnes méritent d'être construites délibérément. Submission Type est une colonne inférée, où l'IA classe l'exigence à partir du contexte et la fait correspondre aux options que vous listez, même lorsque le document n'imprime jamais le libellé « Shop Drawing ». Responsibility fonctionne de la même manière. Pour les utilisateurs connectés, un Rule Format garde les noms de colonnes propres et déplace la normalisation dans une règle JSON, ce qui importe lorsque vous voulez toutes les dates dans un même format ou tous les numéros de section avec des zéros non significatifs. Le but de l'exercice est qu'une liste d'exigences est un petit schéma nommé, et non un résumé du document.

Étape deux : extraire, puis vérifier la ligne par rapport à la page

L'extraction produit la liste. La vérification au niveau de la page est ce qui la rend défendable, car la seule chose dont un réviseur a besoin est un chemin rapide d'une ligne vers la phrase qui l'exigeait.

Côté extraction, les documents longs sont traités par lots plutôt qu'en un seul fichier. L'application web et l'API plafonnent un téléchargement unique à 10 MB et 50 pages. Un code de 1 000 pages est donc traité par morceaux puis fusionné en une seule feuille de calcul, avec les mêmes colonnes nommées extraites de chaque morceau. La mécanique correspond à une exécution par lots sur un dossier, et l'objectif est le même que pour convertir un PDF en Excel, à l'échelle d'un fichier unique jusqu'à un recueil de codes. Pourquoi une couche de texte change la donne est expliqué dans ce que l'extraction multipage peut et ne peut pas faire.

Côté vérification, Review Mode associe chaque cellule extraite à son emplacement source via Bbox, le cadre englobant que l'IA dessine autour de la région d'où provient une valeur. Survolez n'importe quelle cellule de la feuille de calcul et la région correspondante se met en surbrillance sur la page d'origine. Cliquez sur une région de la page et la vue revient à la cellule correspondante. Vous pouvez le déclencher pour un seul fichier, ce qui coûte un crédit, ou activer l'annotation automatique pour que les cadres soient déjà générés dès la fin du traitement. L'effet pratique est que confirmer une ligne par rapport à une source de 1 000 pages prend des secondes au lieu d'une recherche manuelle, et ce même mécanisme est ce qui rend une liste de vérification utile à exécuter.

Le plan de revue : échantillonner largement, relire ce qui compte

Un plan de revue doit concentrer ses efforts proportionnellement au coût d'une omission, et non les répartir uniformément sur 300 lignes. La plupart des lignes d'une liste de soumissions sont des données produit à faible enjeu. Quelques-unes conditionnent l'ensemble du chantier.

Trois actions couvrent l'essentiel du risque :

Un gestionnaire du fil r/ConstructionManagers mentionné ci-dessus a exprimé le même instinct en une phrase : « Toujours retracer la soumission jusqu'à la section de cahier des charges ou à la note de dessin exacte qui l'exige. » Un plan de revue est cette consigne transformée en séquence reproductible, afin que le traçage s'opère sur les sections qui peuvent vous nuire plutôt que sur les lignes qui attirent l'œil.

Ce qu'aucun outil ne peut garantir ici

Aucun modèle ne garantit l'exhaustivité sur un document normatif de 1 000 pages, et tout produit qui prétend le contraire décrit une démonstration, pas un cahier des charges. Le rappel est limité par l'ensemble de colonnes et les mots qu'il contient. Si une exigence est formulée d'une manière que vos colonnes ne décrivent jamais, un modèle peut encore la manquer, ce qui explique précisément pourquoi le plan de revue existe et pourquoi c'est le plan, et non l'extraction, qui porte la garantie.

L'outil n'interprète pas non plus le code. Il extrait le texte d'exigence que vous demandez ; il ne décide pas si une exigence s'applique à votre périmètre, si une norme de référence modifie l'obligation, ou si la soumission que vous produisez finalement est conforme. Ce sont des jugements professionnels. Sur un document dont les exigences résident en partie dans les références du Chapter 35 et les amendements locaux, l'extraction ne peut couvrir que le fichier que vous lui donnez, et l'assemblage de l'ensemble complet des documents est une étape qu'aucun extracteur n'effectue pour vous.

Lues ensemble, les deux limites définissent la méthode honnête : un ensemble de colonnes défini pour améliorer le rappel, et un plan de revue dimensionné au risque d'un oubli. Tout le reste est une affirmation que personne ne peut étayer.

FAQ

L'IA peut-elle trouver chaque exigence de soumission dans un code du bâtiment de 1 000 pages ?

Pas avec une garantie. Un extracteur basé sur la vision peut extraire un ensemble défini de colonnes de l'ensemble du document avec un rappel bien supérieur à une recherche par mots-clés, et la vérification au niveau de la page vous permet de contrôler le résultat. L'exhaustivité dépend toujours de votre ensemble de colonnes et d'une passe de revue sur les sections où un oubli coûte cher.

Dois-je téléverser tout le code dans un seul fichier ?

Non. Un téléversement unique est limité à 10 MB et 50 pages, et la précision du traitement se maintient mieux lorsqu'un document long est découpé en morceaux puis fusionné. Divisez le code selon ses propres limites de section, traitez les morceaux comme un seul lot, et extrayez les mêmes colonnes de chacun. La mécanique d'une exécution multi-fichiers est la même que pour le traitement par lots de plusieurs fichiers à la fois.

Comment détecter les exigences formulées avec des mots différents ?

Décrivez le champ plutôt qu'une chaîne littérale. Une colonne inférée avec une liste d'options, comme Submission Type défini sur Shop Drawing, Product Data, Sample, Certificate, Test Report, ou Mockup, permet au modèle de classer l'exigence selon le contexte au lieu de faire correspondre un mot-clé. C'est la différence entre rechercher et extraire.

Est-ce que cela remplace un journal des soumissions ?

Non. L'extraction produit la première liste de passage qui alimente le journal. Le suivi du statut, des réviseurs et des dates d'approbation relève toujours d'un outil de gestion des soumissions ou d'un tableur. Ce qui change, c'est que le journal démarre à partir d'une liste vérifiable au lieu d'une saisie manuelle que personne ne peut entièrement vérifier.

Peut-il me dire si une exigence s'applique à mon périmètre ?

Non. L'outil extrait le texte de l'exigence et les champs que vous nommez. Déterminer l'applicabilité, lire les normes de référence et confirmer la conformité restent des décisions humaines, et le plan de revue est l'endroit où ces décisions sont prises.

L'instinct de faire un Ctrl+F sur un long document est judicieux. Il vise simplement la mauvaise mesure. La recherche récompense la précision, la conformité récompense le rappel, et l'écart entre les deux est l'endroit où une soumission manquée vous attend. Définissez les colonnes, extrayez uniquement celles-ci, et consacrez votre revue aux sections où une omission vous coûterait réellement. Une liste d'exigences que vous pouvez retracer jusqu'à la page vaut plus qu'une liste à l'apparence complète que vous ne pouvez pas vérifier.

Essayez sur un PDF de cahier des charges