Agent IA sur mesure : rédiger un cahier des charges utile

Un agent IA sur mesure qui traite des demandes de devis échoue rarement par manque de technologie : il échoue parce que personne n'a écrit ce qui doit sortir, dans quel format, et ce qui est interdit. Ce guide fournit un modèle rempli de cahier des charges pour un cas précis : un agent qui qualifie et prépare les demandes de devis entrantes, sans jamais émettre de devis final. Vous y trouverez les champs obligatoires, des exemples contradictoires, les formats attendus, les règles métier, les droits d'accès, les critères de recette et la gestion des changements. Vous verrez aussi comment corriger un brief vague et quelles informations préparer avant de lancer le projet.

Pourquoi un cahier des charges testable change tout

Un cahier des charges utile n'est pas un document de style : c'est un contrat de test. Chaque phrase doit pouvoir se transformer en un contrôle binaire, réussi ou échoué. « L'agent doit bien traiter les demandes » ne se teste pas. « L'agent doit classer chaque demande dans exactement une des trois catégories A, B, C et produire un récapitulatif JSON avec ces sept champs » se teste.

Cette discipline protège les deux parties. Le prestataire sait ce qu'il doit livrer, et vous savez ce que vous pouvez refuser. Si vous comparez plusieurs propositions, un cahier des charges précis rend les offres comparables, comme expliqué dans notre guide pour comparer les propositions d'une agence agent IA. Sans lui, chaque devis décrit un produit différent.

Le cas choisi ici est volontairement borné : l'agent prépare, ne décide pas. Aucun devis final n'est envoyé au client final ; un humain relit et envoie. Cette frontière simplifie les règles, réduit les risques et reste un excellent premier projet, dans la lignée d'un premier projet d'agent IA mené avec une mission qui se termine vraiment.

Exemple principal : l'agent de qualification des demandes de devis

Prenons une PME de services fictive qui reçoit, dans cet exemple, 30 à 60 demandes de devis par semaine par e-mail et formulaire. Aujourd'hui, un chargé d'affaires lit chaque demande, cherche les informations manquantes, puis rédige un brouillon de réponse. L'agent sur mesure doit reprendre cette tâche préparatoire.

Mission de l'agent : pour chaque demande entrante, extraire les informations structurées, détecter les champs manquants ou incohérents, classer la demande par famille de prestation et urgence, puis produire un brouillon de réponse dans la boîte de l'entreprise. Le brouillon reste un brouillon : il n'est jamais envoyé automatiquement.

Sortie attendue pour chaque demande : un enregistrement structuré avec les champs listés plus bas, plus un brouillon d'e-mail de relance ou d'accusé de réception, prêt à relire.

Sortie explicitement interdite : envoi d'un e-mail, émission d'un prix, engagement de délai, modification d'un document commercial, suppression ou transfert de message.

Cette limitation n'est pas une prudence excessive. Si l'agent manipule Gmail, il faut savoir que les scopes comme gmail.compose et gmail.modify peuvent aussi autoriser l'envoi de messages ; limiter le comportement aux brouillons exige donc des contrôles applicatifs, pas seulement une case cochée côté autorisation. La documentation officielle des scopes Gmail le décrit clairement, et un libellé de dossier n'est pas une frontière de permission Gmail : ce sont vos règles applicatives qui font la frontière.

Champs obligatoires du cahier des charges

Voici le squelette, rempli avec notre exemple. Vous pouvez le réutiliser tel quel pour un agent IA personnalisé de qualification.

Section	Contenu dans notre exemple
Mission	Qualifier les demandes de devis entrantes et préparer un brouillon de réponse
Périmètre inclus	E-mail entrant et formulaire web, extraction, classement, brouillon
Périmètre exclu	Envoi d'e-mail, chiffrage, signature, relances automatiques au-delà d'un brouillon
Entrées	Boîte e-mail dédiée, export quotidien du formulaire web
Sorties	Enregistrement JSON normalisé, brouillon Gmail, ligne dans le tableau de suivi
Règles métier	Classement A/B/C, détection des champs manquants, seuils d'urgence
Droits	Lecture de la boîte dédiée, création de brouillons, écriture dans le tableau de suivi. Pas d'envoi, pas de suppression
Recette	20 demandes réelles historiques rejouées, avec résultats attendus écrits à l'avance
Limites connues	Demandes multilingues hors français et anglais traitées en marquage « à revoir humain »
Gestion des changements	Toute nouvelle règle passe par une fiche de changement avec impact sur la recette

Chaque ligne doit être rédigée pour pouvoir échouer. « Droits : pas d'envoi » devient un test : on tente de faire envoyer un message par l'agent dans un scénario de recette, et le test réussit si l'agent refuse et le signale.

Formats et règles de données : ne pas confondre les deux

Une erreur fréquente dans les briefs consiste à mélanger deux choses différentes : le format des données et les règles qui s'appliquent à ces données. Le format décrit à quoi ressemble une information ; la règle décrit ce qu'on en fait.

Formats, dans notre exemple :

• Horodatages : date, heure et fuseau explicites ; une date seule reste au format AAAA-MM-JJ. Une demande reçue le 20/10/2026 à 10h Paris correspond à 08h Dakar ; le 3 novembre 2026 à 10h Paris correspond à 09h Dakar, à cause du changement d'heure. Si vos équipes travaillent sur deux fuseaux, le format doit porter le fuseau, pas le deviner.
• Montants : nombre décimal avec devise en code ISO, jamais « environ 5k ».
• Identifiants : l'identifiant de brouillon Gmail est stable, mais l'identifiant du message contenu change lorsqu'on modifie le brouillon. Si votre tableau de suivi référence un brouillon, il doit stocker l'identifiant de brouillon, pas celui du message.
• Catégories : valeurs fermées A, B, C. Toute valeur hors liste est une erreur à signaler, pas une catégorie « autre » fourre-tout.

Règles, dans notre exemple :

• Si le budget annoncé est absent, la demande passe en catégorie C et le brouillon pose la question du budget.
• Si le délai demandé est inférieur à dix jours ouvrés, la demande est marquée « urgence » et le chargé d'affaires est notifié dans le récapitulatif, jamais par e-mail automatique.
• Si la demande mentionne un concurrent par nom, le brouillon ne fait aucune comparaison ; il signale la demande au chargé d'affaires dans le récapitulatif, sans transférer ni envoyer de message.

La distinction compte pour la recette : on teste les formats avec des jeux de données, on teste les règles avec des scénarios. Un cahier des charges qui confond les deux produit des recettes interminables et des litiges. Cette même grille de distinction sert aussi pour évaluer les réponses d'un chatbot IA avec des critères métier plutôt qu'à l'impression.

Exemples contradictoires : ce qui rend un brief inutilisable

Les briefs vagues contiennent presque toujours des instructions qui se contredisent. Voici trois paires fictives, construites pour montrer les contradictions, reformulées pour notre exemple.

Contradiction 1 : autonomie contre contrôle. « L'agent doit répondre immédiatement aux clients » et « aucune réponse ne part sans validation ». Correction : l'agent prépare un brouillon immédiatement ; l'envoi reste humain. Une seule phrase suffit : « Le brouillon est disponible dans les 15 minutes suivant la réception ; l'envoi est manuel. »

Contradiction 2 : exhaustivité contre simplicité. « Extraire toutes les informations utiles de la demande » et « ne pas inventer ce qui n'est pas écrit ». Correction : lister les champs exacts à extraire et la conduite à tenir pour chaque champ absent : « champ manquant » plutôt qu'une devinette. Un agent IA sur mesure doit savoir dire « je ne sais pas » de façon structurée.

Contradiction 3 : classement contre exceptions. « Toute demande inférieure à 2 000 € passe en catégorie C » et « les clients connus restent en catégorie A quel que soit le montant ». Correction : écrire l'ordre des règles. « Règle 1 : si client connu, catégorie A. Règle 2 : sinon, si montant inférieur à 2 000 €, catégorie C. » L'ordre fait partie du cahier des charges.

Pour corriger un brief vague, appliquez cette procédure en quatre étapes :

1. Soulignez chaque verbe d'action et demandez : quel déclencheur, quelle entrée, quelle sortie observable ?
2. Pour chaque adjectif (« rapide », « fiable », « intelligent »), remplacez-le par une mesure : « brouillon prêt en moins de 15 minutes », « 95 % des champs obligatoires remplis sur l'échantillon de recette ».
3. Pour chaque « toujours » et « jamais », écrivez le scénario de test correspondant.
4. Faites relire le document par quelqu'un qui n'a pas participé, et demandez-lui de lister ce qu'il ferait différemment. Chaque écart est une ambiguïté restante.

Droits d'accès et frontières de permission

Le cahier des charges doit traiter les droits comme une spécification à part entière, pas comme un détail technique. Trois choses différentes se cachent souvent derrière le mot « connexion » : le transport (le canal technique), l'autorisation du fournisseur (le compte et ses scopes) et la preuve d'opération (le journal qui montre ce qui a réellement été fait). Un cahier des charges sérieux décrit les trois.

Dans notre exemple :

• Transport : l'agent lit une boîte e-mail dédiée via l'API, pas la boîte personnelle du dirigeant.
• Autorisation : le scope demandé couvre la lecture et la création de brouillons. Comme les scopes de type compose ou modify peuvent aussi permettre l'envoi, le cahier des charges impose un contrôle applicatif : la fonction d'envoi n'existe pas dans le code livré, et un test de recette tente l'envoi pour vérifier le refus.
• Preuve d'opération : chaque demande traitée produit une ligne de journal horodatée avec l'identifiant de la demande, le classement et l'identifiant de brouillon créé.

Si votre agent doit aussi consulter des agendas, sachez que Calendar permet de créer des événements avec des identifiants explicites, mais qu'il n'existe pas de transaction globale garantie entre Calendar et votre propre système : le cahier des charges doit prévoir un état intermédiaire réconciliable en cas d'échec partiel. De même, un protocole comme MCP permet d'échanger des outils et du contexte, mais il ne choisit pas à votre place les règles métier ni les permissions : celles-ci restent dans votre spécification. Enfin, la protection des données personnelles traitées par l'agent (coordonnées des prospects, contenu des échanges) doit respecter les grands principes rappelés par la CNIL : finalité, minimisation, sécurité.

Critères de recette : comment on validera

La recette transforme le cahier des charges en verdict. Préparez-la pendant la rédaction, pas après le développement. Notre exemple fixe :

• Jeu d'essai : 20 demandes réelles anonymisées couvrant les trois catégories, deux demandes multilingues, une demande sans budget, une demande avec délai urgent, une demande incohérente (date de livraison antérieure à la date d'envoi).
• Critère de classement : au moins 18 réponses sur 20 classées comme attendu ; les deux écarts maximum doivent être analysés et compris.
• Critère de champs : 100 % des enregistrements produits respectent les formats (dates, montants, catégories fermées). Un seul format invalide fait échouer le test.
• Critère de sécurité : aucun envoi possible, vérifié par tentative volontaire ; aucune écriture hors du tableau de suivi prévu.
• Critère de brouillon : chaque brouillon cité dans le tableau de suivi reste retrouvable après modification, grâce au stockage de l'identifiant de brouillon et non de l'identifiant de message.

Ces critères rejoignent la logique générale de la recette et de la livraison d'un développement de chatbot : des tests écrits avant, un verdict binaire, et une liste d'écarts acceptés explicitement plutôt qu'une impression générale.

Gestion des changements et informations à préparer

Un agent vit avec vos règles commerciales, qui changeront. Le cahier des charges doit prévoir comment. Dans notre exemple : toute modification de règle (nouvelle catégorie, nouveau seuil, nouveau champ) passe par une fiche de changement d'une page décrivant la règle actuelle, la règle visée, les scénarios de recette impactés et la date d'application. Les changements qui touchent les formats obligatoires déclenchent une recette partielle sur le jeu d'essai complet.

De votre côté, préparez ces informations avant de rédiger ou de confier le brief :

• Vingt à trente demandes réelles passées, avec le classement que votre équipe aurait donné.
• La liste fermée des catégories et familles de prestation.
• Les règles de priorité écrites, avec leur ordre d'application.
• La boîte e-mail dédiée et les droits disponibles dessus.
• Le tableau de suivi existant, avec ses colonnes réelles.
• Les personnes qui valident la recette et celles qui décident des changements.

Si vous partez de zéro, le guide sur les missions d'un agent IA en entreprise aide à choisir une tâche qui se termine, condition d'un premier projet réussi.

Limites à assumer dans le document

Écrire les limites dans le cahier des charges évite de les découvrir en production. Trois limites méritent une mention explicite dans notre exemple. D'abord, la classification repose sur des exemples passés : une demande d'un type jamais vu peut rester incertaine. Le cahier des charges prévoit alors un état de traitement « à relire », distinct des catégories A/B/C : tant que la classification n'est pas validée, le champ de catégorie reste vide. Ensuite, l'extraction depuis des pièces jointes non textuelles (plans, scans) est hors périmètre ; ces demandes sont marquées « pièce jointe à traiter ». Enfin, l'agent ne gère pas la relation commerciale : un prospect qui répond au brouillon relance le processus humain normal.

Assumer ces limites, c'est aussi protéger la confiance dans les réussites. Un agent qui qualifie correctement 19 demandes sur 20 et signale honnêtement la vingtième est plus utile qu'un agent qui prétend tout traiter.

Questions fréquentes

Faut-il interdire l'envoi d'e-mails dès le premier projet ?

C'est fortement recommandé pour un premier agent IA sur mesure. Les scopes Gmail de type compose ou modify pouvant aussi autoriser l'envoi, l'interdiction doit être portée par le code applicatif et vérifiée en recette. Vous pourrez élargir plus tard, avec des règles d'envoi explicites et un journal.

Quelle différence entre une règle de données et une règle métier ?

Une règle de données décrit le format et la validité d'une information : date en AAAA-MM-JJ, montant avec devise, catégorie dans une liste fermée. Une règle métier décrit le traitement : « si le budget est absent, passer en catégorie C ». Les premières se testent avec des jeux de données, les secondes avec des scénarios.

Combien de scénarios de recette prévoir ?

Comptez un scénario par règle écrite, plus les cas limites que vous connaissez déjà : demande sans budget, dates incohérentes, langue inattendue. Les vingt demandes de notre exemple constituent un point de départ illustratif, pas une preuve statistique suffisante. Ajoutez les cas limites et adaptez le volume à la diversité des demandes et aux conséquences d'une erreur.

Que faire si mon brief contient des instructions contradictoires ?

Traitez chaque contradiction comme une décision à prendre, pas comme un détail. Écrivez l'ordre des règles, remplacez les adjectifs par des mesures, et faites relire le document par une personne extérieure. Une contradiction laissée dans le brief ressortira comme un litige à la recette.

Le cahier des charges doit-il prévoir les changements futurs ?

Oui, c'est même ce qui le distingue d'une simple liste de fonctionnalités. Prévoyez une fiche de changement avec impact sur la recette pour chaque nouvelle règle, et une recette partielle quand les formats changent. Un agent IA personnalisé qui ne peut pas évoluer proprement devient un coût au premier changement commercial.