Cahier des charges d'un agent IA support : le modèle pratique

Un agent IA support doit savoir répondre, agir et s’arrêter. Le cahier des charges sert surtout à définir ces trois limites avant que l’outil ne les invente à votre place.

La plupart des projets ratent moins à cause du modèle qu’à cause du flou : données mal identifiées, droits trop larges, escalade absente, tests trop propres. Pour un projet d’agent IA support, le document de départ doit être court, concret et vérifiable.

Voici un modèle utilisable avant un prototype, un atelier de cadrage ou une première phase de construction.

Décision de cadrage Le cahier des charges doit surtout dire ce que l’agent ne fait pas. C’est là que le projet devient exploitable.

Un cahier des charges support doit protéger l’équipe, pas flatter l’outil

Le document utile ne décrit pas “un agent intelligent”. Il décrit ce qu’il peut lire, écrire, refuser et escalader.

Transformer ce modèle en sprint

1. Objectif métier

Écrivez l’objectif en une phrase, sans promesse chiffrée inventée.

Exemples corrects :

• préparer des réponses support sur les demandes de facturation ;
• trier les tickets entrants par thème et priorité ;
• aider l’équipe à retrouver les procédures internes ;
• générer une première réponse validée par un humain.

Exemple trop flou : “améliorer l’expérience client avec l’IA”. Personne ne peut tester ça proprement.

Ajoutez ensuite le périmètre négatif : ce que l’agent ne fera pas. Cette partie protège le projet. Un agent support qui ne modifie jamais un contrat, ne promet jamais de remboursement et ne donne pas d’avis juridique est plus facile à mettre en production.

Un bon objectif support tient dans une situation observable : “réduire le temps de préparation des réponses sur les demandes de facturation simples”, pas “améliorer l’expérience client grâce à l’IA”. La première phrase donne un lot de tickets, une mesure et une limite. La seconde donne une promesse invérifiable.

Ajoutez aussi une raison de ne pas automatiser certains cas. Litige, geste commercial, contrat, données personnelles sensibles, client stratégique : ces mots doivent déclencher une escalade, pas une improvisation du modèle.

Où utiliser ce modèle

Ce modèle arrive après le choix du périmètre. Si vous n’avez pas encore choisi le cas d’usage, commencez par agent IA pour PME. Si vous hésitez encore entre agent et workflow, lisez chatbot, agent IA ou automatisation.

2. Utilisateurs et canaux

Précisez qui utilise l’agent et où il intervient. Au lieu d’empiler des colonnes, gardez cette partie sous forme de courte fiche de contexte.

Un agent interne qui prépare des réponses n’a pas les mêmes contraintes qu’un agent exposé directement au client. Ne mélangez pas les deux dans un premier lot.

3. Sources de données

Le cahier des charges doit nommer les sources de vérité. Pas “nos documents internes”. Les sources exactes.

Pour chaque source, indiquez qui la maintient. Un agent branché sur une base documentaire abandonnée deviendra vite convaincant et faux.

Ce que l’agent peut faire, refuser et tracer

4. Actions autorisées

Un agent support peut être plus qu’un assistant de rédaction, mais chaque action doit être décidée avant le prototype. Écrivez-la comme une règle d’exploitation, pas comme une promesse.

Cette section force la vraie discussion métier : qu’a-t-on le droit de déléguer, et quelle preuve garde-t-on quand quelque chose se passe mal ?

5. Règles d’escalade

Un bon agent ne cherche pas à tout résoudre. Il sait passer la main.

Définissez les cas d’escalade dès le départ :

• client mécontent ou menaçant ;
• demande liée à un contrat, un remboursement ou un litige ;
• identité incertaine ;
• donnée absente ou contradictoire ;
• demande hors périmètre ;
• confiance faible dans la réponse ;
• action irréversible ;
• répétition d’une erreur déjà détectée.

L’escalade doit produire un objet utile : résumé du cas, données consultées, proposition de réponse, raison du blocage. Sinon l’agent ne fait que déplacer la charge vers l’humain.

6. Format des logs

Sans logs, impossible de savoir si l’agent s’améliore ou s’il a seulement l’air fluide.

Journal minimal :

Horodatage
Canal
Identifiant ticket ou conversation
Intention détectée
Sources consultées
Action proposée ou exécutée
Niveau de confiance interne
Raison d'escalade, si escalade
Validation humaine
Correction apportée

Ne stockez pas plus de données personnelles que nécessaire. Mais stockez assez pour auditer les décisions et corriger les règles.

7. Lot de test

Le test doit utiliser des cas réels anonymisés, pas seulement des exemples propres. Un lot utile mélange volontairement ce qui marche, ce qui casse et ce qui doit être refusé.

Un bon test ne cherche pas à prouver que l’agent marche. Il cherche à trouver où il casse.

8. Critères d’acceptation

Remplacez les critères vagues par des observations.

• L’agent utilise uniquement les sources autorisées.
• Il cite ou indique la source interne utilisée quand c’est utile.
• Il escalade les cas interdits.
• Il ne promet pas d’action non autorisée.
• Il produit un log exploitable.
• Il demande une clarification quand l’identité ou le contexte manque.
• Les corrections humaines peuvent être réinjectées dans la boucle d’amélioration.

Ces critères ne garantissent pas un produit parfait. Ils rendent le pilote jugeable.

Modèle compact à copier

Pour garder un cahier des charges lisible, remplissez ces neuf lignes dans un document court plutôt que dans un grand tableau décoratif.

• Objectif: la tâche métier que l'agent doit vraiment absorber.
• Utilisateurs et canaux: qui l'utilise, où, avec quel niveau de visibilité.
• Sources autorisées: documents, bases et outils consultables, avec un responsable pour chaque source.
• Actions autorisées et interdites: ce que l'agent peut faire seul, préparer ou ne jamais faire.
• Règles d'escalade: les cas où l'humain reprend la main et ce que l'agent doit transmettre.
• Logs: les traces minimales pour auditer, corriger et comprendre les décisions.
• Lot de test: cas simples, ambigus, interdits, données absentes et tickets historiques.
• Responsable métier: la personne qui arbitre les règles, pas seulement la technique.
• Critères d'acceptation: observations vérifiables avant une mise en production limitée.

Transformer le modèle en sprint réel

Un cahier des charges utile ne doit pas dormir dans un document. Il doit produire un prototype testable sur un lot de tickets réels anonymisés, avec logs, seuils d’escalade et critères de refus.

Last Word peut convertir ce modèle en sprint de cadrage ou de prototype pour un agent IA support. Si vous avez déjà le flux et les exemples, envoyez le périmètre.

Les quatre lignes que le brief ne peut pas esquiver

• Ce que l’agent ne fait jamais: remboursement, promesse commerciale, décision contractuelle.
• La source qui fait foi: CRM, outil support, base documentaire ou facture.
• Le moment d’escalade: doute, donnée manquante, client sensible, ton inhabituel.
• La preuve gardée: sources consultées, action proposée, correction humaine.

FAQ

Faut-il un cahier des charges long ?

Non. Pour un premier agent, deux à cinq pages bien remplies valent mieux qu’un document de vingt pages impossible à maintenir.

Peut-on commencer sans CRM propre ?

Oui si le premier périmètre ne dépend pas du CRM. Sinon, il faut au moins identifier les champs fiables et les cas où l’agent doit s’arrêter.

Qui doit valider le cahier des charges ?

Le métier et la personne responsable du support. La technique peut proposer l’architecture, mais elle ne doit pas inventer les règles de décision.

Comment Last Word cadrerait le projet

Last Word peut transformer ce cadrage en prototype : workflow, connexion aux sources, règles d’escalade, journalisation et QA. Ce cahier des charges gagne à être relié à une méthode de création d’agent IA et à une lecture claire de la différence entre agent IA et chatbot. Si vous avez déjà un processus support à cadrer, envoyez le contexte via contact.