Claude vous a écrit un cahier des charges IA : et maintenant ?

Écrit par la rédaction · 12 novembre 2026 · Mis à jour le12 novembre 2026

Un cahier des charges écrit par Claude ou ChatGPT est un bon premier jet de votre intention, pas la preuve que l'idée marche. Entre le cahier des charges, une démo de deux heures et un système que votre équipe utilise chaque semaine, le vrai travail porte sur vos propres données, sur les cas qui le font casser, sur une façon de mesurer qu'il est juste et sur quelqu'un qui le fait tenir. C'est le métier d'un forward deployed engineer, et c'est ce que nous faisons.

Vous avez décrit votre idée à Claude ou à ChatGPT, et quelques minutes plus tard vous tenez un cahier des charges exhaustif : des user stories, une architecture, une feuille de route, parfois même une page de tarifs. On a l’impression que le plus dur est fait. Nous connaissons ce sentiment, et il est réel. Ces outils transforment une idée en document structuré mieux que la plupart des gens. Ce que le document ne dit pas, c’est si ce qu’il décrit marchera sur vos données, avec vos équipes, un lundi matin.

À quoi sert un cahier des charges généré

Il met votre intention en mots en quelques minutes. Il trouve ce que vous aviez oublié de demander. Il vous donne de quoi briefer une équipe ou un prestataire. Lisez-le comme un premier jet de ce que vous voulez, pas comme la preuve qu’on peut construire ce qu’il promet.

Ce qui sépare le cahier des charges d’un produit qui marche

Il y a trois étapes, et elles sont éloignées : le cahier des charges, la démo, et le système que les gens utilisent.

Une démo prend un après-midi. Elle tourne sur un échantillon propre, suit le cas heureux et impressionne la salle. Un système que l’on utilise chaque semaine demande le travail que personne ne voit dans la démo :

• Les vraies données. Des documents rangés à cinq endroits, des noms écrits de trois façons, des droits d’accès qui diffèrent selon la personne.
• Les cas qui le font casser. Les exceptions que le cahier des charges n’a jamais mentionnées, et qui font l’essentiel du travail quotidien.
• Une façon de savoir qu’il est juste. Un jeu de cas réels, écrits avant de construire et rejoués après chaque modification. Anthropic le dit ainsi : « The key to success, as with any LLM features, is measuring performance and iterating on implementations. »
• Une personne qui valide. Ce que le système prépare, quelqu’un de votre entreprise l’approuve avant que cela parte.
• L’intégration et les droits. Quels outils il lit, qui voit quoi.
• L’hébergement et les données. Où il tourne, qui peut lire vos documents.
• L’entretien. Les modèles, les outils et vos propres process changent ; le système doit suivre.

Un exemple imaginé

Imaginons que vous ayez demandé un cahier des charges pour un agent qui répond aux mails clients. La démo répond aux cinq mails que vous avez choisis, et elle le fait bien. À la troisième semaine d’usage réel, l’agent tombe sur un mail écrit en deux langues, un fil transféré de onze messages, un client en colère, et une règle de remboursement qui a changé le mois dernier et n’existe que dans la tête d’un collègue. Rien de cela n’est dans le cahier des charges. Chaque cas demande une décision : ce que l’agent fait, ce qu’il refuse, ce qu’il passe à une personne, et comment vous le remarquerez la prochaine fois. Cette liste de décisions, c’est le produit.

Produit ou démo qui a bonne mine ?

Sept questions à poser à tout prototype, le vôtre compris :

1. Qui l’utilise chaque semaine, et qu’arrête-t-il de faire ?
2. Sur quels vrais documents ou données l’avez-vous testé, plutôt que sur un échantillon ?
3. Que se passe-t-il quand il se trompe ?
4. Comment mesurez-vous qu’il est juste, et sur quels cas ?
5. Qui le maintient dans six mois ?
6. Combien coûte son fonctionnement chaque mois ?
7. Qu’est-ce qu’il remplace, et les personnes concernées sont-elles d’accord ?

Si vous ne savez pas répondre à trois d’entre elles, vous avez une démo. C’est utile, et ce n’est pas encore un produit.

Parfois, la solution la plus simple est la bonne

Le conseil d’Anthropic sur la construction d’agents commence par là : « we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. » Un tableur, un outil que vous payez déjà ou un prompt bien écrit suffisent parfois. Le dire fait partie du travail.

Là où l’expertise change le résultat

Choisir la plus petite tranche qui vaut la peine d’être construite. Écrire les cas de test à partir de vos situations réelles. Se brancher à vos documents avec les bons accès. Mettre en production, puis suivre. C’est le travail d’un forward deployed engineer, et le faire bien demande de l’expérience.

Et chez nous ?

Nous sommes une agence IA en forward deployed. Le premier appel dure 30 minutes, il est offert et sans engagement. Vous autorisez l’accès à vos outils en deux clics, sans mot de passe, et deux semaines après l’appel un premier agent tourne pour que votre équipe le teste. Une personne de votre entreprise valide avant tout envoi, et un interlocuteur dédié suit le projet. Nous faisons des agents, et aussi des projets de machine learning et de données.

Si vous hésitez à le construire vous-même avec un GPT personnalisé ou un Projet Claude, voyez la page sur jusqu’où tient un GPT personnalisé ou un Projet Claude.