Forest et la nécessité de traiter la décision comme une infrastructure, pas comme une boîte de réception

Une société de location de véhicules avec laquelle nous travaillons nous a un jour envoyé un fichier dont nous étions discrètement fiers. Cinquante-trois pages, quatre documents agrafés en un seul PDF par quelqu'un de pressé, dont deux à l'envers, et un certificat d'immatriculation où le nom du titulaire était imprimé en travers d'un filigrane de sécurité conçu spécifiquement pour mettre les scanners en échec. Il est revenu en quatre-vingt-dix secondes : chaque partie identifiée, chaque partie rattachée à la personne à qui elle appartenait, chaque chiffre doté d'une bounding box permettant de cliquer pour revenir à son emplacement exact sur la page.

Puis il est resté dans la boîte de réception de quelqu'un pendant deux jours, car personne n'était sûr de savoir qui était autorisé à approuver un contrat de location de plus de cinquante mille euros.

■ Série partenaire

Forest×

La provenance à l'entrée.La responsabilité à la sortie.

Holofin

Le document devient une donnée de confiance, avec une bounding box derrière chaque champ.

Forest

La donnée devient une décision, routée, soumise à des permissions et journalisée comme n'importe quelle autre action.

La précision a un chiffre. L'attente n'en a pas.

L'extraction est scrutée à la loupe parce qu'on peut y associer un chiffre. La précision a un chiffre, les benchmarks ont des tableaux, et les tableaux sont comparés lors des achats. C'est là que nous investissons notre ingénierie, et c'est là que le marché regarde.

Rien de ce qui suit l'extraction n'a de chiffre.

Pensez à ce que cela cache. Un dossier attend trois jours dans une boîte mail partagée, et cette attente coûte plus cher qu'un chiffre mal lu ne l'a jamais fait. Un réviseur ouvre un PDF de quarante pages parce que le système a dit "nécessite une révision" et rien d'autre, et perd une après-midi. Demain, un autre réviseur, une autre après-midi, et ainsi de suite. Une approbation se déroule correctement et ne laisse aucune trace, ce qui ne coûte rien du tout jusqu'à ce qu'un auditeur pose une question à ce sujet, moment auquel cela coûte tout.

Rien de tout cela n'apparaît dans un benchmark. Tout cela se reflète dans les effectifs, et dans la rapidité avec laquelle votre entreprise peut dire oui.

Ce qui est gênant pour une entreprise qui vend de l'extraction. Nous pouvons pousser notre chiffre plus haut et laisser le véritable goulot d'étranglement exactement là où il est. Atteindre 97 % sur des documents complexes relève d'une véritable ingénierie. Cela a toujours moins de valeur pour une équipe de crédit que de savoir quel analyste peut signer au-dessus de cinquante mille euros.

Trois choses qu'un dossier partagé ne peut pas faire

Presque toutes les équipes auxquelles nous nous connectons ont construit cette couche elles-mêmes. Une file d'attente, un champ de statut, deux canaux Slack et une feuille de calcul indiquant qui approuve quoi. Ne vous en moquez pas : ça marche. Les dossiers sont tranchés. Les gens rentrent chez eux.

Cela s'effondre sur exactement trois choses, et il se trouve que ce sont les trois choses sur lesquelles un régulateur pose des questions.

Il ne peut pas exprimer l'autorité. Pas "qui peut ouvrir cet écran" mais "qui peut effectuer cette action, sur cet enregistrement, dans cette juridiction, sous cette limite". Les couches faites maison modélisent les permissions au niveau d'une page, car c'est ce qu'un framework web vous offre gratuitement. Puis, au beau milieu d'un audit, quelqu'un se rend compte que l'accès au niveau de la page ne peut pas décrire la règle sur laquelle l'entreprise fonctionne réellement, et la réponse honnête à "qui était autorisé à faire cela ?" s'avère être "toute personne ayant le lien".

Il ne peut pas escalader sans amnésie. Transférer un dossier est facile. Transporter la raison avec lui ne l'est pas : quelle vérification a échoué, de combien, et ce que le dernier réviseur a déjà écarté. Lorsque cela se perd en cours de route, votre spécialiste senior ouvre le fichier à la page un et lit ce qu'un junior a lu hier. Vous avez payé deux fois pour la même lecture, et le deuxième passage était le plus cher.

Il ne peut pas conserver une piste unique à travers les systèmes. L'outil d'extraction a un log. L'outil de gestion de dossiers a un log. Le système bancaire central a un log. Cela fait trois logs, ce qui n'est pas une piste d'audit, c'est un devoir à la maison. Six mois plus tard, quelqu'un les relie à la main, dans une pièce, avec une personne qui ne se montre pas très charitable quant aux lacunes.

La partie qui est véritablement difficile à construire

Chacun de ces éléments représente un sprint. Vous pourriez livrer des permissions au niveau de l'enregistrement ce trimestre si vous faisiez place nette. Maintenir les trois comme un seul modèle, pendant que le métier réécrit ses règles sous vos pieds toutes les quelques semaines, voilà le vrai problème, et c'est la partie qui n'est jamais livrée.

Forest est construit autour de ce problème plutôt qu'autour d'un écran. Les dossiers arrivent dans une boîte de réception avec des règles de distribution et des SLAs. Les workflows intègrent des étapes d'approbation, des chemins d'escalade et des barrières qui s'arrêtent et attendent un humain. Les actions vivent au niveau de l'enregistrement, chacune soumise à des permissions, de sorte qu'un appel à un fournisseur, une étape d'un agent et la décision d'un réviseur atterrissent tous dans la même piste. Il lit et écrit directement dans votre propre base de données, sans couche de copie, ce qui épargne à tout le monde la dispute de 3 heures du matin pour savoir quelle copie fait autorité, et la conversation qui s'ensuit avec un délégué à la protection des données pour expliquer pourquoi il y en a deux.

La partie que nous ne nous attendions pas à aimer autant : il se superpose aux fournisseurs que vous avez déjà choisis plutôt que de les remplacer. Un workflow KYB s'y exécute par-dessus les fournisseurs d'identité et de registres qui sont déjà dans votre stack, et nous sommes un fournisseur de plus à l'intérieur, celui qui lit les documents. C'est une image plus honnête d'une opération réglementée que n'importe quel diagramme bipartite. Pas un pipeline. Un plan de contrôle au-dessus d'une douzaine de fournisseurs, chacun excellent dans un domaine, aucun d'entre eux n'étant capable de voir l'ensemble du dossier.

Cela répond également à l'objection qui tue discrètement la version interne de ce projet. Les équipes n'abandonnent pas le back-office interne parce qu'il ne peut pas être construit. Elles abandonnent parce que c'est un engagement sur plusieurs années qui doit se battre contre la roadmap produit chaque trimestre, et qui perd ce combat. La promesse de Forest est une couche de gouvernance en douze semaines. Disons vingt si vous êtes pessimiste. La comparaison reste des trimestres contre des années, et ce sont les trimestres qui remportent l'argument en interne.

Qui a agi, et en avait-il le droit

Tout le monde intègre des agents dans les opérations maintenant. La question intéressante n'a jamais été de savoir si l'agent est bon, car cela se règle lors d'une démo. La question est de savoir ce qui se passe au moment où il agit.

La réponse habituelle est un compte de service. L'agent n'agit en tant que personne en particulier, avec le périmètre qui a été attribué à l'intégration, et apparaît dans le log comme un événement système. Ce qui est très bien, jusqu'au jour où ça ne l'est plus, et ce jour-là est le seul où quelqu'un lira ce log.

Forest fait passer les personnes et les agents par un seul modèle de permissions. Mêmes rôles, mêmes périmètres, même ligne de log au niveau de l'enregistrement, avec la trace du raisonnement attachée lorsque l'acteur n'était pas une personne. Un agent ne bénéficie d'aucune indulgence sous prétexte d'être un logiciel.

Le mécanisme est la partie qui vaut la peine d'être volée. Un analyste prend un dossier dans la boîte de réception et fait avancer le workflow. Un agent appelle le même workflow via le serveur MCP de Forest. Pas un chemin d'automatisation parallèle, pas un webhook câblé sur le côté : le même objet de workflow, les mêmes barrières, de sorte que le log se lit de la même manière dans les deux cas et la différence entre les deux acteurs est un nom et une trace.

Il absorbe également l'acteur que tout le monde oublie. Un réviseur externalisé dans une équipe BPO est, en termes de gouvernance, exactement le même problème qu'un agent : un acteur compétent qui n'est pas votre employé, travaillant sur vos enregistrements, dont quelqu'un devra un jour énoncer le périmètre à voix haute. Un seul modèle couvre les employés, les agents et les prestataires. L'alternative est d'en maintenir trois, et qu'ils se contredisent.

Là où la couture disparaît

L'article de Forest décrit comment notre côté est construit, voici donc plutôt ce qui en ressort à la fin, ce qui est la partie qui compte au niveau d'une couture.

Pas une valeur. Une valeur, ses coordonnées sur la page, le verdict de chaque règle qui s'est exécutée contre elle, et son historique si un humain l'a touchée. Les règles sont celles que vous avez écrites en anglais courant, compilées en Hololang, notre DSL pour la validation financière. Un relevé dont le solde de clôture présente un écart de plus de deux centimes est signalé, avec la page et le montant nommés, avant que quiconque n'exporte quoi que ce soit.

C'est la partie qui sauve une file d'attente de révision. "Nécessite une révision" n'est pas une raison. Dites à un réviseur que les crédits de la page 12 manquent le solde de clôture de quatre euros et quatre-vingts centimes, et il lira une ligne d'une page au lieu de quarante.

Cela ne survit au transfert que parce que Forest route en fonction de la règle qui a échoué plutôt que d'un statut, et parce que ses actions vivent au niveau de l'enregistrement, de sorte que les coordonnées et l'historique des corrections restent attachés au chiffre au lieu de rester en arrière dans notre système.

Un chiffre dans Holofin remonte jusqu'à un pixel sur la page d'où il provient. Le même chiffre, une fois traité dans Forest, trace en aval qui a décidé quoi, quand, et en vertu de quelle règle. Aucun de nous ne peut produire cette ligne complète seul.

Deux moitiés, une seule ligne

Notre propre discipline est étroite à dessein. La précision avant la vitesse. La provenance sur chaque champ, ou le champ n'est pas livré. Une règle qui échoue est une fonctionnalité, pas un incident. Nous nous connectons, nous ne prenons pas le contrôle, et les données restent les vôtres. En pratique, cela représente plus de 100 000 documents par mois en production, environ 40 secondes chacun, sur plus de 100 types de documents, traités dans l'UE avec la période de rétention définie par vous.

Aucun de nous ne dérive dans la moitié de l'autre, ce qui est la seule raison pour laquelle cela fonctionne. Forest a écrit l'autre moitié de l'argument sur son propre blog : l'OCR est une infrastructure, pas une commodité. Les deux moitiés sont des infrastructures peu glamour, et toutes deux méritent d'être construites correctement, car l'alternative est un très bon chiffre qui reste dans une corbeille pendant deux jours.

Un chiffre qui peut montrer d'où il vient, dans un système qui peut montrer ce qui a été fait à son sujet. Moins que cela, et quelqu'un, tôt ou tard, fera le travail deux fois.