Il n'est pas nécessaire de choisir le modèle ou l'architecture avant de contacter un prestataire. Il faut expliquer le travail attendu et les contraintes importantes.
Un brief court accompagné d'exemples réels est plus utile qu'une longue liste de fonctions sans définition du résultat acceptable.
Décrire le travail plutôt que la technologie
Au lieu de « nous voulons un agent IA », écrire : « Notre équipe reçoit des devis dans différents formats, copie les champs dans un tableau et vérifie les totaux incohérents. Nous cherchons à préparer ce tableau avec une revue claire. »
Le prestataire peut alors proposer une combinaison pertinente de logiciel classique, d'extraction, de recherche et de traitement par modèle.
Identifier les utilisateurs et les décideurs
Préciser qui utilise le résultat et qui approuve les choix produit. Distinguer, si nécessaire, le responsable du budget, le référent technique et le propriétaire des données.
Décrire le processus actuel, sa fréquence et ses difficultés. Lorsqu'une mesure existe, indiquer sa méthode et sa période. Sinon, signaler qu'il s'agit d'une estimation.
Fournir des exemples d'entrées et de sorties
Indiquer l'origine des données, les formats et les droits nécessaires. Inclure des cas courants et difficiles. Montrer pour chacun le résultat qu'une personne accepterait.
Ne pas envoyer d'informations confidentielles via un formulaire public. Convenir d'un canal et d'un périmètre d'accès avant de transmettre du contenu non public.
Délimiter une première version
Séparer le nécessaire des évolutions futures. Définir la tâche complète réalisable, les intégrations indispensables et les actions qui restent manuelles.
Par exemple : « La première version extrait les champs des devis, signale les exceptions et exporte un tableau après revue. Elle ne commande pas, ne négocie pas et ne modifie pas la comptabilité. »
Expliquer les contraintes et l'acceptation
Préciser les permissions, l'hébergement, les intégrations disponibles, les performances attendues et les responsabilités d'exploitation. Une contrainte est plus utile lorsque sa raison est connue.
L'acceptation porte sur des tâches représentatives et les échecs importants. Définir quand demander une précision, ne pas répondre ou transmettre à une personne.
Donner le contexte commercial
Indiquer le budget approximatif, le calendrier et les éventuelles échéances fixes. Préciser l'état du financement ou des validations achats. Le prestataire peut ainsi proposer une étape adaptée plutôt qu'un développement complet inapproprié.
Aborder la propriété, les frais tiers, le support et le transfert avant de s'engager.
Un modèle à reprendre
Problème : quel travail pose difficulté ?
Utilisateurs : qui utilisera le système et qui approuve le projet ?
Processus actuel : que se passe-t-il aujourd'hui et à quelle fréquence ?
Entrées : quels fichiers, systèmes et droits sont concernés ?
Sorties : quel résultat doit pouvoir être utilisé ou validé ?
Première version : qu'inclut-elle et qu'exclut-elle ?
Acceptation : quels exemples et conditions déterminent la réussite ?
Contraintes : données, intégrations, hébergement, calendrier et support.
Contexte commercial : budget, décisions et démarrage visé.
Questions ouvertes : que doit aider à déterminer le partenaire ?