Agent IA
Du processus métier à un agent IA opérationnel avec contraintes claires.
GiSoft ne commence pas un projet d’agent d’IA en demandant quel modèle doit être connecté. Cette décision compte, mais elle vient plus tard. La première question est opérationnelle : quel travail réel doit devenir plus simple, plus rapide ou plus fiable pour les personnes qui exécutent déjà le processus ?
Nous analysons la manière dont la tâche est réalisée aujourd’hui : ce qui déclenche le processus, qui participe, quelles informations sont utilisées, où les équipes passent du temps, où le travail se répète, où les erreurs apparaissent et quelles décisions exigent de l’expérience. Nous définissons aussi les actions qui doivent rester sous contrôle humain et le résultat qui prouvera que le projet est utile.
Un exemple courant : un client envoie une longue demande technique. Un collaborateur lit le message, identifie le sujet, vérifie l’historique du client, choisit le service responsable, prépare une réponse et met à jour le CRM. L’objectif n’est pas simplement de « créer un chatbot ». Un meilleur objectif peut être de réduire le temps nécessaire pour comprendre et orienter une nouvelle demande, tout en laissant la classification finale au collaborateur.
La première version de production doit avoir une responsabilité limitée et compréhensible. De bons points de départ sont : préparer le résumé d’une demande, suggérer une catégorie, extraire des champs d’un document, rechercher dans une documentation approuvée, préparer un brouillon de réponse, comparer une demande avec une procédure interne, proposer l’étape administrative suivante ou signaler les informations manquantes.
« L’agent doit gérer tout le processus de l’entreprise » est trop large pour un premier déploiement sûr. Un périmètre étroit est plus facile à tester, à relire, à introduire progressivement, à mesurer et à améliorer.
Les limites font partie de la conception, elles ne sont pas une couche de sécurité ajoutée à la fin. Pour une demande client, l’agent peut lire le contenu approuvé, préparer un résumé, suggérer une catégorie et préparer un brouillon de réponse. Il ne peut pas modifier les droits d’un client, approuver un remboursement, modifier une facture, supprimer des enregistrements, envoyer la réponse finale sans validation ni accéder à des données client sans rapport avec la tâche.
┌──────────────────────────────────────────┐
│ Processus métier actuel │
│ │
│ Personnes • Documents • Systèmes • Décis.│
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Analyse du processus │
│ │
│ Temps • Répétition • Erreurs • Risques │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Une responsabilité d’IA clairement définie│
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Résultat attendu mesurable │
└──────────────────────────────────────────┘Dans le processus actuel, le client envoie une demande, le collaborateur lit tout le message, vérifie le sujet, attribue une catégorie, décide de la priorité, choisit une équipe et prépare une réponse.
Avec un agent, l’application existante enregistre toujours la demande normalement. L’agent prépare un résumé, suggère une catégorie et une priorité, trouve les informations internes liées et prépare un brouillon de réponse. Le collaborateur vérifie la suggestion, l’accepte, la modifie ou la rejette, puis l’application continue le processus normal.
Par exemple, une entreprise demande de l’aide pour moderniser un ancien CRM Symfony et l’intégrer avec un nouveau système de commandes. L’agent peut proposer :
Le collaborateur reçoit un point de départ préparé, pas une décision finale automatique.
Dans un processus manuel, un collaborateur reçoit un document fournisseur, ouvre le PDF, cherche le numéro de facture, copie les dates et montants, les saisit dans le système et vérifie les totaux.
Avec un agent, le collaborateur dépose le document dans l’application existante. L’agent lit le document et propose le numéro de facture, le fournisseur, la date d’émission, la date de paiement, le montant net, la taxe, le montant brut et la devise. L’application valide les formats, affiche les valeurs proposées dans le formulaire existant et le collaborateur confirme ou corrige. Le processus d’enregistrement reste inchangé.
Les scores de confiance ne remplacent pas la validation. L’application vérifie toujours si le fournisseur existe, si la facture est un doublon, si les montants sont valides, si les totaux de taxe correspondent, si le collaborateur a les droits nécessaires et si les champs obligatoires sont complets.
De nombreuses organisations disposent de procédures, d’instructions techniques, de documentation produit, de supports d’onboarding, de contrats de service et de politiques internes. Un agent de connaissances peut aider à utiliser ces informations sans contourner les droits d’accès.
Le collaborateur pose une question, l’application vérifie ses droits, l’agent recherche uniquement dans les documents approuvés, prépare une réponse avec des références et le collaborateur ouvre la source pour vérifier l’information.
Si la question est de savoir quelles informations collecter avant d’estimer une mise à niveau Symfony, la réponse peut mentionner la version PHP, la version Symfony, les dépendances, la couverture de tests, la taille de la base de données, les intégrations externes, la méthode de déploiement et les zones critiques pour le métier. Si les sources approuvées ne contiennent pas la réponse, l’agent doit le dire clairement. Il ne doit pas inventer des procédures d’entreprise.
L’agent doit recevoir uniquement les données nécessaires à sa tâche. Une entité complète, un enregistrement complet de base de données ou un historique client sans rapport ne doit pas être envoyé automatiquement à un fournisseur d’IA externe.
Application existante
│
│ Informations sélectionnées uniquement
▼
Préparation de l’entrée
│
├── supprimer les données inutiles
├── vérifier les droits
└── définir le résultat attendu
│
▼
Agent d’IA
│
│ Suggestion structurée
▼
Validation
│
├── champs obligatoires
├── valeurs autorisées
├── règles métier
└── contrôles de sécurité
│
▼
Validation humaine ou règle existante
│
▼
L’application stocke le résultat approuvéAvant l’implémentation, nous définissons ce que l’agent doit produire. Au lieu de demander « analyse cette demande et dis-nous ce que tu en penses », nous définissons une structure métier : résumé, catégorie, priorité, équipe suggérée, informations manquantes, prochaine étape et confiance.
Une structure claire rend le résultat plus facile à valider, afficher, comparer, tester et enregistrer dans l’historique d’audit.
Tous les résultats ne doivent pas être appliqués automatiquement. L’assistance à faible risque, comme les résumés, la classification, l’aide à la recherche et les brouillons, peut généralement être affichée comme suggestion. Les changements à risque moyen, comme l’affectation d’une demande, le choix d’une priorité ou la proposition de valeurs de document, nécessitent normalement une validation humaine. Les décisions à haut risque, comme les validations financières, les changements de droits, les remboursements, les décisions juridiques, la suppression de données ou la suspension d’un compte client, doivent rester contrôlées par les règles métier et les personnes autorisées.
Résultat de l’agent
│
▼
Quel type d’action est proposé ?
│
┌───┼────────────────┐
│ │ │
▼ ▼ ▼
Faible Moyen Risque élevé
risque risque
│ │ │
▼ ▼ ▼
Afficher Validation Règles,
comme humaine autorisation
aide requise et décision humaineL’application existante reste responsable des utilisateurs, droits, clients, commandes, documents, paiements, statuts, historique d’audit et actions métier finales. La couche contrôlée de l’agent prépare les données approuvées, communique avec le service d’IA choisi, vérifie la structure de la réponse, gère les délais d’attente, enregistre le résultat et présente la suggestion pour validation.
┌─────────────────────────────────────────┐
│ Application existante │
│ │
│ Utilisateurs • Droits • Données métier │
│ Processus existants • Décisions finales │
└───────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Couche contrôlée de l’agent │
│ │
│ Entrée • Contexte • Validation • Audit │
└───────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Fournisseur d’IA choisi ou modèle interne│
└─────────────────────────────────────────┘Cette structure permet de changer plus tard de fournisseur ou de modèle sans reconstruire l’application de l’entreprise.
GiSoft commence généralement par un prototype ciblé. Il doit répondre à des questions concrètes : la tâche est-elle adaptée à l’IA, les données sources sont-elles suffisantes, les suggestions sont-elles utiles, à quelle fréquence les collaborateurs les corrigent-ils, quels sont les temps de réponse et les coûts, que se passe-t-il dans les cas inhabituels et quelles exigences de protection des données s’appliquent ?
Un prototype n’est pas encore une mise en production. Une démonstration réussie doit être suivie par le travail de sécurité, la vérification des droits, la gestion des échecs, les tests, l’audit, le monitoring et un déploiement progressif.
Nous testons plus que le cas idéal : demandes normales, entrées très courtes et très longues, documents incomplets, langue non prise en charge, données sources absentes, sortie invalide de l’agent, réponse lente, délai dépassé, demande répétée, service indisponible, utilisateur sans droit, contenu contenant des instructions trompeuses, correction par un collaborateur et rejet humain.
Résultat attendu
│
├── suggestion valide
├── suggestion incomplète
├── suggestion invalide
├── fournisseur indisponible
└── rejet humain
│
▼
Chaque cas a une réponse applicative définieL’agent doit améliorer un processus sans devenir un nouveau point de défaillance unique.
Agent disponible
→ la suggestion est préparée
→ le collaborateur la vérifie
→ le processus continue
Agent indisponible
→ la suggestion est marquée indisponible
→ le collaborateur utilise le processus normal
→ l’application existante continue de fonctionnerPour les workflows non essentiels, les utilisateurs doivent pouvoir continuer manuellement.
Le déploiement doit être contrôlé. L’agent est d’abord activé pour l’équipe projet ou certains administrateurs, puis pour des collaborateurs qui connaissent bien le processus, puis pour un service ou un workflow. L’extension ne vient qu’après l’analyse des résultats.
Prototype
↓
Utilisateurs internes
↓
Équipe sélectionnée
↓
Un workflow de production
↓
Mesure et corrections
↓
Extension contrôléeUne réponse technique du fournisseur d’IA ne suffit pas à prouver la valeur métier. Les mesures utiles peuvent inclure le temps de traitement réduit, les suggestions acceptées, modifiées ou rejetées, l’affectation plus rapide des demandes, moins de champs manquants, un traitement documentaire plus court, la satisfaction des collaborateurs, le taux d’échec du fournisseur, le coût par tâche terminée et le nombre de cas traités sans retard. Ces valeurs doivent être comparées avec l’ancien processus.
Un agent d’IA nécessite une maintenance logicielle normale. Les procédures changent, les catégories changent, les formats de documents changent, les informations produit changent, les fournisseurs changent, les modèles se comportent différemment, les collaborateurs identifient des règles manquantes et les exigences de sécurité évoluent.
GiSoft maintient les instructions données à l’agent, la structure du résultat attendu, la validation, les droits d’accès, les tests, la documentation source, le monitoring, le contrôle des coûts et les règles d’audit.
Un projet peut inclure l’analyse du processus actuel, la définition du périmètre de l’agent, le choix des données d’entrée approuvées, les règles de sécurité et de droits, l’architecture d’intégration, le prototype, la structure du résultat, la connexion avec l’application existante, l’interface de validation humaine, le comportement en cas d’échec, les tests automatisés, le monitoring, le déploiement progressif, la documentation et le plan de maintenance.
L’entreprise reçoit un agent connecté à un processus précis, des règles claires décrivant ce qu’il peut et ne peut pas faire, un processus de validation, des résultats mesurables, une protection contre les sorties invalides, un fonctionnement normal lorsque le fournisseur est indisponible, de la documentation, des tests et une solution extensible.
Un agent d’IA de production n’est pas seulement un modèle connecté à une application. C’est un processus contrôlé qui définit quelles informations peuvent être utilisées, quel résultat est attendu, qui le vérifie et ce qui se passe lorsque le service ne peut pas fournir une réponse fiable. GiSoft conçoit l’agent autour du travail réel de l’entreprise et l’introduit progressivement, sans supprimer les contrôles déjà présents dans l’application.