Comment rédiger un brief IA : ce que votre agence a besoin de savoir pour bâtir la bonne solution
Votre brief détermine votre résultat
La qualité de ce que vous recevez d'une agence IA est directement proportionnelle à la qualité de ce que vous lui donnez. La plupart des briefs qu'on reçoit font trois lignes ou trente pages. Les deux posent problème.
Trois lignes, on n'a rien pour travailler. Trente pages, le vrai problème est enterré sous des spécifications techniques que personne n'a demandées. Les meilleurs briefs qu'on a reçus tenaient sur une seule page. Clairs, précis, centrés sur le problème.
Voici comment en rédiger un bon.
Pourquoi la majorité des briefs ratent la cible
Les briefs échouent de deux façons prévisibles.
La première : trop vague. « On veut de l'IA. » Ça ne nous dit rien. Quelle partie de l'entreprise? Quelle équipe? C'est quoi le blocage? « On veut de l'IA » c'est comme dire à un architecte « on veut un bâtiment. » Vrai, mais inutile.
La deuxième : trop prescriptif. « Construisez-nous un pipeline RAG avec GPT-4, des embeddings vectoriels et un modèle fine-tuné servi sur Kubernetes. » Ce n'est pas un brief. C'est une solution qui cherche un problème.
Le premier ne donne aucune direction. Le deuxième donne la mauvaise direction. Quand un client nous dit exactement quoi bâtir, il décrit généralement ce qu'il a lu la semaine d'avant. Pas ce dont son entreprise a réellement besoin. On a mis de côté des dizaines de spécifications techniques détaillées parce que la solution décrite n'aurait pas réglé le problème en question.
Votre job, c'est d'expliquer le problème. Notre job, c'est de trouver la solution.
Ce que votre brief devrait contenir
Un bon brief répond à six questions. C'est tout.
C'est quoi le problème? Soyez précis. « Notre équipe de vente passe 4 heures par jour sur la saisie de données » est utile. « On veut être plus efficaces » ne l'est pas. Chiffrez autant que possible. Heures perdues, revenus manqués, clients perdus, erreurs commises. Les chiffres rendent les problèmes concrets.
Qui est touché? Nommez l'équipe, le rôle, le département. « Nos trois gestionnaires de comptes » vaut mieux que « l'entreprise. » Plus vous êtes précis sur qui vit le problème au quotidien, mieux on peut concevoir quelque chose qui s'intègre dans leur vrai flux de travail.
Comment c'est géré aujourd'hui? Décrivez le processus actuel. Étape par étape. C'est là que se trouve la majorité de la valeur. On a besoin de comprendre ce que vos gens font vraiment, pas ce qu'ils sont censés faire. Incluez les solutions de fortune. Incluez les fichiers Excel dont personne n'est fier. Incluez les routines de copier-coller. Ce sont exactement ces choses-là qu'on corrige.
À quoi ressemble le succès? Décrivez le résultat que vous voulez. Pas l'outil. « Les gestionnaires de comptes passent moins de 30 minutes par jour sur la saisie » est une cible claire. « Un tableau de bord IA » ne l'est pas. On doit savoir ce que le succès veut dire pour vous afin de mesurer si on l'atteint.
Qu'avez-vous déjà essayé? Parlez-nous des outils testés, des processus modifiés, des fournisseurs consultés. Ça nous évite de recommander quelque chose que vous avez déjà écarté. Ça nous montre aussi ce qui n'a pas fonctionné et pourquoi. C'est parmi les informations les plus précieuses d'un brief.
Quel est votre échéancier et votre fourchette budgétaire? Pas besoin de chiffres exacts. Mais « on a besoin de ça avant le Q3 » est différent de « quelque part cette année. » Et $10K, c'est un projet différent de $100K. Connaître l'ordre de grandeur nous permet de dimensionner correctement au lieu de concevoir quelque chose que vous ne pouvez pas vous offrir ou de livrer en-deçà de vos besoins.
Ce qu'il faut laisser de côté
Les exigences techniques. C'est notre travail. Quand vous spécifiez que vous voulez GPT-4 plutôt que Claude, ou une base vectorielle plutôt qu'un graphe de connaissances, vous nous enfermez dans une solution avant qu'on comprenne le problème.
Les diagrammes d'architecture détaillés. Même raison. Vous ne remettriez pas un plan d'opération à votre chirurgien avant qu'il vous ait examiné.
Les préférences de modèles. Le modèle est un outil. On choisit le bon en fonction de votre cas d'usage, vos données, vos exigences de latence et votre budget. Ça change souvent. Ce qui était le meilleur choix il y a trois mois ne l'est pas forcément aujourd'hui.
Votre brief devrait être agnostique sur la technologie. Décrivez le monde dans lequel vous voulez vivre. Laissez-nous déterminer comment le construire.
Le cadre : Problème, Personnes, Processus, Preuve
Si vous cherchez une structure simple, utilisez celle-ci.
Problème. Un paragraphe. Qu'est-ce qui est brisé, lent, coûteux ou sujet aux erreurs? Mettez des chiffres.
Personnes. Qui est confronté à ce problème tous les jours? Quel est leur rôle? Combien sont-ils?
Processus. Comment gèrent-ils ça en ce moment? Prenez un exemple réel du début à la fin. Faites des captures d'écran d'une journée typique si c'est plus simple.
Preuve. Comment sauriez-vous que le problème est réglé? Qu'est-ce qui changerait? Quel indicateur bougerait?
Ça fait quatre paragraphes. Peut-être une page. Ça nous donne tout ce qu'il faut pour commencer.
Les signaux d'alarme dans votre propre brief
Relisez votre brief avant de l'envoyer. Cherchez ces signes.
Vous ne pouvez pas décrire le problème sans mentionner l'IA. Si le mot « IA » apparaît dans votre énoncé de problème, vous n'avez pas encore de problème. Vous avez une solution en quête d'un problème. Le problème devrait se tenir tout seul. « Notre équipe de support répond aux mêmes 40 questions 200 fois par mois » est un problème. « On a besoin d'un chatbot IA » n'en est pas un.
Le brief mentionne une solution avant un problème. Si le premier paragraphe décrit ce que vous voulez bâtir au lieu de ce qui ne va pas, inversez l'ordre. Commencez par la douleur. La solution vient après.
Il n'y a pas de chiffres. « C'est trop long » ne nous aide pas. « Ça prend 6 heures par semaine par personne dans une équipe de 12 » oui. Des problèmes vagues mènent à des solutions vagues.
Vous décrivez l'outil, pas le résultat. « On veut un tableau de bord » est un outil. « On veut voir la santé du pipeline sans aller chercher des données dans quatre systèmes » est un résultat. Concevez pour des résultats.
Chaque personne de votre équipe décrirait le problème différemment. Si votre VP ventes dit « on a besoin d'un meilleur scoring de leads », votre directeur techno dit « on a besoin d'un entrepôt de données » et votre PDG dit « on a besoin d'IA », le brief n'est pas prêt. Alignez-vous à l'interne avant de briefer à l'externe. Sinon, on résout trois problèmes différents et on livre quelque chose qui n'en satisfait aucun.
Pourquoi on commence par s'intégrer à votre équipe
C'est comme ça qu'on travaille chez Deadly. Avant d'écrire une seule ligne de code, on s'intègre à votre équipe. On observe comment vos gens travaillent. On assiste à des appels. On regarde les outils qu'ils utilisent vraiment, pas ceux qu'ils sont censés utiliser.
Le meilleur brief, c'est de regarder vos gens travailler. On voit les inefficacités qu'ils ont arrêté de remarquer. On repère les solutions de fortune devenues routinières. On trouve les problèmes qui valent la peine d'être résolus, pas juste ceux qui viennent en tête en premier.
Mais un bon brief écrit nous amène à 80% avant le jour un. Ça veut dire que nos premières conversations portent sur les détails au lieu de partir de zéro. Ça veut dire qu'on passe notre temps d'immersion à valider ce que vous nous avez dit, pas à tout découvrir sur place.
Pour mieux comprendre comment ça fonctionne en pratique, consultez notre processus.
Le test d'une page
Voici un test simple. Si votre brief fait plus d'une page, il contient probablement des solutions déguisées en exigences. Coupez. Concentrez-vous sur le problème, les personnes, le processus et la preuve.
Si votre brief fait moins d'une demi-page, il manque probablement de précision. Ajoutez des chiffres. Ajoutez le déroulement du processus actuel. Ajoutez ce que vous avez déjà essayé.
Le juste milieu, c'est une page qui nous fait dire « on sait exactement quoi aller regarder. » C'est le brief qui vous obtient la bonne solution. Pas juste une solution.
