Missions d’agents IA à périmètre fixe : checklist acheteur
Written by Tileo, operator of Pitstop.
Une mission d’agent IA à périmètre fixe est un lot de travail borné avec des entrées nommées, un livrable défini, des limites explicites et un contrôle d’acceptation. Ce n’est ni la construction ouverte d’un agent ni une offre d’emploi. Refusez les promesses vagues du type « tout automatiser ». Demandez ce qui entre, ce qui sort, ce qui ne sera pas fait et comment le résultat sera accepté. Décidez aussi qui fournit l’accès au modèle et qui valide le travail. Pitstop présente un catalogue de missions bornées avec entrées, sorties et limites explicites. La checklist ci-dessous aide à choisir entre une mission du catalogue, un brief sur mesure, un développement freelance ou une phase de cadrage.
Qu’est-ce qu’une mission d’agent IA à périmètre fixe ?
L’achat porte sur un travail fini, pas sur une capacité indéfinie. Une bonne mission se décrit avant son exécution :
- Entrée nommée : fichiers, données ou textes fournis pour cette exécution.
- Livrable défini : fichier ou résultat structuré remis à la fin.
- Limites explicites : actions, sources, formats et décisions exclus.
- Contrôle d’acceptation : conditions observables permettant d’accepter ou de refuser le livrable.
- Responsable humain : personne autorisée à valider, refuser ou demander une correction.
Pitstop décrit chaque machine comme un workflow borné avec des entrées, sorties et limites explicites, dont le résultat peut être validé par un humain sur sa page publique. « Utiliser l’IA dans nos opérations » n’est pas une mission. « Transformer ce lot fourni dans ce format, signaler ces exceptions puis s’arrêter » peut en devenir une.
Un périmètre fixe ne signifie pas que le sujet est simple. Il signifie que la remise est contrôlable. L’acheteur peut identifier le lot, le vérifier et clore l’exécution sans transformer silencieusement la demande en produit logiciel.
Quelle différence avec un ingénieur IA ou un freelance ?
La différence tient à la forme de l’achat. Une mission bornée achète un livrable produit à partir d’entrées données. Un développement achète du travail vers un système, une intégration ou une capacité continue. Une offre d’emploi recherche le temps et le rôle d’une personne. Chaque voie peut convenir, mais chacune mérite son propre brief.
| Voie d’achat | À définir en premier | Résultat adapté | Question avant validation |
|---|---|---|---|
| Mission du catalogue | Entrée, sortie et limites listées | Un livrable contrôlable | La fiche correspond-elle au besoin ? |
| Mission sur mesure | Contrat d’entrée et de livrable | Une remise bornée | L’acceptation est-elle vérifiable ? |
| Développement freelance | Exigences, interfaces, propriété, maintenance | Outil ou workflow continu | Qui l’exploite et le modifie ? |
| Poste salarié | Responsabilités et place dans l’équipe | Contribution continue | Est-ce un rôle plutôt qu’un lot ? |
Ne faites pas entrer une opération continue dans un achat ponctuel. Si le besoin inclut connexions à des systèmes actifs, supervision, exceptions, règles changeantes ou maintenance, cadrez-le comme un développement. Le guide sur l’automatisation des workflows IA détaille la catégorie. Le guide des outils d’IA agentique aide si vous choisissez encore une catégorie de produit.
Certains prestataires emploient « Fixed-Scope Pilots », dont Essens Software. Le mot « pilote » ne suffit pas. Le brief doit toujours fixer entrées, livrable, limites et acceptation.
Quelles entrées et quels livrables verrouiller ?
Commencez par les deux côtés de la remise. Nommez le type exact d’entrée et de sortie. « Des documents contre des analyses » oblige les parties à inventer la mission pendant son exécution.
Pour les entrées, notez :
- Les types de fichiers ou la structure de données acceptés.
- Les champs obligatoires.
- La limite du lot ou de l’exécution.
- La langue ou locale couverte.
- Le traitement des éléments illisibles, absents ou contradictoires.
- Ce qui ne doit pas être envoyé, notamment les clés de modèle.
Pour le livrable, indiquez le format, les sections ou colonnes obligatoires et les marqueurs de révision. Un tableur doit nommer ses colonnes. Un rapport doit nommer ses sections. Une comparaison doit préciser comment chaque changement renvoie au contenu fourni. Le catalogue Pitstop illustre ce schéma avec un lot PDF ou image transformé en CSV avec marqueurs, ou une transcription transformée en DOCX.
Ajoutez une ligne claire sur la propriété. Indiquez qui possède les données fournies, qui peut y accéder pendant l’exécution, qui reçoit le livrable et qui peut le conserver après acceptation. Sans accord, mettez la demande en pause. Une promesse générale de confidentialité ne remplace pas des consignes précises.
Comment écrire tests d’acceptation et limites ?
Un test d’acceptation doit être observable dans le livrable et l’entrée convenue. Il ne doit pas reposer sur l’impression que la sortie « semble intelligente ». Donnez au relecteur des contrôles concrets :
- Présence : chaque section, champ ou fichier requis existe.
- Format : le livrable s’ouvre dans le format convenu et suit le schéma.
- Traçabilité : si elle est demandée, chaque assertion renvoie au contenu fourni.
- Exceptions : les éléments incertains ou non étayés portent le marqueur convenu.
- Périmètre : le livrable couvre le lot fixé et rien d’autre.
- Validation : un humain nommé consigne acceptation ou refus.
Modèle de brief :
> À partir de [entrée nommée], produire [livrable et format]. Inclure [champs ou sections]. Signaler [exceptions]. Ne pas [actions exclues]. La mission passe si [contrôles observables] sont satisfaits. [personne ou rôle] donne la validation finale.
Consacrez une section aux limites. Dites si la mission peut consulter des sources externes, modifier les originaux, contacter des personnes, publier, déclencher un paiement ou écrire dans un système actif. « Faire preuve de jugement » n’autorise aucune de ces actions. La limite indique où arrêter l’exécution et ce que le livrable ne prétend pas faire.
Évitez les objectifs en pourcentage sans jeu de mesure et méthode inscrits dans le brief. « Précis » n’est pas un test autonome. Nommez les éléments contrôlés, la valeur attendue et le traitement des exceptions.
Quand le BYOK compte-t-il ?
BYOK signifie « bring your own keys ». Il compte quand l’acheteur fournit l’accès au modèle. Le brief doit indiquer qui fournit l’accès, où l’exécution se déroule et si les identifiants entrent dans l’outil d’exécution.
Ne collez jamais une clé de modèle dans un message d’admission ordinaire. Pitstop indique publiquement que la clé LLM reste celle de l’acheteur et que la connexion passe par OAuth sans collage de clé API sur sa page d’accueil. Pour tout prestataire, demandez la méthode de connexion exacte. Le sigle BYOK ne répond pas seul à la question de sécurité.
Séparez quatre éléments :
- Accès au modèle et propriétaire du compte.
- Accès à l’exécuteur et méthode d’autorisation.
- Données d’entrée et usage permis.
- Livrables finis et destination.
Le BYOK ne définit ni périmètre, ni acceptation, ni propriété. Il ne couvre qu’une partie de l’accès.
Que faut-il garder sous validation humaine ?
Le livrable final doit avoir un validateur nommé. Toute étape qui envoie, publie, paie, supprime, signe ou modifie une donnée active doit aussi avoir un point d’approbation explicite avant l’action.
La tâche du relecteur doit rester concrète :
- Comparer le livrable à la checklist d’acceptation.
- Examiner les marqueurs et éléments non étayés.
- Confirmer que les actions exclues n’ont pas eu lieu.
- Accepter, refuser avec les échecs constatés ou demander une correction dans le périmètre.
N’écrivez pas seulement « humain dans la boucle ». Nommez la personne, ce qu’elle voit et sa décision. Pitstop dit que les résultats de ses machines peuvent être validés par un humain sur sa page d’accueil. Pour comparer les degrés d’indépendance, consultez agents IA autonomes. Le brief borné conserve une décision humaine quel que soit le terme employé.
Checklist avant de demander la mission
- Pouvons-nous nommer un livrable et son format ?
- Avons-nous les entrées requises dans la forme convenue ?
- La limite d’exécution est-elle claire ?
- Les actions hors périmètre sont-elles écrites ?
- Un relecteur peut-il effectuer tous les contrôles ?
- Les marqueurs d’exception sont-ils définis ?
- Les accès au modèle et à l’exécuteur sont-ils documentés ?
- Le traitement des entrées et la propriété du livrable sont-ils attribués ?
- Un humain est-il nommé pour la validation finale ?
- La demande s’arrête-t-elle à la remise ?
Si tout est clair, comparez la demande au catalogue. Si le livrable est clair mais que format ou limites restent à définir, rédigez un brief sur mesure. Si le besoin est un outil maintenu ou un workflow continu, cadrez un développement. Si livrable, entrées ou validateur sont inconnus, n’envoyez pas encore les données.
Demander une mission IA cadrée
FAQ
Une mission d’agent IA à périmètre fixe peut-elle être à distance ?
Oui. « À distance » décrit le lieu. « Périmètre fixe » décrit le lot. La demande conserve entrées nommées, livrable, limites, acceptation et validateur.
Comment parler du prix ?
Demandez un prix pour la limite d’entrée, le livrable, les conditions d’acceptation et la politique de correction exacts. Confirmez ce qui se passe si l’exécution échoue ou si l’entrée ne respecte pas le format convenu. Ne comparez les devis que s’ils couvrent le même lot. Pitstop indique que les crédits ne sont débités qu’en cas de succès et sont automatiquement remboursés en cas d’échec sur sa page d’accueil. Vérifiez les conditions de la voie choisie.
Un prompt suffit-il ?
Non. Il peut être une instruction de l’exécution. Le brief doit aussi fixer entrées, format, limites, acceptation, accès, propriété et validation humaine.
Quand choisir un freelance ?
Ouvrez une discussion de développement si le résultat visé est un outil ou un workflow continu, avec connexions actives, exploitation, exigences changeantes ou maintenance. Gardez livrables et propriété explicites.
L’automatisation de rapports peut-elle être bornée ?
Oui, si sources, format, sections, marqueurs, lot et test d’acceptation sont fixes. La collecte récurrente ou la distribution active relève d’un workflow ou développement. Voir le guide sur l’automatisation de rapports.
Comment refuser vite une proposition vague ?
Posez quatre questions : que fournissons-nous ? Quel livrable exact revient ? Que l’exécuteur ne fera-t-il pas ? Comment notre relecteur l’acceptera-t-il ? Si une réponse reste indéfinie, la mission n’est pas prête.