Dans beaucoup d’entreprises, le contrat signé finit dans un dossier partagé, et ses informations utiles finissent dans un tableur rempli à la main. Date d’effet, durée, reconduction tacite, préavis, montant, clause d’indexation : chaque champ est recopié par quelqu’un, puis recopié à nouveau lorsqu’un outil de suivi change. Le jour où une échéance de résiliation passe inaperçue, le coût de cette ressaisie devient visible.
Ce qu’il faut extraire, et pourquoi la liste compte plus que l’outil
Un projet d’extraction réussi commence par une liste de champs, avant le choix d’un logiciel. Les équipes opérationnelles ont rarement besoin du contrat entier. Elles ont besoin d’une quinzaine d’informations, toujours les mêmes : les parties et leurs identifiants, la date de signature et la date d’effet, la durée et les conditions de reconduction, le délai de préavis, les montants et leur mode de révision, les pénalités, la limitation de responsabilité, la loi applicable et la juridiction compétente.
Cette liste sert ensuite de contrat de service pour l’outil. Chaque champ reçoit un format attendu (une date, un montant, une durée en mois) et une règle de contrôle. Un préavis de « trois mois » doit devenir « 3 », une reconduction « tacite par périodes successives d’un an » doit devenir « oui, 12 mois ». Sans cette normalisation, l’extraction produit du texte, et le tableur reste à remplir.
La chaîne technique, étape par étape
La première étape transforme le document en texte exploitable. Les contrats signés électroniquement sont déjà lisibles. Les contrats scannés, annotés ou paraphés à la main passent par un OCR, et la qualité de cette étape conditionne tout le reste. Un contrat bilingue, par exemple arabe et français pour une filiale au Maghreb, demande un moteur capable de lire les deux écritures dans la même page.
La deuxième étape repère les champs. Les modèles de langage récents savent lire une clause rédigée librement et en tirer une valeur structurée, là où les anciennes méthodes par gabarit échouaient dès que la mise en page changeait. Le modèle reçoit le schéma de champs défini plus haut et doit répondre dans ce format, avec, pour chaque valeur, le passage du contrat dont elle provient.
La troisième étape contrôle. Une date d’effet antérieure à la date de signature, un montant sans devise, une durée incohérente avec la date de fin : ces anomalies se détectent par des règles simples. Chaque valeur reçoit aussi un niveau de confiance.
La quatrième étape fait intervenir l’humain, mais seulement là où il apporte quelque chose. Les valeurs sûres et cohérentes passent directement dans le référentiel contractuel. Les autres arrivent dans une file de validation, avec le passage source affiché à côté du champ. Le juriste ou l’opérationnel vérifie en quelques secondes au lieu de relire le contrat.
Le point que les démonstrations oublient, la confidentialité
Un contrat contient des prix, des conditions négociées, parfois des données personnelles. L’envoyer à un service en ligne pour en extraire trois dates revient à confier l’ensemble du document à un tiers. Pour une direction juridique ou achats, la question de l’hébergement se pose donc avant celle de la précision. Une extraction installée sur l’infrastructure de l’entreprise, ou chez un hébergeur qualifié qu’elle a choisi, règle la question à la source.
Par où commencer
Le bon premier périmètre est étroit : un seul type de contrat (baux, contrats fournisseurs, contrats de maintenance), une centaine de documents réels, une liste de champs validée par les utilisateurs. On mesure alors deux chiffres, la part des champs extraits sans correction et le temps de validation des autres. Ces deux mesures disent si le projet mérite d’être étendu.
Chez BADIS AI, nous déployons ce type de chaîne sur l’infrastructure de nos clients, OCR bilingue compris. Notre page consacrée à l’extraction documentaire sans ressaisie détaille la démarche.
Nadir Krid, cofondateur de BADIS AI, éditeur de logiciels d’IA souverains déployés on-premise.
