# Workflows IA, traitement documentaire et RAG | tracee > Conception et intégration du traitement documentaire, de la recherche documentaire sourcée, du tri des demandes et de la revue assistée, pannes comprises. Source: https://traceegroup.com/fr/ia/workflows --- # L'IA dans le workflow, pas à côté. Nous concevons et intégrons des briques d'IA dans les processus où le travail se fait déjà : documents lus et vérifiés, connaissances retrouvées avec leurs sources, demandes triées, et chaque résultat qui compte relu par une personne qui voit pourquoi il a été proposé. ## Cinq briques, définies précisément. 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. ## Un processus, chaque étape écrite. 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. **Lire le schéma sous forme de texte** - Réception : chaque document reçu par e-mail, dépôt ou portail obtient un identifiant, une empreinte de contenu et un horodatage. - 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. - 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. - 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. - 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. - 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. - 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. ## Conçu pour le jour où ça se passe mal. 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. - Panne - Détection - Ce qui se passe - Document en double - Même empreinte de contenu, ou mêmes fournisseur, numéro, montant et date. - Mis en attente et rattaché à l'original. Une personne confirme ; rien n'est supprimé automatiquement. - Pièce manquante - Règle de pièce obligatoire, par exemple un bon de commande au-delà d'un seuil. - Dossier classé incomplet, expéditeur prévenu par un message type, relance programmée. - Extraction peu fiable - Confiance par champ sous le seuil, ou contrôle de cohérence en échec. - Champ surligné pour la revue, avec le motif. Jamais accepté en silence. Taux suivi par mise en page. - Délai dépassé sur une API - Délai ou code d'erreur du service de modèle ou du logiciel métier. - Nouvelle tentative espacée avec la même clé d'idempotence, puis mise en file visible par l'exploitation. Aucun export partiel. - Correction humaine - La personne modifie une valeur ou inverse la décision proposée. - Conservée avec motif, utilisateur et heure. Alimente le jeu d'évaluation. Taux de correction suivi comme signal d'alerte. - Reprise ou rejeu - Action d'un opérateur ou tâche planifiée après un incident. - Reprise depuis la dernière étape validée avec les mêmes versions de composants, ou avec de nouvelles versions journalisées comme telles. ## Là où l'IA est le mauvais outil. 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. ## Ce qu'une mission workflow livre. ### Spécification du workflow Chaque étape, ses règles, où le modèle intervient et où il n'intervient pas, et les points de revue. ### Conception de l'intégration Comment le workflow lit et écrit dans vos systèmes existants, avec idempotence et contrats d'erreur. ### Prototype Construit selon la spécification sur des données synthétiques ou un échantillon validé, jamais par défaut sur des données de production. ### Jeu d'évaluation et plan de test Cas annotés, critères d'acceptation et scénarios de panne ci-dessus, scénarisés. ### Procédure d'exploitation Exceptions, reprises, corrections humaines et retour arrière, écrits pour l'équipe qui exploitera. ## Un workflow en tête ? Décrivez les documents ou demandes concernés et leur traitement actuel. Nous vous dirons quelles parties un modèle devrait toucher, et lesquelles il ne devrait pas toucher.