L'IA dans le workflow, pas à côté.

Des termes flous font des projets flous. Voici les cinq briques avec lesquelles nous concevons, et ce que chacune fait réellement.

Traitement documentaire

Trois opérations distinctes, souvent regroupées sous un même nom. L'OCR transforme l'image d'une page en texte. L'extraction associe ce texte à des champs nommés : fournisseur, date, montant, clause. Le contrôle de cohérence confronte les champs entre eux et à des données de référence : les lignes font le total, le fournisseur existe, la date tombe dans une période ouverte. Le modèle fait la deuxième ; un code ordinaire doit faire la troisième.

Recherche documentaire

La génération augmentée par récupération (RAG) cherche dans un ensemble de documents choisis et soumis aux droits d'accès, puis ne transmet au modèle que les passages trouvés, pour que la réponse puisse les citer. Sa qualité dépend du corpus avant le modèle : doublons, versions périmées et documents sans responsable produisent des réponses fausses énoncées avec assurance.

Tri des demandes

Classer les demandes entrantes par type, urgence et compétence requise, puis les orienter. Le plus souvent des règles et un classifieur ; un modèle de langage aide quand les demandes arrivent en texte libre, dans plusieurs langues.

Orchestration du workflow

La couche qui enchaîne les étapes, appelle les systèmes, reprend sans risque et conserve l'état. Ce doit être un logiciel ordinaire et déterministe. Un agent, au sens précis, est un modèle autorisé à choisir l'outil qu'il appelle ensuite. Nous accordons cette liberté avec parcimonie, dans des permissions bornées, et seulement quand le chemin ne peut vraiment pas être spécifié à l'avance.

Revue assistée

L'écran où une personne voit ce que le système propose, les éléments sur lesquels il s'appuie et son degré d'incertitude, puis approuve, corrige ou rejette. Les corrections sont conservées et deviennent des cas de test. C'est là que l'essentiel de l'effort de conception doit porter, car c'est là que la confiance se gagne ou se perd.

La réception de factures est une bonne référence, car presque toutes les organisations en ont une. La même structure vaut pour des contrats, des sinistres ou des dossiers d'entrée en relation. Il s'agit d'une conception illustrative ; nous ne prétendons pas qu'elle soit déployée chez un client.

Workflows · Processus de référence

Réception de factures, entièrement spécifiée.

Faites défiler le schéma latéralement pour le voir en entier.

Système de référence Étape de traitement ou service Canal, fournisseur ou tiers Couche regroupée Instruction ou données sortantes Résultat ou décision en retour Enregistrements vers le journal

Lire le schéma sous forme de texte

1. Réception : chaque document reçu par e-mail, dépôt ou portail obtient un identifiant, une empreinte de contenu et un horodatage.
2. Règles de validation : type et lisibilité du fichier, détection des doublons par empreinte et par champs clés, présence des pièces obligatoires. Les échecs vont dans la file d'exceptions.
3. Les mises en page connues sont lues par des règles de gabarit, sans modèle. Les mises en page inconnues vont à l'extraction par IA, qui doit rendre un schéma fixe.
4. Contrôles de cohérence : les totaux se recoupent, les dates sont plausibles, le fournisseur existe dans le référentiel, la confiance par champ dépasse le seuil. Tout échec devient une alerte motivée.
5. Validation humaine : la personne voit le document à côté des champs extraits, doutes surlignés, et approuve, corrige ou rejette. Des seuils par montant fixent ce qui doit être revu.
6. Export vers la comptabilité ou l'ERP par son API ou un fichier d'import validé, avec une clé d'idempotence pour qu'une reprise ne comptabilise jamais deux fois.
7. Le journal de preuves conserve l'empreinte, les versions du modèle et du prompt, les valeurs extraites, les contrôles, la décision de revue et l'identifiant d'export.

Remarquez où le modèle n'est pas. Il ne décide ni si un document est un doublon, ni si les totaux se recoupent, ni si une facture peut être payée. Il lit les mises en page que les règles ne savent pas lire, et son résultat est vérifié avant que quiconque s'y fie.

Un pilote se juge sur le cas nominal. L'exploitation se juge sur tout le reste. Chaque panne ci-dessous a une détection et une réponse définies avant la mise en service.

Dire où ne pas utiliser de modèle fait partie du métier. Dans ces cas, un logiciel ordinaire est moins cher, plus fiable, ou les deux.

• Calculs et totaux. Un modèle peut lire les chiffres. Le code doit les additionner.
• Règles stables à portée juridique ou financière. Taux de TVA, plafonds d'approbation, seuils d'éligibilité. Codez-les ; ne demandez pas à un modèle de s'en souvenir.
• Recherches exactes. « Quel est le solde de ce compte » relève d'une requête en base, pas d'une recherche documentaire.
• Tâches à faible volume. Si cela arrive douze fois par an, une liste de contrôle vaut mieux qu'une chaîne de traitement.
• Résultats que personne ne peut vérifier. Sans vérité de référence ni relecteur, impossible de savoir si le système fonctionne.
• Décisions aux effets importants sur une personne, prises sans revue humaine réelle. Elles exigent une autre conception et, d'abord, une analyse juridique.