Comment rédiger un document de périmètre pour un agent IA

Publié en août 2026.

TL;DR : Un document de périmètre est ce qui transforme « je veux un agent IA pour mon entreprise » en un chiffre que vous pouvez proposer et qu’un client peut valider. Il lui faut six parties : le déclencheur, les entrées, les sorties, les outils qu’il touche, ce qui est explicitement exclu, et une liste écrite de tests d’acceptation. Rédigez-le avant de chiffrer des frais de construction, pas après. Je facture le mien comme un livrable d’audit forfaitaire de 500 $ à 1 000 $, séparé de la construction.

[Point de vue de l’opérateur] Je gère plus de 30 agents en production pour une marque de conseil et Pickleland, une installation de pickleball à Pflugerville, TX, et j’ai cadré des constructions d’agents pour des clients en m’appuyant sur cette expérience. La raison la plus courante pour laquelle un engagement d’agent tourne mal n’est pas le code — c’est que personne n’a écrit ce que « terminé » signifiait avant l’envoi de la facture. Un document de périmètre règle ça en une seule séance. C’est le livrable le moins glamour que je produise, et celui qui évite le plus de disputes.

Table des matières

Pourquoi un document de périmètre, et non un e-mail de proposition

Un e-mail de proposition décrit ce que vous allez faire. Un document de périmètre définit à quoi ressemble « terminé » — de façon assez précise pour que vous et le client puissiez tous deux le comparer à l’agent fini et vous accorder, sans discussion, sur le fait qu’il a réussi ou non.

Cette distinction compte parce que la tarification des agents IA ne fonctionne que si les frais de construction s’accrochent à quelque chose de fixe. Chiffrez un prix fixe contre un périmètre non défini, et vous avez chiffré un montant que vous ne pouvez pas réellement livrer — le modèle mental du client pour « un agent IA pour mon entreprise » continue de s’étendre gratuitement jusqu’à ce que vous repoussiez, et repousser après l’acompte est une conversation bien pire que définir la limite avant.

J’en écris un pour chaque construction, même les petites. Un agent à flux de travail unique reçoit une version d’une demi-page. Un système multi-agents reçoit le document complet. Le format ne change pas — seule la longueur change.

Les six éléments dont un document de périmètre a besoin

1. Le déclencheur. Ce qui met l’agent en marche — la soumission d’un formulaire, une heure planifiée, un e-mail entrant, un webhook depuis un autre outil. Nommez le déclencheur exact, pas une catégorie de déclencheur. « Se déclenche quand un formulaire de prospect est soumis » relève du périmètre. « Gère les prospects entrants » n’en relève pas.

2. Les entrées. Les données que l’agent reçoit et leur provenance. Listez les champs, pas seulement la source — « nom, e-mail, taille de l’entreprise, et le champ de message en texte libre de la soumission Typeform », pas « les données du formulaire ».

3. Les sorties. Ce que l’agent produit et où cela va. Même règle : nommez la destination et le format. « Publie un brouillon de réponse dans le canal Slack #leads pour validation humaine » relève du périmètre. « Répond aux prospects » n’en relève pas.

4. Les outils et intégrations qu’il touche. Chaque API, base de données ou plateforme que l’agent appelle. C’est aussi ici que vous notez tout ce que vous *n’*intégrez explicitement pas — un client qui suppose que son CRM est inclus parce qu’il l’a mentionné une fois pendant l’appel de découverte est la source de dérive de périmètre la plus courante que j’aie vue.

5. Ce qui est exclu. Une liste courte et explicite des choses que l’agent ne fera pas, même si elles semblent adjacentes. Si vous construisez un agent de classification de prospects, écrivez « n’envoie pas de messages sortants » même si cela semble évident — évident pour vous ne l’est pas pour un client qui n’a jamais cadré de logiciel auparavant.

6. La liste des tests d’acceptation. La liste concrète des cas que l’agent fini doit réussir avant que le paiement final soit dû. Pas « fonctionne bien » — des cas spécifiques et vérifiables : « classe correctement 9 prospects sur 10 dans l’échantillon de données fourni », « publie avec succès dans le canal Slack connecté sans intervention manuelle », « gère une soumission mal formée (champ e-mail manquant) sans planter ». C’est la section la plus importante du document, parce que c’est celle que les deux parties peuvent invoquer plus tard sans rejuger ce qui était voulu.

Le modèle

C’est la structure exacte que j’utilise. Copiez-la, remplissez les six sections, et vous obtenez un document sur lequel vous pouvez poser un prix.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

Les lignes de frais de construction et d’abonnement existent pour que le prix soit ancré directement dans le périmètre qui le précède — voir comment je calibre les deux montants si vous n’avez jamais tarifé de construction auparavant. Un client qui signe ce document valide le périmètre et le prix dans le même geste, ce qui est précisément l’objectif.

Comment je mène l’appel qui produit ce document

Je facture la session de cadrage elle-même comme un audit forfaitaire de 500 $ à 1 000 $, séparé des frais de construction — jamais intégré dedans, même quand le client donne suite. Deux raisons : cela empêche l’étape de cadrage de devenir du travail commercial non payé, et cela pousse le client à prendre l’appel au sérieux plutôt que de le traiter comme une consultation gratuite.

L’appel lui-même dure 30 à 45 minutes, structuré autour des six sections ci-dessus, dans l’ordre. Je ne laisse pas la conversation dériver vers « ce qu’un agent IA pourrait théoriquement faire pour votre entreprise » — c’est une conversation différente, plus coûteuse, et c’est celle qui produit des documents que personne ne peut chiffrer. Je demande le déclencheur en premier, parce qu’un client incapable de nommer ce qui démarre le processus n’a généralement pas encore un flux de travail assez stable pour être automatisé — ce qui vaut la peine d’être mis au jour avant que l’un ou l’autre ne s’engage dans une construction.

Livrez le prompt, pas la page blanche

Je n’écris pas le premier brouillon du document à la main. Je prends mes notes d’appel — souvent juste un paragraphe désordonné de puces — et je colle ceci dans Claude :

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

Cette dernière instruction — signaler les lacunes plutôt que de les combler — est la partie qui compte. Un modèle inventera volontiers un test d’acceptation à l’apparence plausible pour compléter le document, et un test plausible qui ne correspond pas à ce que le client voulait vraiment est pire qu’un blanc que vous devez aller clarifier.

Les erreurs courantes que je vois encore

Écrire la section des exclusions en dernier, ou la sauter. La section des exclusions est celle que la plupart des gens traitent comme facultative. C’est celle qui évite le plus de litiges. Écrivez-la avant les tests d’acceptation, pas après.

Des tests d’acceptation qui décrivent un comportement plutôt qu’un résultat. « L’agent doit comprendre le ton du client » est un comportement. « Le brouillon de réponse de l’agent est approuvé sans modification dans 7 cas sur 10 » est un résultat. Seuls les résultats sont vérifiables.

Cadrer à partir d’une seule conversation sans notes écrites. Si le document de périmètre est le premier artefact écrit de l’engagement, vous reconstruisez l’appel de mémoire des jours plus tard. Prenez des notes pendant l’appel, dans l’ordre des six sections, et le document s’écrit presque tout seul.

Laisser le client écrire le périmètre. Un client qui décrit ce qu’il veut avec ses propres mots est une entrée du document, pas le document lui-même. Son langage est généralement en forme de fonctionnalité (« je veux qu’il gère mes prospects »), pas en forme de test. Traduire cela en critères d’acceptation vérifiables est la véritable valeur de la session de cadrage — c’est pourquoi c’est un livrable payant, et non un formulaire que le client remplit lui-même.

Les outils que j’utilise pour faire ça

Claude rédige le document à partir des notes d’appel brutes en utilisant le prompt ci-dessus, et signale les lacunes plutôt que de les deviner.

Notion est l’endroit où vit le document de périmètre terminé, partagé avec le client avant l’encaissement de tout acompte — le même endroit où je conserve le reste du dossier papier de l’engagement.

Airtable suit quels engagements sont en cadrage, signés, ou en construction, une ligne par client, pour qu’un document de périmètre ne reste jamais non signé pendant des semaines sans que personne ne le remarque.

FAQ

Quelle longueur doit avoir un document de périmètre ?

Aussi long que nécessaire pour rendre chaque test d’acceptation vérifiable, et pas plus. Un agent à flux de travail unique peut tenir sur une demi-page. Un système multi-agents avec plusieurs intégrations peut s’étendre sur deux ou trois pages. La longueur n’est pas l’objectif — l’objectif est qu’un client et un développeur, en lisant les tests d’acceptation indépendamment, s’accordent sur le fait qu’ils ont réussi ou non.

Que se passe-t-il si le client veut changer le périmètre après la signature ?

C’est une demande de changement, tarifée séparément et chiffrée avant le début du travail — inscrivez cette clause dans le document lui-même, comme dans le modèle ci-dessus. Un document de périmètre qui peut être discrètement étendu après signature n’est pas vraiment un document de périmètre.

Ai-je besoin d’un document de périmètre pour de très petites automatisations ?

Oui, juste un court. La valeur n’est pas dans la longueur — c’est d’avoir une liste écrite de tests d’acceptation avant de commencer à construire, pour que « terminé » soit une checklist plutôt qu’une impression. J’ai vu de petites missions cadrées de façon informelle traîner plus longtemps que de grandes missions correctement cadrées, exactement pour cette raison.

À qui appartient le document de périmètre lui-même — fait-il partie du livrable ?

Je considère qu’il appartient au client, qu’il donne suite ou non à une construction, puisqu’il a payé l’audit qui l’a produit. Ce que je conserve, c’est le modèle et le prompt sous-jacents, de la même façon que je conserve un échafaudage réutilisable d’un engagement à l’autre — la structure du document est à moi, le contenu rempli sur leur entreprise spécifique est à eux.

Prochaines étapes : Mon cours AI Agents for Beginners couvre la construction des agents que décrit un document de périmètre comme celui-ci. Le programme cowork est pour les opérateurs qui veulent un environnement structuré pour s’entraîner à cadrer et construire ce type de travail. Si vous préférez faire écrire le document de périmètre pour vous, réservez une session de 30 minutes.