Le suivi des attestations d'assurance dans le BTP reste
figé aux e-mails et tableurs

Le tableur COI : un rite de passage universel dont personne ne se vante

Sur le subreddit r/ConstructionManagers, un nouveau coordinateur de projet a posté il y a six mois : « Je passe mes journées à relancer les sous-traitants par e-mail pour obtenir leur nouvelle attestation avant l'expiration de l'ancienne. C'est complètement dingue et hyper risqué. Une seule date oubliée dans ce tableur pourrait coûter des millions à l'entreprise. Est-ce que tout le monde fait vraiment comme ça ? »

Les réponses ont formé un haussement d'épaules collectif : oui, tout le monde fait comme ça, et oui, c'est un cauchemar. Un chef de projet a décrit son système comme « des tableurs et des appels téléphoniques ». Un autre a évoqué la peur de « suivre la licence expirée jusqu'à ce que l'inspecteur du comté débarque ». Dans un troisième fil, un petit entrepreneur général a demandé tout simplement : « C'est normal que ce soit une galère ? »

Ce que révèlent ces fils, ce n'est pas que les professionnels du bâtiment sont mauvais en conformité. Ce qu'ils révèlent, c'est que le suivi des attestations occupe un angle mort dans la pile technologique du secteur — une tâche qui tombe entre le logiciel de gestion de projet et les systèmes comptables, revendiquée par aucun, résolue par personne.

L'outil par défaut est toujours le même : un tableur maître. Des colonnes pour le nom du sous-traitant, le type de police, l'assureur, le numéro de police, les plafonds de couverture, la date d'effet, la date d'expiration, le statut d'assuré supplémentaire, la renonciation à recours, et un champ de notes qui s'allonge à chaque cycle de renouvellement. Quand le tableur reste sous les 30 lignes, ça marche. Avec 50 sous-traitants et quatre lignes de police chacun, vous gérez 200 points de données dans une matrice où une seule cellule obsolète peut signifier un sous-traitant non assuré travaillant sur un chantier actif.

Un certificat d'assurance n'est pas la police — et le tableur ne peut pas faire la différence

Le formulaire ACORD 25 d'attestation d'assurance responsabilité civile — le document COI standard utilisé dans le secteur de la construction aux États-Unis — contient une mention en lettres majuscules grasses que la plupart des gens ignorent : « CE CERTIFICAT EST DÉLIVRÉ À TITRE D'INFORMATION UNIQUEMENT ET NE CONFÈRE AUCUN DROIT AU TITULAIRE DU CERTIFICAT. CE CERTIFICAT NE MODIFIE, NI N'ÉTEND, NI N'ALTÈRE LA COUVERTURE OFFERTE PAR LES POLICES CI-DESSOUS, QUE CE SOIT DE MANIÈRE POSITIVE OU NÉGATIVE. »

Il ne s'agit pas de clauses en petits caractères. C'est l'architecture juridique du document. Un certificat d'assurance résume ce qu'un agent d'assurance croit qu'une police stipule. Il n'engage pas l'assureur. Il ne garantit pas que la couverture mentionnée existe. Il ne prouve pas que l'entrepreneur général a été ajouté comme assuré supplémentaire, même si cette phrase apparaît dans la case du titulaire du certificat.

Regardez de près ce que ces défaillances révèlent, et vous comprendrez pourquoi un tableur ne peut pas les détecter. Le COI mentionne une couverture générale de 2 millions de dollars — mais la police réelle exclut le travail spécifique du sous-traitant. L'attestation indique le GC comme assuré supplémentaire — mais seulement via une avenant CG 20 10 couvrant les opérations en cours, pas le CG 20 37 pour les travaux achevés, créant une lacune après la fin du chantier, découverte des mois plus tard. La case de renonciation à subrogation est cochée — mais l'avenant n'a jamais été déposé auprès de l'assureur.

Un formulaire ACORD 25, selon l'Independent Insurance Agents & Brokers of America, est vulnérable à trois problèmes majeurs : la fraude des agents qui attestent de couvertures inexistantes pour qu'un sous-traitant décroche un contrat ; des exigences contractuelles d'assurance trop lourdes que les polices du marché ne peuvent satisfaire ; et le problème persistant des détenteurs d'attestation qui ne reçoivent jamais l'avis de résiliation promis. Le tableur ne voit rien de tout cela. Il enregistre ce que dit le PDF et passe à autre chose.

Chaque tableur de suivi des COI dans la construction repose donc sur des données systématiquement peu fiables. Le goulot d'étranglement de la saisie — les cinq minutes par attestation à recopier les champs d'un PDF dans Excel — est réel, mais ce n'est que le deuxième problème. Le pire, c'est que les données saisies sont erronées 90 % du temps, et le tableur n'a aucun moyen de le détecter.

Le relais à quatre que personne n'a conçu et que personne ne gagne

Pour comprendre pourquoi les e-mails et les tableurs restent le flux de travail par défaut pour les COI, suivez le parcours d'une seule attestation.

L'entrepreneur général envoie un contrat au sous-traitant précisant les assurances requises : responsabilité civile générale à 2 millions $ par sinistre / 4 millions $ cumul, accidents du travail aux limites légales, automobile commerciale à 1 million $, parapluie à 5 millions $, avec avenants d'assuré supplémentaire et renonciation au recours subrogatoire. Le sous-traitant transmet ces exigences à son agent d'assurance. L'agent extrait les informations de police du système de l'assureur et remplit un formulaire ACORD 25 — un processus qui, comme l'a montré l'audit IRMI, présente un taux d'erreur supérieur à 90 % par rapport aux termes du contrat.

L'agent envoie le PDF du COI par courriel au sous-traitant, qui le transmet au coordonnateur de projet de l'entrepreneur général. Le coordonnateur ouvre le PDF, lit chaque champ — numéro de police, nom de l'assureur, types de couverture, limites, date d'entrée en vigueur, date d'expiration, assuré supplémentaire O/N, renonciation au recours subrogatoire O/N — et les saisit dans le tableur maître. Le PDF est placé dans un dossier réseau partagé avec une convention de nom de fichier qui varie selon le dernier utilisateur à l'avoir enregistré. Le tableur est mis à jour. Le coordonnateur définit un rappel calendaire 30 jours avant l'expiration.

Quatre parties, quatre transferts, zéro vérification des conditions de police sous-jacentes. Le coordonnateur au bout de cette chaîne retranscrit des données provenant d'un document lui-même compilé à partir d'un système d'assureur par un agent travaillant à partir d'un courriel transmis — quatre degrés de séparation de la source de vérité. À chaque étape, les données se dégradent. Un chiffre erroné dans un numéro de police. Une limite de couverture inversée. Un avenant d'assuré supplémentaire discuté par téléphone mais jamais déposé.

Ce n'est pas un processus défaillant qu'une meilleure discipline pourrait corriger. C'est un flux de travail multipartite où chaque participant a des incitations différentes. Le sous-traitant veut être sur le chantier et être payé — la paperasse d'assurance est une friction. L'agent du sous-traitant veut conserver le compte — délivrer un certificat qui dit ce que le contrat exige, même si la police ne le couvre pas, sert cet objectif. Le coordinateur du GC veut cocher une case et passer au sous-traitant suivant. Le libellé réel de la police de l'assureur est la seule chose qui compte en cas de sinistre, et c'est la seule chose que personne dans la chaîne, à part le souscripteur de l'agent, ne lit jamais.

Les renouvellements de polices d'assurance amplifient cela de façon exponentielle. La police de responsabilité civile générale d'un sous-traitant se renouvelle chaque année, mais pas à la même date que son assurance accidents du travail. Son umbrella se renouvelle à une troisième date. Son auto à une quatrième. Chaque cycle de renouvellement déclenche le relais complet des quatre parties pour chaque ligne de police de chaque sous-traitant — et chaque renouvellement crée une nouvelle opportunité d'erreur qui atterrit dans le tableur comme si rien n'avait changé.

L'industrie a acheté le logiciel. Le tableur est resté.

La construction n'est pas une industrie réfractaire à la technologie. L'Enquête de perspectives 2025 de l'Associated General Contractors of America a révélé que 66 % des grands entrepreneurs utilisent un logiciel de gestion de projet, 44 % un logiciel d'estimation, 40 % un logiciel de planification. L'entreprise moyenne déploie 6,2 outils numériques distincts. Ce n'est pas une industrie qui refuse d'adopter la technologie. C'est une industrie où la technologie adoptée n'a pas été conçue pour résoudre le problème du COI.

Procore gère les ordres de modification, les RFI, les soumissions et les listes de contrôle. Il ne vérifie pas si la police d'assurance responsabilité civile générale d'un sous-traitant couvre réellement les travaux qu'il effectue. Pour intégrer le suivi de conformité des COI dans Procore, un entrepreneur général doit acheter une intégration distincte : Billy, myCOI, Jones, SmartCompliance ou TrustLayer. Chacun de ces outils se connecte à Procore via une API et synchronise l'état de conformité, mais l'étape fondamentale de capture des données — lire un PDF de COI et en extraire les champs — reste une étape manuelle qui se produit avant que le logiciel ne puisse faire quoi que ce soit d'utile.

Le panneau latéral Procore de la plateforme Billy, par exemple, permet à un responsable de la conformité de voir le statut d'assurance des sous-traitants sans quitter Procore — mais quelqu'un doit d'abord télécharger le PDF du COI, et soit l'équipe de révision gérée, soit le personnel interne de l'entrepreneur général doit le vérifier par rapport aux exigences. myCOI remplit une fonction similaire avec une équipe d'experts en assurance agréés. Jones ajoute une vérification assistée par IA qui signale le langage d'exclusion dans les polices réelles. Ce sont des services précieux. Mais ils fonctionnent au-dessus du même goulot d'étranglement de capture de données que le tableur : un PDF arrive par e-mail, et quelqu'un doit décider ce qu'il contient.

La raison pour laquelle le tableur persiste n'est pas que les prestataires refusent d'acheter un logiciel. C'est que le logiciel qu'ils ont acheté a été conçu pour gérer le statut de conformité une fois les données dans le système — pas pour intégrer les données dans le système à partir des PDF reçus par e-mail. Cette étape — lire les numéros de police, les limites de couverture et les dates d'expiration sur un formulaire ACORD d'une page et les saisir dans un enregistrement structuré — est le maillon intermédiaire non automatisé de tout le flux de travail. Tant qu'elle n'est pas résolue, toute plateforme de suivi des COI est en aval d'une étape de saisie manuelle, et tout utilisateur de tableur qui reste sur son tableur reconnaît à un certain niveau que payer pour une plateforme afin de gérer des données qu'il doit encore taper manuellement n'est pas une amélioration évidente.

La couche manquante : extraire les données du PDF vers le tableur sans taper

Si le problème structurel est que les données des COI se trouvent dans des PDF et que les outils de suivi ont besoin de données structurées, l'intervention la plus directe n'est pas de remplacer le tableur ou d'acheter une autre plateforme. Il s'agit de supprimer l'étape de saisie manuelle — les cinq minutes par certificat, les chiffres inversés, les dates d'expiration copiées-collées — en la transformant en quelque chose qui se produit automatiquement à l'arrivée du PDF.

C'est là que l'extraction de documents change l'économie du suivi des COI. Au lieu de lire les champs du formulaire ACORD 25 et de les taper dans Excel, vous définissez les colonnes dont vous avez besoin — Numéro de police, Assureur, Type de couverture, Limite par sinistre, Limite annuelle, Date d'effet, Date d'expiration, Assuré supplémentaire (O/N), Renonciation à recours (O/N) — et laissez l'IA localiser chaque valeur sur le PDF du COI. Le résultat est une ligne dans votre tableur avec tous les champs renseignés, sans aucune saisie. Le PDF va dans un dossier. Les données vont dans le suivi. L'écart entre la réception d'un certificat et son enregistrement se réduit à quelques secondes.

Cette approche fonctionne car les formulaires ACORD 25, bien que standardisés dans leur mise en page, arrivent en pratique sous forme d'images scannées, de PDF aplatis, de documents signés numériquement, et parfois de photos d'attestations imprimées prises sur un chantier — autant de formats où la reconnaissance optique traditionnelle par modèle échoue, car les positions des pixels varient. L'extraction par nom de colonne d'ImageToTable.ai contourne ce problème en comprenant le contenu sémantique du formulaire plutôt qu'en cherchant des coordonnées : elle identifie « Assureur A » et récupère le numéro de police adjacent en fonction du sens du texte, et non de son emplacement.

Ce qui rend cette approche durable, c'est qu'elle ne vous oblige pas à abandonner votre flux de travail actuel. Vous pouvez continuer à utiliser votre tableur. Vous pouvez continuer à utiliser votre dossier partagé. Vous pouvez continuer à utiliser — ou ajouter — une plateforme de suivi des attestations comme Billy ou myCOI en aval, car les données extraites alimentent tout système acceptant Excel ou CSV. Le relais email continue de fonctionner — les sous-traitants reçoivent toujours leurs polices de leurs agents et transmettent les attestations au GC — mais le coordinateur ne passe plus ses journées à recopier ces PDF dans des cellules. Le tableur devient un tableau de bord alimenté par l'extraction, et non un terminal de saisie.

La même couche d'extraction fonctionne pour l'ensemble du casse-tête documentaire auquel sont confrontés les coordinateurs de projet dans la construction. Les factures des sous-traitants arrivent dans 15 formats différents, mais l'équipe comptable a besoin des mêmes champs pour chacune. Les renonciations de privilège, les W-9 et les licences professionnelles ont chacun leurs propres données que quelqu'un saisit actuellement dans un suivi séparé. L'extraction par nom de colonne les traite tous comme une seule et même opération : définir les colonnes, télécharger les documents, obtenir des données structurées — quelle que soit la catégorie de conformité à laquelle ils appartiennent.

Ceci ne remplace pas les plateformes dédiées au suivi des attestations d'assurance. Ces plateformes vérifient le libellé des polices, signalent les avenants restrictifs, assurent la conformité entre projets et fournissent des pistes d'audit — des fonctions qu'un tableur ne peut reproduire et qu'un outil d'extraction ne cherche pas à imiter. L'extraction résout le problème en amont : récupérer les données du PDF pour les intégrer au système qui les utilisera. C'est la couche qui manquait depuis le début — la raison pour laquelle le tableur est devenu la norme et l'est restée, même après l'adoption de toutes les autres catégories de logiciels par le secteur.

Questions fréquentes

Pourquoi Procore ou Sage ne gèrent-ils pas le suivi des attestations d'assurance ?

Procore et Sage 300 CRE sont des plateformes de gestion de projet et de comptabilité — elles organisent les données financières et opérationnelles une fois qu'elles sont dans le système. Aucune n'a été conçue pour lire un PDF d'attestation, extraire les champs d'assurance ou vérifier que la couverture indiquée sur un certificat correspond à la police sous-jacente. La place de marché d'applications Procore répertorie des modules complémentaires tiers (Billy, myCOI, Jones, SmartCompliance) qui reconnectent l'état de conformité des attestations au tableau de bord Procore, mais la première étape de capture des données — la lecture d'un formulaire ACORD 25 — nécessite toujours un humain ou un outil d'extraction distinct. La lacune ne réside pas dans les fonctionnalités de Procore. Elle tient à l'hypothèse architecturale selon laquelle les données des attestations arrivent déjà numérisées.

Pourquoi ne pas simplement exiger que tous les sous-traitants soumettent leurs attestations via un portail ?

Les portails transfèrent la charge de saisie des données de vous vers le sous-traitant ou son agent d'assurance — mais ne l'éliminent pas. Quelqu'un doit toujours lire le formulaire ACORD 25 et remplir les champs. La friction liée à l'obligation pour l'agent d'assurance de chaque sous-traitant de se connecter à une nouvelle plateforme explique le faible taux d'adoption des outils de suivi des COI basés sur des portails. On ne peut pas exiger d'un sous-traitant qui travaille pour six entrepreneurs généraux différents qu'il maintienne des comptes sur six portails de conformité distincts. C'est pourquoi l'e-mail persiste : c'est le seul canal de communication adopté à 100 % par tous les sous-traitants, agents d'assurance et coordinateurs d'entrepreneurs généraux. L'intervention la plus efficace consiste à rendre l'extrémité réceptrice capable de traiter tout format arrivant via ce canal universel.

Un certificat d'assurance est-il juridiquement contraignant ?

Non. Un certificat d'assurance ACORD 25 est, selon ses propres termes, délivré « à titre d'information uniquement » et « ne confère aucun droit au détenteur du certificat ». Il ne modifie, n'étend ni n'altère la police d'assurance qu'il décrit. Les seuls documents juridiquement contraignants sont la police d'assurance elle-même et les avenants qui y sont attachés. Si un certificat mentionne l'entrepreneur général comme assuré supplémentaire mais que l'avenant n'a jamais été effectivement déposé auprès de l'assureur, l'entrepreneur général n'a aucune couverture — quoi que dise le certificat. C'est le malentendu le plus dangereux dans la conformité en construction, et c'est pourquoi la conclusion de l'audit d'IRMI selon laquelle 90 %+ des assurances des entrepreneurs ne répondent pas aux exigences contractuelles n'est pas un problème de paperasse — c'est un problème d'exposition non assurée.

Quelle est la différence entre ACORD 25 et ACORD 28 ?

Le formulaire ACORD 25 est un certificat d'assurance responsabilité civile — il résume les couvertures responsabilité (générale, automobile, accidents du travail, parapluie) qui protègent contre les réclamations de tiers. C'est le formulaire que les sous-traitants soumettent aux entrepreneurs généraux. L'ACORD 28 est une preuve d'assurance de biens commerciaux — il documente la couverture des biens (bâtiment, contenu, équipement) pour les pertes directes. Dans la construction, l'ACORD 25 est le formulaire que les entrepreneurs généraux reçoivent 95 % du temps ; l'ACORD 28 apparaît lorsqu'un propriétaire de projet a besoin de prouver que l'entrepreneur général ou un sous-traitant détient une couverture risque du constructeur ou équipement. Les deux portent les mêmes mentions légales : aucun n'est une police, et aucun ne confère de droits au détenteur du certificat.

Un outil d'extraction par IA vérifie-t-il si la couverture est adéquate ?

Non. Un outil d'extraction remplit des données structurées à partir d'un PDF de COI — numéros de police, limites de couverture, dates d'expiration — mais il ne vérifie pas si ces chiffres satisfont aux exigences d'assurance du contrat, si les avenants listés existent réellement sur la police, ou si la couverture décrite sur le certificat correspond au libellé réel de la police de l'assureur. Cette étape de vérification nécessite soit un spécialiste en conformité humain lisant la police, soit une plateforme dédiée de suivi des COI avec des capacités de vérification au niveau de la police. L'extraction simplifie la couche de saisie des données. La vérification de conformité est une étape distincte et nécessaire en aval.