Un périmètre métier, pas une autonomie sans limite
Je conçois des agents IA pour une tâche identifiée : préparer une réponse au support, proposer une mise à jour CRM ou extraire des informations d'un document. L'agent utilise uniquement les sources et les actions autorisées pour cette mission.
Il ne s'agit pas de déployer un agent généraliste libre de naviguer, d'écrire partout et de décider seul. Le périmètre définit les données accessibles, les outils appelables, les actions réversibles et les situations qui exigent une personne.
Un premier échange permet de vérifier si un agent est utile. Une règle métier ou une automatisation classique reste préférable lorsqu'elle suffit.
Trois missions, trois périmètres d'action
Préparation de réponses au support
L'agent rassemble le contexte du ticket, consulte la base de connaissances autorisée et prépare une réponse accompagnée de ses sources.
- Détection des informations manquantes
- Proposition de réponse ou de demande de précision
- Transmission à un opérateur avant envoi
Mise à jour CRM contrôlée
À partir de messages ou de documents reçus, l'agent prépare les champs à modifier et signale les contradictions avec la fiche existante.
- Lecture limitée aux objets CRM nécessaires
- Validation des champs et des valeurs proposées
- Enregistrement de la valeur avant et après modification
Traitement documentaire supervisé
L'agent classe un document, extrait les données attendues et applique des contrôles définis avec vos équipes.
- Extraction de champs avec référence au document source
- Détection des pièces ou informations absentes
- Revue humaine des anomalies et des cas non prévus
Des outils accessibles, des droits séparés
Outils connectés selon leurs interfaces
- Support Tickets et base de connaissances
- CRM Contacts, entreprises et opportunités
- Documents Espaces de stockage et dossiers autorisés
- Métier API internes et logiciels exposant une interface
Permissions au plus juste
- Compte de service dédié à l'agent
- Droits de lecture et d'écriture distincts
- Liste fermée d'outils, de dossiers et d'actions
- Contrôles côté serveur, hors du prompt
Validations humaines ciblées
- Approbation avant un envoi ou une écriture sensible
- Revue obligatoire en cas de règle ambiguë
- Modification ou rejet de la proposition par l'opérateur
- Responsable métier identifié pour chaque processus
Arrêt et confinement
- Interruption de la file d'exécution
- Révocation des accès de l'agent
- Limite d'étapes, de durée et de tentatives
- Sortie vers une file de revue en cas d'échec
Évaluer avant d'autoriser davantage
Constituer les cas de référence
Nous réunissons des exemples représentatifs, les résultats attendus, les cas limites et les actions interdites.
Mesurer les exécutions
Les contrôles vérifient les champs produits, les sources utilisées, le respect des permissions et le déclenchement des validations.
Suivre le taux d'échec
Le taux d'échec est le nombre d'exécutions non conformes divisé par le total, sur un périmètre et une période définis. Les causes sont distinguées : extraction fausse, source absente, outil indisponible, boucle ou refus de validation.
Élargir par étapes
Les droits et les volumes n'augmentent qu'après revue des résultats sur le périmètre déjà autorisé.
Journaux et coûts visibles
Comprendre chaque exécution
Le journal associe la demande, les sources consultées, les appels d'outils, la proposition, la décision humaine et les versions du prompt et du modèle.
Les règles de conservation et d'accès sont définies au cadrage. Les secrets et les données personnelles non nécessaires ne sont pas ajoutés aux traces.
Suivre le coût par exécution
Le suivi distingue les appels au modèle, les éventuels services d'OCR ou de recherche, l'infrastructure, les nouvelles tentatives et le temps de revue humaine.
Le coût est observé par type de tâche, y compris sur les exécutions échouées, plutôt que présenté comme une moyenne universelle.
Prévoir la maintenance
Les connecteurs, les droits, les modèles et les documents sources évoluent. La maintenance couvre leurs changements, l'actualisation des cas d'évaluation et l'analyse des erreurs.
Le périmètre initial et les modalités de suivi sont définis avant le devis, sans supposer un coût identique pour tous les processus.
Démonstrateur et cas client ne se confondent pas
Exemple de démonstrateur
Un scénario de support utilise des tickets fictifs et une base de connaissances de test. L'agent prépare une réponse, cite les passages utilisés et laisse l'opérateur valider, corriger ou rejeter.
Données de test, environnement isolé, aucune promesse de résultat en productionCas client
Aucun résultat client n'est revendiqué sur cette page. Un cas documenté doit préciser le contexte, le périmètre, la méthode de mesure, la période observée et les limites du résultat.
Aucun chiffre publié sans données vérifiablesQuel processus voulez-vous encadrer ?
Décrivez la tâche, les outils concernés et les validations déjà en place. Nous vérifierons le périmètre avant de parler de développement.