Aller au contenu principal
FromNine
Menu

IA et données

Agents IA et automatisation des processus, dans les limites que vous fixez

Nous automatisons les tâches en plusieurs étapes avec des agents et des workflows qui utilisent des outils aux droits restreints, s’arrêtent pour validation avant toute action engageante et laissent une trace que vos auditeurs peuvent rejouer.

Pour les centres de services partagés et les directions des opérations qui veulent automatiser sans perdre la main sur les décisions qui engagent.

Échanger sur votre projetDécouvrir notre approche
Agents IA et automatisation : les couches de la solutionQuatre couches superposées en profondeur. De haut en bas : le workflow qui conserve l’état, les étapes d’agent qu’il contient, la passerelle d’outils et ses droits, puis le point de validation avant que les actions n’atteignent vos systèmes.01Workflow et état02Étapes d’agent03Passerelle d’outils et droits04Validation, puis action
  1. 01Le bon degré d’autonomie pour chaque étape, du workflow figé à l’agent supervisé
  2. 02Des outils au moindre privilège derrière une passerelle, avec des limites par action
  3. 03Chaque étape, appel d’outil et validation journalisés, rejouables et exportables

01 Enjeux

Pourquoi les programmes d’automatisation marquent le pas

  1. 01

    Personne ne sait dire ce que l’agent a le droit de faire

    Il tourne sous un compte de service aux droits étendus. Les équipes risques et sécurité refusent de valider, et elles ne devraient pas avoir à deviner.

  2. 02

    Le taux d’automatisation est flatteur, les exceptions s’accumulent

    Les cas simples passent. Les autres atterrissent sans contexte dans une boîte partagée, et l’équipe qui les traite est désormais plus chargée qu’avant.

  3. 03

    En cas d’erreur, personne ne peut reconstituer ce qui s’est passé

    Aucune trace des données consultées par l’agent, de l’outil appelé ni de la personne qui a validé l’étape. L’audit interne pose la question, et il n’y a pas de réponse.

  4. 04

    Les robots cassent dès qu’un écran change

    Des robots qui lisent les écrans assurent des tâches critiques. Chaque mise à jour d’application coûte un week-end de réparations.

02 Prestations

Ce que nous livrons

  1. 01 Un niveau d’autonomie défini étape par étape

    Pour chaque étape, nous retenons la solution la plus simple qui fonctionne : un workflow déterministe, un appel unique à un modèle, un agent qui utilise des outils ou une orchestration en plusieurs étapes. Parfois, la réponse honnête est qu’un agent n’est pas le bon outil.

    Ce que nous faisons

    • Analyse du processus avec les personnes qui l’exécutent
    • Décision d’autonomie étape par étape, avec le risque associé à chacune
    • Modélisation du flux en machine à états ou en BPMN
    • Critères pour accorder plus ou moins d’autonomie à une étape

    Ce que vous recevez

    • Cartographie de l’autonomie du processus
    • Modèle de workflow sous gestion de versions
    • Dossier de décision pour chaque étape d’agent

  2. 02 Droits des outils et moindre privilège

    Les agents appellent des outils, jamais directement les systèmes. Une passerelle d’outils applique les périmètres, les listes d’autorisation et les plafonds de transaction, et chaque outil s’exécute sous sa propre identité de service.

    Ce que nous faisons

    • Catalogue d’outils séparant lecture et écriture
    • Identités de service à périmètre restreint pour chaque outil
    • Plafonds de transaction et de débit par type d’action
    • Exécution isolée (sandbox) pour le code et le traitement de fichiers

    Ce que vous recevez

    • Passerelle d’outils avec politique paramétrable
    • Matrice des droits approuvée par la sécurité
    • Suite de tests de l’application des règles

  3. 03 Conception avec l’humain dans la boucle

    Seuils de validation, aiguillage selon le niveau de confiance et principe des quatre yeux pour les actions engageantes. Les décisions qui concernent des personnes gardent une personne dans la boucle, conformément à l’article 22 du RGPD et au droit à une intervention humaine.

    Ce que nous faisons

    • Classification des actions selon leurs conséquences
    • Seuils de validation et règles d’escalade
    • Interface de validation qui fournit le contexte nécessaire pour décider
    • Garanties pour les décisions concernant des individus

    Ce que vous recevez

    • Politique de validation par type d’action
    • Circuit de validation dans les outils que vos équipes utilisent déjà
    • Schéma d’escalade avec équipes désignées

  4. 04 Traçabilité et audit

    Un enregistrement complet des entrées, du contexte retrouvé, des sorties du modèle, des appels d’outils et des validations, pour que chaque exécution puisse être rejouée et exportée pour l’audit interne ou une autorité de contrôle.

    Ce que nous faisons

    • Conception du journal d’événements et des règles de conservation
    • Rejeu des exécutions sur des entrées figées
    • Formats d’export d’audit convenus avec l’audit interne
    • Tableaux de bord des taux d’exception et de validation

    Ce que vous recevez

    • Stockage de la piste d’audit
    • Outillage de rejeu
    • Tableaux de bord opérationnels

  5. 05 Gestion des défaillances

    Les agents échoueront parfois. Nous les concevons pour que l’échec reste sans danger : actions idempotentes, compensation et retour arrière, délais d’expiration, escalade vers une équipe désignée et un coupe-circuit qu’une personne est habilitée à actionner.

    Ce que nous faisons

    • Clés d’idempotence sur chaque action d’écriture
    • Étapes de compensation pour les modifications multi-systèmes
    • Délais d’expiration et budgets de nouvelles tentatives
    • Coupe-circuit par agent et par outil

    Ce que vous recevez

    • Analyse des modes de défaillance
    • Procédure d’exploitation incluant l’activation du coupe-circuit
    • Tests de chaos sur les chemins critiques

  6. 06 Des agents aux côtés de l’automatisation existante

    Le process mining montre le flux tel qu’il se déroule réellement. La RPA reste là où seul un écran existe et cède la place aux API dès qu’elles sont disponibles. Nous mesurons le taux d’exception, pas seulement le taux d’automatisation.

    Ce que nous faisons

    • Process mining sur les journaux d’événements
    • Inventaire des robots existants et de leur historique de pannes
    • Alternatives par API à l’automatisation fragile des écrans
    • Analyse des exceptions par cause

    Ce que vous recevez

    • Analyse du flux actuel
    • Plan de migration des écrans vers les API
    • Situation de référence et objectif pour le temps de traitement des exceptions

03 Architecture

Une architecture de référence illustrative

L’orchestrateur détient l’état du travail. Les étapes d’agent s’y insèrent et ne peuvent atteindre vos systèmes qu’à travers la passerelle d’outils, qui contrôle le périmètre et les limites à chaque appel. Les outils de lecture passent ; les outils d’écriture s’arrêtent à un point de validation lorsque l’action est engageante.

Tout laisse une trace dans la piste d’audit. Un coupe-circuit et des délais d’expiration encadrent l’orchestrateur, et les exceptions sont transmises à une équipe désignée avec le contexte complet de l’exécution.

Couches du schéma

Réception
Un nouveau dossier, message ou événement démarre une exécution avec un identifiant de corrélation.
Orchestration
État du workflow, étapes d’agent, compensation et coupe-circuit.
Périmètre d’autorisation
Passerelle d’outils, outils de lecture, point de validation et outils d’écriture.
Systèmes
CRM, ERP et gestion des dossiers, accessibles uniquement par des outils.
Traçabilité
La piste d’audit et l’équipe qui traite les escalades.
Exemple illustratif

  1. Réception

    • Déclencheur : dossier, message, événement

  2. Orchestration

    • Orchestrateur et état
    • Étape d’agent
    • Coupe-circuit et délais d’expiration
    • Compensation et retour arrière

  3. Périmètre d’autorisation

    • Passerelle d’outils
    • Outils de lecture
    • Point de validation
    • Outils d’écriture

  4. Systèmes

    • CRM, ERP, gestion des dossiers

  5. Traçabilité

    • Piste d’audit : chaque étape, appel et validation, avec rejeu et export
    • Équipe désignée pour les exceptions
Un agent à l’intérieur d’un périmètre d’autorisation

Architecture illustrative, pas un système client.

Lire le schéma sous forme de texte

Le parcours principal part d’un déclencheur, passe par l’orchestrateur et une étape d’agent jusqu’à la passerelle d’outils, puis par un point de validation où une personne décide, ensuite par un outil d’écriture, et aboutit aux applications métier.

La passerelle autorise aussi des outils de lecture qui interrogent directement les applications métier. Un coupe-circuit pilote l’orchestrateur, des étapes de compensation peuvent annuler les actions de l’agent, et l’orchestrateur transmet les cas à une équipe désignée.

Les validations et les actions d’écriture sont enregistrées dans une piste d’audit qui permet le rejeu et l’export. La passerelle, les outils de lecture, le point de validation et les outils d’écriture forment ensemble le périmètre d’autorisation.

04 Points d’attention et limites

Choix d’ingénierie et limites

  • L’autonomie se gagne étape par étape

    Notre méthode

    Les étapes démarrent sous supervision. Nous n’élargissons l’autonomie que lorsque les journaux montrent que l’étape reste dans les limites convenues sur un volume de dossiers significatif.

    Limites et dépendances

    Certaines étapes ne devraient jamais être autonomes, quels que soient les chiffres. C’est une décision métier, et nous vous demanderons de la prendre explicitement.

  • Un agent n’est pas plus sûr que ses outils

    Notre méthode

    Les outils d’écriture sont étroits et paramétrés : « créer un avoir jusqu’à un plafond », jamais « appeler l’ERP ».

    Limites et dépendances

    Lorsqu’un système n’offre pas de modèle d’autorisation fin, nous compensons dans la passerelle. Cela représente du travail supplémentaire, et certains systèmes ne peuvent pas être suffisamment sécurisés pour un accès en écriture.

    Les résultats de l’IA peuvent être erronés. C’est pourquoi les actions engageantes attendent la validation d’une personne, et les cas incertains sont orientés vers une équipe plutôt que tranchés à l’aveugle.

  • L’injection de prompt est un risque opérationnel

    Notre méthode

    Les contenus issus d’e-mails, de documents et de pages web sont traités comme non fiables. Ils ne peuvent ni modifier les instructions de l’agent ni élargir ses droits, et des tests de red teaming le vérifient.

    Limites et dépendances

    Aucune mesure n’élimine complètement le risque. La conception part du principe qu’une tentative réussira un jour et limite ce qu’elle peut atteindre.

  • Les exceptions font partie du produit

    Notre méthode

    Chaque exception arrive avec le contexte de l’exécution, un motif et une proposition de suite à donner, dans la file d’une équipe qui en est responsable.

    Limites et dépendances

    Sans responsable de la file d’exceptions, l’automatisation déplace le travail au lieu de le supprimer. Nous ne passons pas en production sans responsable désigné.

05 Notre façon de travailler

Notre façon de travailler

Nous partons du processus tel qu’il se déroule, pas tel qu’il est dessiné, et l’autonomie se gagne étape par étape.

  1. 01

    Voir le flux réel

    Le process mining et l’observation sur le terrain révèlent les volumes, les variantes et les pertes de temps.

    LivrableAnalyse du flux actuel

  2. 02

    Décider l’autonomie étape par étape

    Workflow, appel à un modèle ou agent, avec pour chaque étape les conséquences d’une mauvaise action consignées par écrit.

    LivrableCartographie de l’autonomie et matrice des droits

  3. 03

    Fonctionner en mode fantôme

    Le système propose, les personnes agissent. Nous comparons ses propositions à leurs décisions sur des dossiers réels.

    LivrableRapport d’exécution en mode fantôme

  4. 04

    Passer en production avec validations

    Les actions engageantes attendent une validation ; les seuils sont revus sur la base de preuves, pas d’impressions.

    LivrablePolitique de validation et tableaux de bord

06 Contrôle humain

Là où l’humain garde la main

Les agents agissent dans les limites des droits que vous définissez, demandent une validation avant toute action engageante et journalisent chaque étape.

  • Validation avant conséquence

    Les paiements, les décisions concernant des personnes et les modifications de données de référence attendent une personne, avec le contexte nécessaire pour décider rapidement.

  • Quatre yeux là où cela compte

    Au-delà de seuils convenus, deux personnes valident. Le seuil est un paramètre réglé par votre responsable des risques, pas une valeur codée en dur.

  • Un coupe-circuit qu’une personne peut actionner

    Chaque agent et chaque outil peut être arrêté par le titulaire d’un rôle désigné, sans redéploiement, et la procédure fait l’objet d’exercices réguliers.

  • Revue humaine des décisions concernant des personnes

    Lorsqu’un résultat touche un individu, une personne l’examine et l’individu peut demander cet examen.

  • Escalade vers une équipe désignée

    Les exécutions incertaines ou en échec vont à une équipe qui en est responsable, jamais à une boîte de réception que personne ne consulte.

07 Exemple

Un exemple illustratif

Exemple illustratif

Litiges fournisseurs après la réforme de la facturation électronique

01Situation
Depuis que les factures arrivent via une plateforme agréée, le centre de services comptables d’une ETI reçoit des statuts de rejet et de litige structurés, mais les traite encore à la main dans l’ERP.
02Ce que nous construirions
Un agent qui lit chaque statut, rassemble commande, bon de réception et échanges, propose une réponse au fournisseur et prépare l’écriture correspondante dans l’ERP.
03Là où l’humain décide
Un comptable valide chaque réponse et chaque avoir ; l’agent ne peut ni modifier des coordonnées bancaires ni déclencher un paiement.
04Ce que nous mesurerions
Délai de traitement d’un litige, part des propositions acceptées sans modification, retards de paiement évités.

08 Regard sectoriel

Dans votre secteur

  • Services financiers

    Sinistres, entrée en relation et exceptions de paiement traités par des agents avec plafonds de transaction, double validation et exports d’audit dans un format convenu avec votre fonction d’audit.

  • Secteur public et administrations

    Une instruction des dossiers où l’agent rassemble et rédige, et où l’agent public décide, chaque étape étant enregistrée pour les procédures de réexamen et de recours.

  • Industrie manufacturière

    Modifications de commandes, relances fournisseurs et demandes de service entre l’ERP et la messagerie, avec des validations aux points qui engagent des budgets ou des capacités.

France

Automatiser sous le regard de la CNIL et du CSE

En France, automatiser un processus qui touche des salariés ou des clients engage plusieurs interlocuteurs : la CNIL et le RGPD pour les décisions automatisées, le règlement européen sur l’IA (AI Act) pour le contrôle humain, et le comité social et économique dès qu’un outil modifie les conditions de travail.

Nous concevons des agents dont les seuils de validation, les journaux et les voies d’escalade sont documentés en français et présentables à chacun. La réforme de la facturation électronique offre un premier terrain concret : rapprochements, relances et litiges fournisseurs.

Questions sur les agents IA et l’automatisation

Comment choisissez-vous entre un agent et un workflow classique ?

Si les étapes sont connues et les entrées structurées, un workflow est moins coûteux, plus rapide et plus facile à auditer. Un agent se justifie lorsque les entrées varient, que le parcours dépend de ce qui est trouvé et qu’une personne peut vérifier le résultat. La plupart des systèmes en production combinent les deux.

Qu’est-ce qui empêche un agent de faire ce qu’il ne devrait pas ?

Il ne peut agir qu’au moyen d’outils, chaque outil s’exécute sous sa propre identité à périmètre restreint, et la passerelle applique des limites à chaque appel. Les actions d’écriture engageantes s’arrêtent pour validation. Un contenu non fiable ne peut pas modifier ces règles.

Nous utilisons déjà la RPA. Faut-il l’abandonner ?

Non. Les robots qui travaillent sur les écrans des systèmes hérités continuent de fonctionner là où aucune API n’existe. Nous ajoutons des agents pour les étapes qui demandent du discernement, utilisons le process mining pour repérer les robots fragiles et les remplaçons par des intégrations API à mesure que les systèmes sous-jacents le permettent.

Comment mesurez-vous la réussite ?

Par le délai de traitement, le taux d’exception, les reprises et le temps que les équipes consacrent aux exceptions, par rapport à une situation de référence établie avant la mise en production. Le taux d’automatisation seul masque trop de choses.

L’audit interne ou une autorité de contrôle peuvent-ils examiner ce qui s’est passé ?

Oui. Chaque exécution peut être rejouée à partir de son journal : entrées, contexte retrouvé, sorties du modèle, appels d’outils et validations. Les formats d’export sont convenus avec votre fonction d’audit avant la mise en production.

Choisissez un processus, nous cartographions les décisions

Nous identifions avec vos équipes ce qu’un agent peut faire seul, ce qui exige une validation, et ce que le CSE et le DPO doivent voir avant le déploiement.

Échanger sur votre projetDécouvrir notre approche