Gains :
- Capacité à transformer des demandes commerciales vagues en exigences logicielles et en témoignages d'utilisateurs clairs et testables avec prise en charge de l'IA
- Capacité à comparer les avantages et les inconvénients de la conception de systèmes, du modèle de données et des décisions architecturales de manière structurée avec l'IA
- Capacité à valider de manière critique la conception proposée par l'IA par rapport aux exigences, à l'évolutivité et aux contraintes
La majorité des projets logiciels échouent non pas à cause d’un mauvais code, mais à cause d’exigences mal comprises. Une requête d'une seule phrase telle que « Autoriser les utilisateurs à télécharger les rapports » laisse derrière elle des dizaines de questions sans réponse : dans quel format ? Qui est responsable ? Combien d'enregistrements ? Et si c'est lent ? L'analyse des besoins (traduire une demande métier en besoins techniques clairs et testables) et la conception logicielle (construire la structure sur papier pour répondre à ces besoins) sont l'étape où les erreurs les plus coûteuses sont évitées avant d'écrire le code. Dans cette unité, nous apprendrons à utiliser l’IA comme un « partenaire de réflexion » à ce stade : un partenaire qui démystifie l’incertitude, trie les options, mais vous laisse la décision finale.
L'IA produit ici deux grandes valeurs. Premièrement, il pose des questions que vous sautez ; Il fait ressortir les hypothèses cachées et les cas extrêmes dans une requête. Deuxièmement, il répertorie rapidement les avantages et les inconvénients d’une décision de conception. Mais c'est là le danger : l'IA donnera des recommandations génériques comme « bonnes pratiques » sans connaître parfaitement votre contexte (budget, équipe, système existant, contrainte légale). Il est de votre devoir de filtrer ces conseils par rapport à votre propre vérité.
Concepts : User story : Une courte phrase exprimant un besoin sous la forme de "... comme, je veux pouvoir... parce que...". Critères d'acceptation : Conditions testables qui doivent être remplies pour qu'un travail soit considéré comme « terminé ». Exigence non fonctionnelle : Exigences liées à « comment il se comportera » plutôt qu'à « ce qu'il fera », comme la vitesse, la sécurité, l'évolutivité.
De la demande vague à l'exigence testable
Une bonne exigence est mesurable et vérifiable. Non pas "laissez le système être rapide", mais "laissez les résultats de la recherche revenir dans les 500 ms". Voici une manière étape par étape d'utiliser l'IA pour réduire l'incertitude :
- Donnez la demande telle quelle et faites générer la question. Ne demandez pas à l'IA la solution, mais d'abord "énumérez tout ce qui n'est pas clair dans cette demande sous forme de question".
- Vous donnez les réponses. Vous seul connaissez le contexte ; Répondez aux questions de l'IA avec vos réelles contraintes métiers.
- Faites-le traduire en user stories et en critères d’acceptation. Traduisez le besoin clarifié en éléments testables.
- Ajoutez des cas limites et des scénarios négatifs. "Résultat vide", "utilisateur non autorisé", "fichier trop volumineux", etc.
Invite d'extraction d'ambiguïté : "Nous traduirons la demande commerciale suivante en exigence logicielle. Ne proposez pas encore de solution. Tout d'abord, extrayez TOUTES les ambiguïtés et hypothèses cachées qui ne trouvent pas de réponse dans cette demande sous forme de liste de questions. Regroupez les questions sous les titres suivants : portée, utilisateur/autorité, volume de données, performances, conditions d'erreur, sécurité. Requête : "Autoriser les utilisateurs à télécharger l'historique des commandes sous forme de rapport."
Invite de user story + critères d'acceptation : "Divisez le besoin clarifié suivant en user stories conformes aux principes INVEST. Écrivez 3 à 5 critères d'acceptation testables pour chaque story (au format Given-When-Then). Ajoutez au moins 2 scénarios négatifs (accès non autorisé, données vides). Besoin : [écrire le besoin clarifié ici]"
Comparer les décisions de conception avec l'IA
La conception est un compromis constant : vitesse contre flexibilité, simplicité contre évolutivité ? L'IA met ces compromis dans une feuille de calcul rapide. Par exemple, pour une fonctionnalité « envoyer une notification », vous pouvez débattre de l'opportunité d'utiliser une approche synchrone (envoi sur demande) ou asynchrone (file d'attente, envoi en arrière-plan).
Invite de comparaison de conception : "Je conçois une fonctionnalité 'envoyer une notification par email à l'utilisateur'. Comparez les deux approches : (A) livraison synchrone lors de la requête HTTP, (B) livraison asynchrone en arrière-plan en la mettant dans la file d'attente des messages. Faites un tableau sur les axes suivants : temps d'attente de l'utilisateur, tolérance aux pannes, complexité, coût de l'infrastructure, difficulté de débogage. Résumez en 2 phrases laquelle je choisirais au final auquel cas. Ne prenez pas la décision à ma place."
axe
transmission synchrone
Asynchrone (file d'attente)
Temps d'attente des utilisateurs
Long (en attente d'expédition)
Court (retourne immédiatement)
Tolérance aux pannes
Faible (la demande explose si l'envoi explose)
Élevé (réessayez possible)
complexité
faible
Moyen-élevé (infrastructure de file d'attente)
Coût des infrastructures
faible
Composants supplémentaires requis
Où ça correspond
Faible volume, application simple
Volume élevé, livraison critique
Astuce : Dire à l'IA « ne prends pas la décision à ma place, montre-moi simplement les options et les conditions » vous oblige à réfléchir et réduit le risque d'accepter aveuglément une suggestion. La meilleure décision de conception est celle prise par la personne qui connaît votre contexte (vous).
Invite faible/Invite forte
FAIBLE : "Concevoir une base de données pour le système de commande." (Résultat : quelle échelle, quelles relations, quelles contraintes ne sont pas claires ; un schéma général et irréaliste.) FORT : "Suggérez un projet de modèle de données pour un petit commerce électronique. Entités : client, commande, produit, article de commande. Contraintes : il peut y avoir plusieurs produits dans une commande ; le prix du produit peut changer au fil du temps, mais le prix actuel doit être conservé dans la commande passée ; environ 500 commandes par jour sont attendues. Relations et pourquoi " Expliquez que vous avez pris la décision. Précisez comment vous avez résolu le problème de l'historique des prix. Donnez-le sous forme de liste d'entités et de champs, pas de code."
La différence d'une invite puissante ; échelle (500 commandes par jour), règle métier (le prix passé doit être conservé) et format de sortie souhaité. Une seule phrase comme « Le prix passé doit être maintenu » change complètement la conception ; Si vous ne le précisez pas, l'IA produira un diagramme inexact mais plausible.
Mini-étuis
Cas 1 — Hypothèse cachée. Une équipe code directement la demande « l’utilisateur peut télécharger une photo de profil ». Une autre équipe a interrogé l'IA sur l'incertitude : "taille maximale ? formats autorisés ? contrôle de contenu inapproprié ? supprimer l'ancienne photo ?" Il produit 8 questions comme. La première équipe prend connaissance du problème en production lorsque des fichiers de 20 Mo remplissent le serveur ; La deuxième équipe le résout dans la conception.
Cas 2 — Hypothèse d'échelle incorrecte. AI propose une couche de mise en cache complexe pour une fonctionnalité de reporting. Lorsque l’ingénieur souligne que les données réelles ne représentent que 30 rapports par jour, l’IA simplifie la suggestion. Ne pas préciser l’échelle entraîne le coût d’une complexité inutile ; spécifier permet d'économiser 2 semaines de travail inutile.
Cas 3 — Lacune dans les critères d’acceptation. « Que se passe-t-il si le paiement échoue ? » La question n'ayant jamais été posée, un système de commande marquera quand même la commande comme « confirmée » en cas d'échec du paiement. La liste des scénarios négatifs générés par l’IA capture cette lacune ; Les critères d'acceptation d'une seule ligne empêchent la perte d'argent réel.
Erreurs courantes
- Passer la requête directement au code. Le code écrit avant que l’ambiguïté ne soit résolue résout rapidement le mauvais problème.
- Adopter aveuglément les « meilleures pratiques » générales de l’IA. Si vous ne précisez pas votre contexte (échelle, budget, équipe), la recommandation ne fonctionnera pas pour vous.
- Ignorer les exigences non fonctionnelles. Si la vitesse, la sécurité et l’échelle ne sont pas spécifiées, la conception sera incomplète.
- Je pense juste au scénario heureux. Les scénarios négatifs tels que données vides, utilisateur non autorisé, état d'erreur doivent être inclus dans la conception.
- Déléguer la décision à l’IA. L'IA génère des options ; Vous décidez quel compromis convient à votre entreprise.
En résumé
L’analyse et la conception des besoins sont l’étape où les erreurs les moins coûteuses sont détectées. Ici, l’IA génère des questions qui révèlent l’incertitude, rédige des témoignages d’utilisateurs et des critères d’acceptation, et présente des compromis en matière de conception. Mais vous seul connaissez le contexte ; C'est votre travail de filtrer les recommandations de l'IA en fonction de votre taille, de votre budget, de votre équipe et de vos contraintes juridiques et de prendre la décision finale. La discipline du « ne prenez pas la décision à ma place, montrez-moi les options » conduit à la fois à une meilleure conception et à un apprentissage plus approfondi.
Tâche de candidature
Choisissez une demande d'emploi d'une phrase dans votre contexte. Tout d'abord, appliquez l'invite d'ambiguïté à l'IA et répondez aux questions avec vos contraintes réelles. Traduisez ensuite le besoin clarifié en au moins 2 user stories et 3 critères d’acceptation pour chacune ; Incluez au moins 1 scénario négatif. Enfin, créez un tableau comparatif pour une décision de conception (synchrone/asynchrone, structure de tableau, etc.) et écrivez votre propre décision en 2 phrases.
liste de contrôle
- [ ] J'ai supprimé les ambiguïtés sous forme de questions avant de transmettre la requête dans le code.
- [ ] J'ai donné le contexte (échelle, autorité, performance, contrainte légale) à l'IA.
- [ ] J'ai divisé les user stories en critères d'acceptation testables.
- [ ] J'ai ajouté au moins un scénario de baisse/avantage.
- [ ] J'ai évalué la décision de conception avec le tableau des compromis.
- [ ] J'ai pris la décision finale en fonction de mon contexte, je ne l'ai pas laissé à l'IA.