Comment briefer une agence IA pour que le devis soit vraiment fiable

Un devis précis pour un projet IA sur mesure repose sur un brief qui répond à cinq questions : quel résultat business vous visez, quelles données vous avez réellement, ce que coûte une mauvaise réponse, quels systèmes l'agent doit lire et modifier, et quelles contraintes sont non négociables. Tout le reste — le modèle, le framework, et la question de savoir si c'est « un agent » ou « un workflow » — relève de la proposition de l'agence. Les fondateurs qui envoient un exposé du problème en deux pages reçoivent un chiffre. Ceux qui envoient une liste de fonctionnalités ou un vague « on veut de l'IA dans notre produit » reçoivent une fourchette tellement large qu'elle est inutile, ou un prix d'appel renégocié au deuxième mois.

Pourquoi la plupart des briefs IA produisent de mauvais devis

Une agence de développement tarifie le risque. Chaque inconnue dans votre brief se transforme soit en surestimation, soit en optimisme qui s'effondre dès que les vraies données arrivent. Les projets IA comportent plus d'inconnues que les projets logiciels classiques, parce que la difficulté ne réside presque jamais dans le code. Elle réside dans les données, les cas limites, et la définition de ce qui est « suffisamment bon ».

Les trois erreurs les plus fréquentes que nous rencontrons dans les briefs :

• La solution à la place du problème. « Créez un chatbot RAG sur notre documentation avec GPT et une base de données vectorielle. » L'agence doit alors reconstituer ce dont vous avez réellement besoin — et le design prescrit est souvent le plus onéreux. Nous en avons fait l'expérience nous-mêmes : la chaîne multi-étapes que nous avions envisagée pour notre propre outil de prospection s'est révélée moins bonne qu'un appel unique, tant en coût qu'en qualité. Un brief qui aurait imposé cette chaîne nous aurait verrouillés dans le moins bon design. Nous expliquons pourquoi cela compte dans RAG vs fine-tuning pour les fondateurs.
• Aucune définition de ce qui est correct. « Le système doit répondre précisément aux questions des clients. » Précisément par rapport à quoi ? Qui vérifie ? Que se passe-t-il en cas d'erreur ? « Juste neuf fois sur dix, avec le reste soumis à un humain » est une définition. « Précis » n'en est pas une.
• Les intégrations mentionnées en passant. « Ça devrait aussi mettre à jour le CRM. » Cette phrase peut doubler un projet. Un agent qui rédige une note CRM pour approbation humaine et un agent qui modifie lui-même les étapes d'une opportunité sont deux constructions différentes, et le brief ne précise généralement pas laquelle est visée. L'authentification, les limites de débit, le mapping des champs et la gestion des erreurs d'un système tiers représentent un vrai travail.

Corrigez ces trois points et le devis que vous recevrez sera proche de ce que vous paierez en réalité.

Les cinq sections indispensables de votre brief

1. Le résultat, exprimé en termes business

Un paragraphe. Pas « un assistant IA » mais « réduire le délai de première réponse aux demandes entrantes du support de plusieurs heures à moins de deux minutes, sans augmenter les escalades vers l'équipe humaine. » Un résultat mesurable permet à l'agence de proposer le design le moins coûteux qui l'atteint, plutôt que le plus impressionnant.

Indiquez les volumes. Cinquante requêtes par jour et cinquante mille par jour sont des systèmes différents avec des structures de coûts différentes. Si vous ne savez pas, donnez votre meilleure estimation et précisez que c'en est une.

2. Les données que vous avez réellement

Cette section détermine le prix plus que tout autre. Soyez précis et honnête :

• Où elles se trouvent. Postgres, un Google Drive plein de PDFs, un CRM legacy avec un bouton d'export, des fils WhatsApp sur le téléphone de quelqu'un.
• Combien et dans quel état. Dix mille enregistrements bien structurés, c'est un travail différent de deux cents formulaires scannés en trois langues.
• Qui en est propriétaire et si elles contiennent des données personnelles. Si le projet touche des données de résidents européens, dites-le. L'agence doit concevoir le système en tenant compte du RGPD dès le départ, pas le rajouter après coup.

Joignez un échantillon anonymisé. Vingt lignes ou dix documents suffisent. Aucune agence sérieuse ne peut estimer un travail d'extraction ou de récupération à partir d'une description en prose des données, et toute agence qui prétend le contraire improvise.

3. Le coût d'une mauvaise réponse

C'est la question que les fondateurs esquivent et que les agences ont le plus besoin de voir traitée. Une fonctionnalité IA qui suggère des tags pour des articles de blog peut se tromper un quart du temps sans conséquence. Un agent qui donne des prix à des clients ou traite des dossiers d'assurance ne peut pas se le permettre.

Indiquez en langage clair :

• Ce qui se passe quand la réponse est fausse. Embarras, remboursement, problème réglementaire, risque pour la sécurité d'un patient.
• Qui le détecte aujourd'hui. Un relecteur humain, personne, le client.
• Le taux d'erreur que vous accepteriez au lancement. Même un chiffre approximatif aide. « Si c'est juste neuf fois sur dix et que le reste est soumis à un humain, c'est mieux que ce qu'on a. »

Cette seule section détermine si l'agence conçoit un système peu coûteux avec un humain dans la boucle ou un système onéreux avec une vérification en couches. Notre article sur les garde-fous déterministes pour les fonctionnalités IA explique pourquoi le second type coûte plus cher et quand cela en vaut la peine.

4. Les systèmes que l'agent doit manipuler

Listez chaque système que l'IA doit lire ou modifier, et pour chacun : disposez-vous d'un accès API, qui l'administre, et existe-t-il un environnement de test. L'écriture coûte plus cher que la lecture. Un agent qui rédige une note CRM pour approbation humaine est un projet plus modeste que celui qui modifie lui-même les étapes d'une opportunité.

Si un système n'a pas d'API, précisez-le aussi. L'automatisation via navigateur et le scraping sont possibles, mais ce sont des postes budgétaires différents, et ils tombent en panne plus souvent.

5. Les contraintes non négociables

Ce à quoi l'agence ne peut pas déroger :

• Résidence des données. Doit rester dans l'UE, en Arabie saoudite, sur vos propres serveurs.
• Budget par requête ou par mois. Un plafond sur le coût d'inférence oriente immédiatement le choix du modèle.
• Latence. Une réponse WhatsApp peut prendre quatre secondes. Un agent vocal ne peut pas se le permettre.
• Délai et ce qui le justifie. Une date de salon professionnel est une vraie contrainte. « Dès que possible » n'en est pas une.
• Obligations légales ou d'information. Si les clients doivent être informés qu'ils parlent à une machine, dites-le.

Gardez cette liste courte. Chaque élément supprime des options de design, et certaines d'entre elles étaient les moins coûteuses.

Ce qu'il faut omettre

L'architecture. Ne spécifiez pas le modèle, la base de données vectorielle, le framework d'orchestration, ni le nombre d'étapes du pipeline. Lorsque nous avons développé notre propre outil de prospection — qui scrape le site de chaque prospect avec un crawler auto-hébergé et rédige un email personnalisé avec un modèle local — notre hypothèse de départ était une chaîne multi-étapes : un appel pour extraire les faits, un autre pour planifier, un autre pour rédiger. La version gagnante, tant en coût qu'en qualité, était un appel unique qui extrayait les faits et rédigeait l'email ensemble. Si un client avait prescrit la chaîne dans son brief, nous aurions construit le moins bon système et facturé davantage pour cela. Laissez l'agence proposer, puis challengez la proposition.

Une longue liste de fonctionnalités. Des fonctionnalités sans ordre de priorité sont toutes tarifées comme obligatoires. Si vous devez en lister, marquez-en trois comme indispensables au lancement et les autres comme ultérieures.

Des captures d'écran de concurrents comme cahier des charges. Utile comme référence, dangereux comme exigence. Vous finissez par payer pour reproduire les compromis de quelqu'un d'autre.

Ce qu'une bonne agence fera de votre brief

Reprenons l'exemple du support de la section un. Un brief indiquant « moins de deux minutes pour la première réponse, volume actuel d'environ cinq cents tickets par jour, juste neuf fois sur dix avec le reste soumis à un humain, doit rédiger mais pas envoyer, données UE uniquement » devrait donner lieu, en une à deux semaines, à une proposition qui répond précisément à ces lignes : une approche recommandée avec les justifications, un périmètre pilote (peut-être une catégorie de tickets, en mode brouillon uniquement), un coût décomposé en construction, inférence au volume indiqué et maintenance continue, ainsi qu'une méthode proposée pour mesurer l'objectif des deux minutes et le taux d'erreur d'un sur dix avant de payer le développement complet. Si la réponse est un chiffre unique sans hypothèses listées, l'agence n'a pas lu le brief. Si c'est un deck de trente pages qui ne mentionne jamais votre échantillon de données, même conclusion.

Attendez-vous aussi à recevoir des questions en retour. Les bonnes agences approfondissent la section sur le coût d'une mauvaise réponse et sur les intégrations, car c'est là que réside le vrai risque d'estimation. Attendez-vous à ce qu'on vous demande qui traite aujourd'hui le dixième cas soumis à un humain, et si le CRM dispose d'un environnement de test. Les agences qui ne posent aucune question sont soit très expérimentées dans votre problème exact, soit comptent sur votre facture pour découvrir les difficultés.

Avant de signer, utilisez comment évaluer la démo d'une agence IA pour challenger ce qu'elles vous montrent, et assurez-vous que la métrique de succès de la section un figure dans le contrat. Se mettre d'accord sur la manière dont le système sera évalué avant le début du développement est la meilleure assurance qui soit — et la moins chère.

Un modèle à copier

```

1. Outcome: what changes for the business, with a number and a volume.
2. Data: where it lives, how much, how clean, personal data yes/no. Sample attached.
3. Cost of wrong: what happens, who catches it today, acceptable error rate at launch.
4. Systems: each one, read or write, API access yes/no, sandbox yes/no.
5. Constraints: residency, cost ceiling, latency, hard dates, disclosure rules.
6. Not in scope for v1: the things you are consciously deferring.

```

Deux pages, plus les annexes. Un fondateur peut le rédiger en une après-midi, ce qui lui fait économiser des semaines d'allers-retours — ou un projet qui double silencieusement de prix.

Si vous avez un brief à moitié rédigé et souhaitez un regard extérieur avant de l'envoyer, ou si vous préférez d'abord en parler de vive voix, discutons-en.