Agents IA pour les achats : où commencent les vrais risques
Fonctions support · 8 min
Un agent peut lire un contrat, interroger une base fournisseur ou préparer une stratégie de négociation. La question n’est pourtant pas « peut-il le faire ? ». La vraie question est : quelle erreur sommes-nous prêts à laisser passer, et qui la détectera ?
Un agent n’est pas un moteur de recherche avec un bouton en plus
Un moteur de recherche propose des informations. Un agent choisit des étapes, appelle des outils et peut modifier un système. Cette capacité d’action change la nature du risque.
Dans les achats, une sortie incorrecte peut devenir :
- une clause importante ignorée ;
- un fournisseur évalué sur une donnée obsolète ;
- une communication envoyée avec le mauvais niveau d’engagement ;
- une recommandation impossible à expliquer lors d’un audit.
Le niveau de contrôle doit donc dépendre de l’impact de l’action, pas du niveau de confiance affiché par le modèle.
Décision 1 : séparer préparation et engagement
L’agent peut préparer une comparaison, extraire les obligations et proposer un brouillon. Il ne devrait pas engager l’entreprise de la même manière.
Une frontière pratique :
| Type d’action | Exemple | Contrôle |
|---|---|---|
| Lecture | rechercher une clause | source visible |
| Préparation | comparer trois offres | validation métier |
| Modification | mettre à jour une fiche | aperçu du changement |
| Engagement | envoyer, signer, négocier | autorisation explicite |
Plus l’action est irréversible, plus la validation doit être proche de l’exécution.
Décision 2 : concevoir les permissions avant le prompt
Un prompt disant « ne modifie rien sans autorisation » est une consigne. Une permission technique est une garantie.
L’agent ne devrait recevoir que :
- les outils nécessaires à son cas d’usage ;
- le périmètre de données correspondant ;
- des opérations bornées plutôt qu’un accès générique ;
- une durée et un volume d’action limités.
Par exemple, préparer_brouillon_fournisseur est plus sûr qu’un accès libre à la messagerie et au CRM.
Décision 3 : évaluer sur les exceptions
Les démonstrations utilisent des dossiers propres. Le travail réel contient des scans incomplets, des variantes contractuelles, des dates contradictoires et des fournisseurs homonymes.
Un jeu d’évaluation utile doit donc inclure :
- les cas fréquents ;
- les cas ambigus ;
- les données absentes ;
- les tentatives de détourner l’instruction ;
- les erreurs ayant déjà coûté du temps à l’équipe.
L’objectif n’est pas d’obtenir un score flatteur. Il est de savoir quand le système doit s’arrêter.
Décision 4 : rendre l’arrêt aussi utile que la réponse
Un agent fiable sait produire trois sorties : une action, une demande de précision ou un refus d’agir. Cette dernière catégorie est souvent oubliée.
Le système doit pouvoir dire :
Deux versions du contrat portent la même date. Je ne peux pas déterminer la version applicable. Voici les deux documents à vérifier.
C’est moins spectaculaire qu’une réponse instantanée. C’est beaucoup plus utile en production.
Une séquence raisonnable pour démarrer
Commencez par un cas d’usage en lecture seule. Mesurez la précision des sources et le temps réellement gagné. Ajoutez ensuite la préparation de brouillons, puis seulement les actions réversibles.
L’autonomie n’est pas un point de départ. C’est une permission gagnée par les résultats.
Vous évaluez un cas d’usage achats ? Passons en revue le processus et ses risques.