
Agent IA
Nous concevons des processus automatisés qui répartissent clairement les rôles entre l’application, les tâches confiées à l’IA et les personnes habilitées.
Avant d’automatiser, nous identifions les participants, les sources de données, les points de blocage, les exceptions, les pannes possibles et le résultat attendu. Si une tâche obéit à une règle précise, la logique applicative peut être plus simple, plus rapide et plus prévisible que l’IA.
| Intervenant | Exemple de responsabilité | |---|---| | Application | identité, autorisations, validation, calculs, état du processus et actions autorisées | | IA | classements suggérés, valeurs extraites à vérifier, résumés, brouillons | | Personne habilitée | examiner les exceptions, corriger et assumer les décisions nécessitant une approbation |
Cette répartition dépend des données, des conséquences d’une erreur et des exigences métier ; elle n’est pas universelle. Une proposition ne modifie pas les données de référence du dossier.
Imaginons un service d’assistance : l’application enregistre et attribue une demande client selon ses règles. L’IA prépare un résumé et un brouillon de réponse, qu’un salarié compare à l’original et corrige si nécessaire.
Pour une facture, l’IA pourrait proposer les champs lus dans le document. L’application contrôle les formats, les montants, les règles métier et les doublons éventuels. Une personne habilitée vérifie les données dans le circuit d’approbation existant.
Autres usages possibles : organiser les demandes commerciales avant une mise à jour du CRM ou préparer une liste d’accueil pour un nouveau salarié à partir d’informations approuvées. Dans ces exemples, l’IA n’accorde pas seule des accès, n’approuve pas de paiements et ne prend pas de décisions engageantes.
Application : enregistrer la demande et vérifier les accès
|
+-- IA : proposition -> validation par l’application
|
+-- valide -> examen / correction par un salarié
| -> enregistrement après validation
| de la proposition et de la décision
|
+-- invalide / indisponible -> parcours d’exception prévu
(p. ex. traitement manuel)
Action ultérieure, comme envoyer une réponse :
proposition approuvée + autorisations + règles métier
-> exécution par l’application existanteL’application valide aussi les corrections. Enregistrer la proposition et la décision n’envoie pas la réponse ; une proposition rejetée n’est pas appliquée.
Le document ou la demande d’origine, la proposition de l’IA et le résultat vérifié ou approuvé restent distincts. Le statut distingue attente, achèvement et échec. Une file permet d’exécuter les tâches longues en arrière-plan sans bloquer l’envoi de la demande, mais ne garantit pas leur fiabilité.
Un délai dépassé, un fournisseur indisponible ou une sortie invalide constitue un échec. Les nouvelles tentatives sont limitées et réservées aux erreurs temporaires.
L’idempotence consiste à pouvoir répéter une opération sans en doubler les effets. Le numéro de dossier ne suffit pas : une clé d’opération, par exemple dossier, tâche et version des données, doit être associée à une trace durable d’exécution. Une contrainte d’unicité en base et une écriture indivisible empêchent deux tentatives simultanées de créer des enregistrements d’exécution en double. Elles ne garantissent pas un appel unique au fournisseur ; son traitement des doublons doit être vérifié séparément.
Le parcours manuel doit être conçu et testé pour ce processus : ce qui peut être terminé sans IA et ce qui doit attendre.
L’IA reçoit seulement les données nécessaires. L’application fait respecter les droits des utilisateurs et les limites d’accès entre organisations, valide les résultats et conserve une trace des décisions importantes. Un score de confiance élevé ne prouve ni la justesse des données ni l’autorisation d’agir. L’examen humain complète ces protections sans les remplacer.
Chez GiSoft, nous commençons sur un périmètre limité. Nous mesurons le temps de traitement, les corrections, les propositions acceptées, les erreurs et le coût par dossier terminé. La comparaison avec le fonctionnement antérieur guide le choix d’étendre l’automatisation, d’adapter les règles ou d’abandonner l’étape confiée à l’IA.