· 8 min de lecture

Des centaines de prompts plus tard, toujours pas de système fiable : pourquoi un projet d'agents IA a besoin d'un analyste d'affaires

Pourquoi les entreprises brûlent des requêtes IA après la préparation des données sans résultat fiable — et pourquoi la pièce manquante est une personne qui possède le processus et les tests.

Résumé

QuestionRéponse courte
Nous avons bien préparé nos données — pourquoi l’agent reste-t-il peu fiable ?Parce que la préparation corrige les entrées. Spécifier le processus — chaque exception, chaque cas limite — est un travail séparé que l’outil suppose déjà fait par quelqu’un
Donc les modèles ne sont pas assez bons ?Ils sont excellents et progressent (Claude Opus 5, GPT-5.x). Le goulot d’étranglement est passé du modèle à la spécification
Pour qui OpenAI construit-il ces outils ?Son lancement d’AgentKit le dit clairement : « développeurs et entreprises » — des gens déjà capables de spécifier un système
Que fait la personne manquante ?Elle arbitre les contradictions, tranche les cas limites, construit les tests d’acceptation et possède le processus de changement
Quand le DIY suffit-il ?Productivité personnelle, documents ponctuels, prototypes jetables
À quoi ressemble « terminé » ?Un système avec rôles, piste d’audit, tests et tableau de bord — voir la démo en direct sur demo.kamensky.dev

C’est la deuxième moitié d’une histoire. Dans la première, nous avons nettoyé les données : une grille tarifaire canonique, des statuts contrôlés, un processus documenté, un jeu de tests. Ce travail est réel et il porte ses fruits. Et pourtant, un nombre remarquable d’équipes cale ensuite pendant des mois au même endroit : prompts, re-prompts, des agents payés qui brillent en démo et lâchent le lundi.

L’échec n’est pas dans la préparation. Il est dans ce qu’aucun prompt ne peut fournir.

D’abord, le crédit qui est dû

Les outils sont devenus réellement bons. L’AgentKit d’OpenAI livre un Agent Builder visuel ; les GPT personnalisés se connectent à votre Drive ; les projets et espaces de travail de Claude ingèrent des documents et construisent des applications fonctionnelles ; les modèles de pointe continuent de grimper — Claude Opus 5 est arrivé en juillet 2026, explicitement optimisé pour les agents longue durée. Pour une personne technique, la distance de l’idée au prototype fonctionnel est tombée à quelques heures.

Relisez pourtant l’annonce d’AgentKit et notez l’audience : « un ensemble complet d’outils permettant aux développeurs et aux entreprises de créer, déployer et optimiser des agents ». Développeurs et entreprises. L’outil suppose que quelqu’un chez vous sait spécifier le système : quel est le processus, où vivent les exceptions, ce que « correct » signifie, ce qui se passe en cas d’échec. Si personne chez vous ne le peut — et dans une PME typique, personne ne le peut — l’outil ne supprime pas ce besoin. Il le laisse simplement vacant.

Sept modes de défaillance que davantage de prompts ne peuvent pas réparer

1. Quelqu’un doit arbitrer les contradictions. Votre directeur commercial dit que les retours sont de 14 jours ; votre responsable opérationnel dit 30 ; tous deux ont « raison » selon les segments de clients. Un agent doté des deux règles n’escalade pas le conflit — il en choisit une, invisiblement. La compétence centrale d’un analyste d’affaires est de transformer « les deux, ça dépend » en une règle écrite avec des exceptions nommées. Cette décision est du travail de gestion, pas de prompt.

2. Les cas limites sont le système. Le chemin heureux représente 20 % du processus et 100 % de la démo. La valeur est dans la longue traîne : le client à deux entités juridiques, la commande passée à 23 h 58 le 31 décembre, la livraison partielle, la réévaluation de devise en pleine facture. Ils ne sont dans aucun fichier — ils vivent dans la tête de vos deux personnes les plus expérimentées. Les extraire demande des entretiens, des tableaux blancs, des décisions. Les requêtes au modèle ne les font pas émerger ; les questions à vos équipes, si.

3. Lire est facile ; écrire en sécurité est de l’ingénierie. Les agents de chat lisent vos Sheets sans difficulté. Écrire en retour — sans créer de lignes en doublon quand deux personnes éditent simultanément, sans perdre une mise à jour quand le réseau tombe en pleine sauvegarde, sans que l’agent « serviablement » écrase un prix — exige des transactions, du verrouillage, de la gestion de conflits. Aucun produit de chat ne fait cela, car ce n’est pas un problème de chat ; c’est un problème de plateforme de données. (C’est le même mur que Sheets heurte à l’échelle, avec un nouveau chapeau.)

4. Sans boucle d’évaluation, impossible de distinguer « meilleur » de « différent ». Vous peaufinez le prompt ; les réponses changent. Sont-elles plus correctes ? Personne ne le sait, car il n’existe ni jeu de tests figé ni personne dont le métier est de mesurer. La boucle devient affaire de goût : prompt, plisser les yeux, re-prompt. Voilà comment naissent les « centaines de requêtes » — non parce que le modèle est faible, mais parce que rien ne définit le succès. Le jeu de tests issu de la préparation est la moitié de la solution ; l’autre moitié est une personne qui le déroule après chaque changement et signe le résultat.

5. Un processus métier doit tourner pareil à chaque fois. Les agents sont probabilistes ; votre service de commandes n’a pas le droit de l’être. « Il approuve généralement la bonne remise » n’est pas un standard opérationnel — c’est un rapport d’incident en quête de date. La fiabilité vient de l’enrobage de l’agent dans des rails déterministes : validation, nouvelles tentatives, idempotence, une piste d’audit de qui a changé quoi. Construire ces rails est de l’ingénierie autour de l’agent, pas une conversation avec lui.

6. Quelqu’un doit posséder le processus de changement. La grille tarifaire change mardi. Si les données de référence ont un propriétaire et une règle de mise à jour, l’agent redevient correct en quelques minutes. Sinon, il reste confiemment faux jusqu’à ce qu’un client le remarque. Tout système réel a besoin de ce propriétaire — une personne comptable du maintien de la vérité. Les éditeurs vous vendent l’agent ; le propriétaire n’est inclus dans aucune offre.

7. La confiance se gagne, puis se garde. Une équipe abandonne un système après environ deux mauvaises réponses, et elle a raison. Rebâtir la confiance exige exactement ce qu’apporte un analyste : l’incident passé en revue, la règle corrigée en un seul endroit, le test enrichi de ce cas, et la correction démontrée — pas un autre prompt plein d’espoir.

L’économie de l’itération par prompts

Itérer sur des prompts semble gratuit parce que chaque requête est bon marché. Ça ne l’est pas : aux tarifs au compteur des outils de chat, un classeur de 40 onglets relu par session plus le prompting exploratoire évolue avec l’activité, pas avec les résultats — et le vrai coût, ce sont les mois où votre équipe opérationnelle vit à moitié dans l’ancien processus, à moitié avec l’agent. L’alternative n’est pas un meilleur prompt. C’est une spécification : le document de processus, le registre des cas limites, le jeu de tests et les critères d’acceptation issus de la checklist de préparation — produits une fois, par une personne, en quelques semaines — après quoi les agents deviennent bon marché et fiables.

Pourquoi le rôle manquant est d’abord un analyste d’affaires

Remarquez : sur les sept modes de défaillance ci-dessus, seuls les nº 3 et 5 relèvent substantiellement de l’ingénierie. Les cinq autres sont de l’analyse d’affaires : arbitrer les règles, extraire le savoir non écrit, définir une correction mesurable, posséder les données de référence, conduire l’acceptation. C’est pourquoi « embaucher un prompt engineer » sauve si rarement ces projets — le goulot n’a jamais été les prompts.

C’est aussi la description honnête de mon métier. J’ai passé 17 ans à l’intérieur des opérations métier avant de construire du logiciel : diplôme d’économie, analytique industrielle, analyse d’affaires, automatisation SAP et Excel dans de vraies entreprises. Aujourd’hui, je conduis cette discipline de découverte comme étape un de chaque projet d’automatisation — puis je construis les agents et la plateforme autour, pour que le résultat ait des rôles, des permissions, une piste d’audit, des sauvegardes et une suite de tests. Le même processus, appliqué à vos données, est visible de bout en bout sur demo.kamensky.dev : le pipeline de migration, la plateforme d’opérations authentifiée que votre équipe utiliserait vraiment, et le tableau de bord qui affiche les heures et les dollars.

Si votre équipe est coincée dans la boucle des prompts, le prochain pas le moins cher n’est pas une requête de plus. Réservez une appel de cadrage de 20 min — apportez le processus qui fait mal ; vous repartirez en sachant si c’est un problème de données, de spécification ou de plateforme, et ce que chacun coûte à corriger.

Quand le faire soi-même suffit vraiment

La frontière honnête : productivité personnelle (résumer, rédiger, traduire), questions analytiques ponctuelles sur un fichier propre unique, et prototypes jetables qui valident une idée avant d’investir. Pour cela, les outils intégrés sont excellents et cet article ne s’applique pas. Dès qu’un processus tourne chaque semaine, touche de l’argent ou des clients, ou exige que deux personnes s’accordent sur les chiffres — le rôle manquant apparaît, prévu ou non.

Sources et lectures complémentaires