Cadrer un projet d'application web avec l'IA : la chaîne de 6 prompts (de l'idée au SOW)

Cadrer un projet d'application web avec l'IA : la chaîne de 6 prompts (de l'idée au SOW)

Sur nos cinq derniers cadrages clients, la phase qui prenait habituellement 12 à 16 heures d'appels découverte est tombée à environ 3 heures de travail IA plus 1 heure de relecture humaine. On tourne tout ça dans un seul Claude Project pour que le contexte se propage d'une étape à l'autre. Le hic ? L'IA a fait les mêmes trois erreurs à chaque fois. On a donc ajouté une porte de validation humaine avant que quoi que ce soit n'arrive au client.

Voici la chaîne de 6 prompts qu'on utilise, le livrable que chaque prompt produit, un exemple complet travaillé, et les modes de défaillance à surveiller soi-même.

L'IA peut-elle cadrer un projet d'application web ? Oui. Elle peut rédiger un cahier des charges complet (énoncé du problème, user stories, fonctionnalités, priorités MoSCoW et un statement of work) en quelques heures plutôt qu'en plusieurs jours. Ce qu'elle ne peut pas faire, c'est valider ce brouillon. Elle invente des exigences et sous-estime l'effort — la validation humaine est donc obligatoire avant toute signature.

Points clés

• L'IA produit un cahier des charges complet en quelques heures, mais ne peut pas valider sa propre production.
• La chaîne comporte six prompts : problème, user stories, fonctionnalités, MoSCoW, estimation, SOW.
• L'IA invente des intégrations et sous-estime les cas limites — la porte de validation humaine est non négociable.
• Utilisez Claude Projects ou ChatGPT Projects pour la chaîne ; les agents viennent après la signature du périmètre.

L'IA peut rédiger votre premier brouillon de cadrage en une après-midi. Elle ne sait juste pas quand elle se trompe.

Qu'est-ce que le cadrage assisté par IA (et ce que ce n'est pas) ?

Le cadrage assisté par IA consiste à utiliser une série de prompts LLM pour transformer une idée brute en livrables de périmètre structurés : exigences, user stories, liste de fonctionnalités, priorités et un statement of work. L'IA se charge de la rédaction et de la structuration. Un humain s'occupe toujours des décisions, des conversations avec les parties prenantes et de la validation.

Alors, est-ce que l'IA pense à votre place ? Pas vraiment. Elle est rapide pour le recueil d'exigences IA, la partie où vous fixez une page blanche en essayant de traduire « je veux une appli de réservation » en quelque chose qu'un développeur peut chiffrer. Elle est mauvaise pour distinguer ce que le client veut vraiment de ce qui semble plausible.

Quelques précisions sur ce que le cadrage assisté par IA n'est pas : il n'est pas autonome, il ne remplace pas les discussions avec de vraies parties prenantes, et il n'est pas une garantie d'exactitude. Le modèle rédigera avec plaisir une spécification confiante et bien formatée pour une fonctionnalité que personne n'a demandée.

Cet article suppose que vous comprenez déjà le processus de cadrage lui-même. Si vous souhaitez les fondamentaux, notre guide de cadrage pas à pas couvre le processus non-IA, les 7 étapes et la structure complète du document de périmètre. Ici, on reste sur la couche IA : quel prompt, dans quel ordre, et où ça casse.

La chaîne de prompts de cadrage IA en un coup d'œil

La chaîne comporte six prompts exécutés en séquence, chacun alimentant le suivant avec son résultat. Dans l'ordre : (1) problème et objectifs, (2) user stories, (3) liste de fonctionnalités, (4) priorisation MoSCoW, (5) estimation de l'effort, du coût et du calendrier, et (6) le brouillon de SOW. Lancez-les dans un seul projet pour que le contexte persiste.

Le point intéressant : comme chaque prompt s'appuie sur le précédent, vous n'avez pas à réexpliquer votre application six fois. Le modèle connaît déjà le problème quand il rédige les user stories, et il connaît déjà les stories quand il priorise les fonctionnalités.

1. Problème & objectifs : transforme une idée brute en énoncé du problème et objectifs SMART.
2. User stories : convertit les objectifs en user stories avec critères d'acceptation.
3. Liste de fonctionnalités : tire un inventaire concret de fonctionnalités à partir des stories.
4. Priorisation MoSCoW : classe les fonctionnalités en Must, Should, Could, Won't.
5. Estimation : produit une estimation d'effort, une fourchette de coût et un calendrier.
6. Brouillon de SOW : assemble tout cela en un statement of work.

C'est aussi un ensemble propre de prompts IA pour la gestion de projet en général, mais on a adapté chaque prompt spécifiquement aux applications web (stack technique, intégrations, cas limites). C'est cette adaptation qui sépare un cadrage utilisable d'un générique.

L'astuce, ce n'est pas un prompt magique. Ce sont six prompts qui se transmettent leurs résultats.

Comment exécuter la chaîne, étape par étape ?

Vous exécutez la chaîne de haut en bas dans un seul Claude Project ou ChatGPT Project, en collant chaque prompt dans l'ordre et en laissant la réponse précédente en contexte. Voici les six étapes avec les prompts exacts que nous utilisons. Chacun est adapté aux applications web délibérément, parce que des prompts d'analyse métier génériques produisent des périmètres génériques.

Une note avant de commencer : remplacez les espaces réservés entre crochets par vos propres détails, et n'acceptez jamais la première production comme définitive. Le bon réflexe : lisez chaque résultat, corrigez-le, puis lancez le prompt suivant.

Prompt 1 : Énoncé du problème et objectifs

You are a senior product manager scoping a web application.
Here is the rough idea: [describe the app in 2-4 sentences].
The target users are [who]. The business wants [outcome].

Write:
1. A one-paragraph problem statement.
2. 3-5 SMART goals with success metrics.
3. 3 assumptions you are making that I should confirm.
Flag anything that is unclear instead of guessing.

Cela produit la section vue d'ensemble et objectifs. Conseil pro : la ligne « 3 assumptions » fait un gros travail. Elle fait remonter les lacunes que l'IA aurait sinon comblées en inventant.

Prompt 2 : User stories

Acting as the same product manager, turn the goals above into
user stories for a web app. Use the format:
"As a [role], I want [action], so that [benefit]."
Cover every user role. For each story, add 2-3 acceptance
criteria. Group stories by feature area.

Vous obtenez maintenant les exigences fonctionnelles. C'est l'étape de génération de user stories IA. Point de vigilance : l'IA oublie souvent les rôles admin et les cas limites — relancez-la avec « maintenant ajoutez des stories pour les admins, les paiements échoués et les états vides ».

Prompt 3 : Liste de fonctionnalités

Based on the user stories above, produce a flat feature
inventory for this web app. Group features into: core, account
and auth, admin, integrations, and notifications. Note any
feature that requires a third-party service or API.

C'est votre liste candidate de fonctionnalités dans le périmètre. Surveillez cette étape de près, car c'est là que l'IA commence à inventer des intégrations (on y revient plus loin).

Prompt 4 : Priorisation MoSCoW

Prioritize the feature list using MoSCoW (Must, Should, Could,
Won't) for a first release (MVP). For each feature give a
one-line reason. Assume a 3-month MVP budget and be ruthless:
most features should NOT be "Must."

Cela étiquette vos éléments dans le périmètre et hors périmètre. L'instruction « soyez impitoyable » est importante ; sans elle, le modèle classe presque tout en Must.

Prompt 5 : Estimation de l'effort, du coût et du calendrier

Estimate effort, cost, and timeline for the Must-have features
only. Assume a stack of [e.g. Next.js, Supabase, Stripe] and a
team of [N] developers. Break the estimate down by feature in
days. State every assumption. Give a cost RANGE, not a single
number, and flag the 3 riskiest estimates.

C'est l'entrée du générateur de cahier des charges IA pour le budget et le calendrier. Exigez toujours une fourchette et les hypothèses, car un chiffre unique et confiant est la sortie la plus dangereuse que l'IA puisse vous donner.

Prompt 6 : Brouillon de SOW

Assemble everything above into a draft statement of work for a
client. Include: overview, goals and success metrics, in-scope
features, explicit out-of-scope items, timeline, budget range,
deliverables, assumptions, and a sign-off section. Mark any
section where you are uncertain with [REVIEW].

Les balises [REVIEW] deviennent la liste de contrôle de votre porte de validation humaine. Cette étape assemble le passage idée-vers-SOW que l'ensemble de la chaîne promettait.

Correspondance prompt → section du document

Chaque prompt ne répond pas seulement à une question — il remplit une section précise du document que vous remettez au client. Cette correspondance remplace le modèle habituel en 11 sections : au lieu de mémoriser un squelette, vous lancez la chaîne et le document s'assemble tout seul. Voici quel prompt produit quel livrable.

À la fin du Prompt 6, vous avez un premier brouillon complet d'un document qu'un client peut vraiment lire et signer — pas une pile de notes déconnectées.

Chaque prompt ne répond pas seulement à une question. Il remplit une section précise du document que vous remettrez au client.

Un exemple complet travaillé : cadrage d'un SaaS de prise de rendez-vous

Voici la chaîne exécutée de bout en bout sur un cas concret : un SaaS de prise de rendez-vous pour une petite chaîne dentaire. C'est un exemple illustratif, pas un livrable client réel — et oui, on a trouvé deux erreurs dans la production IA, corrigées dans la section porte de validation ci-dessous.

Sortie du Prompt 1 (problème & objectifs). Problème : une chaîne dentaire de trois sites perd des réservations à cause du téléphone et des absences. Objectifs : réduire les absences de 30 % grâce aux rappels, permettre aux patients de réserver en ligne, et donner au personnel de réception un calendrier partagé unique. Hypothèses signalées : fuseau horaire unique, anglais uniquement, pas de facturation d'assurance.

Sortie du Prompt 2 (exemples de user stories).

• En tant que patient, je veux prendre rendez-vous en ligne, pour ne pas avoir à appeler.
• En tant que patient, je veux un rappel par SMS, pour ne pas oublier mon rendez-vous.
• En tant que membre du personnel de réception, je veux voir les trois sites dans un seul calendrier, pour gérer les chevauchements.

Sortie du Prompt 3 (liste de fonctionnalités, condensée). Réservation en ligne, synchronisation du calendrier, rappels SMS et e-mail, comptes patients, administration multi-sites, reporting de base, et une étape paiement (cette dernière a été inventée — personne ne l'avait demandée).

Sortie du Prompt 4 (grille MoSCoW).

Sortie du Prompt 5 (estimation, condensée). En supposant Next.js, Supabase et Twilio avec deux développeurs : fonctionnalités Must à environ 45-60 jours-développeur, fourchette de coût autour de 35 000-55 000 $, calendrier de 8 à 10 semaines. Estimation la plus risquée signalée : la logique du calendrier multi-sites.

Sortie du Prompt 6 (extrait de SOW). « Dans le périmètre : réservation en ligne, calendrier partagé multi-sites, rappels SMS (Twilio), comptes patients. Hors périmètre : paiements, assurance, appli mobile native. Calendrier : 8-10 semaines. Fourchette budgétaire : 35 000-55 000 $. [REVIEW] Confirmer Twilio vs alternative SMS avec le client. »

Parcourez ça et vous voyez un périmètre réel et signable prendre forme en une seule session. Si vous envisagez d'ajouter des fonctionnalités intelligentes par la suite, notre guide sur l'ajout de fonctionnalités IA à votre appli prend le relais là où celui-ci s'arrête.

Comment estimer le coût et le calendrier avec l'IA ?

Vous demandez au modèle de décomposer l'estimation par fonctionnalité en jours, de supposer une stack technique précise, d'énoncer toutes ses hypothèses et de renvoyer une fourchette plutôt qu'un chiffre unique. Ensuite, vous vérifiez cette fourchette par rapport aux niveaux de marché connus, car l'IA ancre presque toujours ses estimations trop optimistement sur l'effort.

Traitez les estimations IA comme un point de départ, jamais comme un devis. L'instruction la plus utile est « signalez les trois estimations les plus risquées », ce qui vous dit exactement où dépenser votre propre jugement. Voici les niveaux auxquels on confronte chaque estimation IA.

Ces fourchettes s'alignent sur les benchmarks publiés par les agences et les places de marché ; les recherches de Clutch sur le coût de développement d'applications constituent une référence publique raisonnable. Si votre estimation IA tombe bien en dessous du niveau correspondant, elle a probablement raté des cas limites. C'est aussi le moment de poser la question plus large : build vs buy. Un périmètre qui dépasse largement le niveau complexe plaide parfois pour l'achat plutôt que la construction.

Quel outil IA utiliser pour chaque étape ?

Pour la chaîne complète, utilisez Claude Projects ou ChatGPT Projects, car les deux persistent le contexte entre les prompts pour que les résultats se transmettent sans recopier. N'utilisez un agent autonome qu'après la signature du périmètre, quand vous générez des artefacts répétables. Pour un cadrage ponctuel, Projects l'emporte sur un agent à chaque fois.

On exécute la chaîne dans Claude Projects pour les étapes à long contexte (user stories, assemblage du SOW) et on se tourne vers ChatGPT quand on veut un deuxième avis sur l'estimation. Selon la documentation Projects d'Anthropic, un Project maintient un contexte et des instructions partagés tout au long d'une conversation — exactement ce dont un workflow claude projects pour les exigences en six prompts a besoin. Les Projects d'OpenAI fonctionnent de la même façon pour les prompts ChatGPT développement logiciel.

Une technique qui vaut la peine d'être copiée : alternez le rôle de l'IA selon l'étape. Dites-lui « agis en tant que product manager » pour les user stories et « agis en tant qu'ingénieur senior » pour l'estimation. Le changement de rôle modifie son raisonnement, et le persona ingénieur est nettement plus conservateur sur l'effort.

Une fois le périmètre livré et la construction lancée, la question d'outillage bascule vers les agents de codage IA — une décision entièrement différente.

Où l'IA se trompe-t-elle dans le cadrage ? La porte de validation humaine

L'IA se trompe dans le cadrage de façon prévisible : elle hallucine des intégrations que personne n'a demandées, sous-estime les cas limites et les états d'erreur, et soit invente des exigences de conformité, soit omet silencieusement des exigences réelles. Elle ancre aussi les estimations de coût trop optimistement. Rien de tout cela n'est rare — cela arrive à pratiquement chaque exécution, d'où le caractère non négociable de la porte de validation humaine.

Les mauvaises exigences coûtent cher, qu'elles soient écrites par un humain ou un modèle. Les recherches Pulse of the Profession du PMI ont établi qu'un recueil d'exigences inexact est une cause principale d'échec de projet dans environ 37 % des projets échoués — l'objectif de la porte, c'est de détecter ces manques avant qu'ils n'atteignent un devis, pas après.

Le correctif est une courte liste de contrôle qu'un humain passe en revue avant que tout périmètre n'arrive à un client :

• Supprimez les fonctionnalités inventées : retirez tout (paiements, exports, intégrations) que le client n'a jamais demandé.
• Ajoutez les cas limites manquants : paiements échoués, états vides, permissions, gestion des erreurs.
• Vérifiez chaque intégration : confirmez que chaque service tiers nommé est réel, nécessaire et budgété.
• Vérifiez les affirmations de conformité : confirmez ou corrigez toute exigence d'authentification, de confidentialité ou réglementaire que l'IA a énoncée.
• Ajustez l'estimation : corrigez les chiffres optimistes par rapport à votre propre vélocité, en particulier les estimations risquées signalées.

L'IA cadrера avec confiance un flux de paiement qu'elle a inventé. Votre travail est de supprimer ce que personne n'a demandé.

Ce qu'on a appris en appliquant cela sur de vraies missions client

Sur nos dernières missions de cadrage client, la phase découverte qui prenait autrefois environ 12 à 16 heures d'appels et de rédaction produit maintenant un SOW en première ébauche en 2 à 3 heures de travail IA plus 1 heure de relecture humaine. Ce sont des fourchettes réelles tirées de nos propres runs, pas un chiffre-titre précis — et l'heure humaine est celle qu'on ne supprimera jamais.

On exécute la chaîne dans Claude Projects, avec ChatGPT comme contrôle de cohérence sur les estimations. Le temps gagné est réel, mais la valeur réside dans le fait de toujours trouver les mêmes trois défaillances :

1. Elle invente des intégrations. Une étape paiement dans l'exemple dentaire que personne n'avait demandée. Presque chaque périmètre comportait au moins une fonctionnalité fantôme.
2. Elle sous-estime les cas limites. Les états d'erreur, les états vides et les flux admin sont systématiquement absents ou sous-comptés — c'est là que les vrais budgets explosent.
3. Elle gère mal la conformité et l'authentification. Parfois elle hallucine une exigence, parfois elle en omet une réelle. On ne lui fait jamais confiance là-dessus.

On a donc ajouté la porte de validation humaine ci-dessus comme étape fixe. La chaîne rédige le brouillon vite ; la porte est ce qui le rend sûr à envoyer. Passez la porte et vous expédiez juste une supposition confiante et bien formatée.

Comment Techsy aborde le cadrage assisté par IA

Cette chaîne plus la porte de validation humaine est le workflow exact qu'on applique pour les clients qui construisent des applications web. On rédige vite avec l'IA, puis une personne qui a livré de vraies constructions valide chaque ligne avant que cela ne devienne un devis. Si vous préférez confier le cadrage à une équipe qui le fait tous les jours, c'est ce qu'on fait. Vous obtenez un SOW défendable sans payer deux semaines d'appels découverte au préalable.

Foire aux questions

L'IA peut-elle rédiger un périmètre de projet ou un SOW ?

Oui, l'IA peut rédiger un cahier des charges complet ou un statement of work, incluant le problème, les user stories, les fonctionnalités, les priorités, le calendrier et la fourchette budgétaire. Exécutez une chaîne de six prompts dans un Claude ou ChatGPT Project. Le brouillon est fiable comme point de départ, mais un humain doit le valider avant toute signature.

Quel est le meilleur outil IA pour cadrer un projet logiciel ?

Claude Projects et ChatGPT Projects sont les meilleurs outils pour le cadrage, car les deux persistent le contexte tout au long de la chaîne de prompts pour que chaque résultat alimente le suivant. On utilise Claude Projects pour les étapes à long contexte comme les user stories et l'assemblage du SOW, et ChatGPT comme deuxième avis sur les estimations. Les agents sont mieux adaptés au travail de construction post-périmètre.

Comment utiliser ChatGPT ou Claude pour recueillir des exigences ?

Exécutez la chaîne de prompts dans l'ordre : demandez un énoncé du problème et des objectifs, puis des user stories avec critères d'acceptation, puis une liste de fonctionnalités, puis les priorités MoSCoW. Gardez tout dans un seul Project pour que le contexte se propage. La production de chaque prompt devient l'entrée du suivant — c'est ce qui rend le recueil d'exigences IA rapide.

L'IA peut-elle estimer le coût et le calendrier d'un projet logiciel ?

Oui, comme point de départ uniquement. Demandez au modèle de décomposer l'estimation par fonctionnalité en jours, de supposer une stack précise, d'énoncer ses hypothèses et de renvoyer une fourchette. Vérifiez ensuite par rapport aux niveaux de marché : 10 000-50 000 $ pour un MVP simple, jusqu'à 150 000 $+ pour des applis complexes. L'IA ancre systématiquement trop optimistement.

Le périmètre généré par l'IA est-il vraiment fiable ?

Fiable pour un premier brouillon, pas pour une signature. L'IA produit rapidement un périmètre bien structuré, mais elle invente des intégrations, sous-estime les cas limites et gère mal la conformité sur pratiquement chaque exécution. Traitez la production comme un brouillon rapide, puis passez une porte de validation humaine pour supprimer les fonctionnalités inventées et ajouter les cas limites manquants avant que quiconque signe.

Comment transformer une idée brute en spec avec l'IA ?

Commencez par le Prompt 1 : collez votre idée en deux à quatre phrases et demandez à l'IA de rédiger un énoncé du problème, des objectifs SMART et les hypothèses qu'elle pose. Puis exécutez les cinq prompts suivants dans l'ordre. Au Prompt 6, vous avez un brouillon de SOW. La chaîne complète prend quelques heures plutôt que plusieurs jours.

Le cadrage assisté par IA remplace-t-il une phase de découverte ?

Non, il compresse la découverte plutôt qu'il ne la remplace. Vous avez toujours besoin de vraies conversations avec les parties prenantes pour savoir ce que le client veut réellement. L'IA s'occupe de la rédaction et de la structuration, transformant vos notes en exigences et en SOW en quelques heures. Les humains valident, priorisent et prennent les décisions finales sur le périmètre.

Combien de temps prend le cadrage d'une application web avec l'IA ?

Dans notre expérience, un SOW en première ébauche prend environ 2 à 3 heures de travail IA plus environ 1 heure de relecture humaine, contre 12 à 16 heures de découverte et de rédaction manuelle. Le temps IA est rapide ; l'heure de relecture est non négociable, car c'est là qu'on détecte les fonctionnalités que l'IA a inventées et les cas limites qu'elle a ratés.