L’art de la description de problème : des exigences traditionnelles à l’ingénierie de prompts pour l’IA

Introduction : L’évolution d’une compétence critique

Historiquement, laDescription de problème (DP) était l’artefact fondamental de l’analyse de systèmes. Elle servait de source unique de vérité pour dériver les cas d’utilisation,les modèles de processus métier (BPMN)les diagrammes de classes et les schémas de base de données. Une DP vague entraînait un dérapage des périmètres ; une DP précise signifiait une réalisation réussie.

Aujourd’hui, avec l’IA générative, la description de problème n’est pas devenue obsolète ; elle est devenuele prompt.

Les modèles d’IA sont essentiellement des « moteurs d’exigences ». Ils ne peuvent pas lire dans vos pensées, mais ils peuvent exécuter des instructions à une vitesse surhumaine si ces instructions sont structurées comme une description de problème rigoureuse. Rédiger une DP pour l’IA requiert la même discipline analytique que pour une équipe de développement, mais avec des couches de contexte supplémentaires concernantle format de sortie, les contraintesetl’affinement itératif.

Ce guide fait le pont entre l’analyse de systèmes traditionnelle et l’ingénierie de prompts moderne pour l’IA, en fournissant un cadre complet pour rédiger des descriptions de problème qui génèrent des diagrammes, du code et des analyses stratégiques de haute qualité.

1. Concepts clés des descriptions de problème efficaces

Qu’il s’agisse de cibler des analystes humains ou des LLM, quatre piliers soutiennent une DP robuste :

1. Ancrage contextuel

• Traditionnel : Contexte commercial, parties prenantes, environnement réglementaire.

• Usage pour l’IA : Définition du persona, niveau d’expertise dans le domaine, public cible pour la sortie.

• Pourquoi cela compte : Sans contexte, l’IA se rabat sur des moyennes génériques. « Concevoir un système de connexion » donne un projet étudiant ; « Concevoir une connexion à un portail patient conforme HIPAA pour des utilisateurs âgés ayant une faible littératie numérique » donne un modèle architectural spécialisé.

2. Décomposition structurelle

• Traditionnel : Décomposer les problèmes en exigences fonctionnelles/non fonctionnelles, acteurs et entités.

• Utilisation de l’IA : Structuration par Chaîne de Pensée (CoT), demandes de raisonnement étape par étape, sollicitation modulaire.

• Pourquoi cela compte : L’IA peine avec la complexité monolithique. Décomposer la description du problème (PD) aide le modèle à maintenir la cohérence sur de longs résultats.

3. Spécification des contraintes

• Traditionnel : Budget, calendrier, pile technologique, normes de conformité.

• Utilisation de l’IA : Format de sortie (Mermaid, PlantUML, JSON), directives de style, motifs interdits, limites de jetons.

• Pourquoi cela compte : Les contraintes imposent la créativité et la précision. Une IA sans contraintes génère des artefacts verbeux, souvent inutilisables.

4. Critères d’acceptation

• Traditionnel : Définition de l’achèvement, cas de test, indicateurs clés de performance (KPI).

• Utilisation de l’IA : Vérifications de validation, invites d’auto-correction, vérification de la structure attendue.

• Pourquoi cela compte : Vous devez définir à quoi ressemble le « bon » résultat avant le début de la génération pour permettre une itération efficace.

2. Cadre : Le modèle C.R.E.F.O. pour les descriptions de problèmes d’IA

Adapté de la collecte traditionnelle des exigences, utilisez ce modèle pour les tâches d’IA :

3. Cas d’utilisation et exemples

Cas A : Génération de Diagrammes de classes UML

Défi :L’IA crée souvent des diagrammes excessivement complexes ou syntaxiquement incorrects lorsqu’elle reçoit des descriptions de domaine vagues.

❌ Description de problème faible

« Créez un diagramme de classe pour un système de commerce électronique. »

✅ Description de problème complète

CONTEXTE : Vous êtes un expert en Conception pilotée par le domaine. Nous construisons une plateforme de commerce électronique B2B en gros où la tarification est basée sur des contrats, et non sur un catalogue.

EXIGENCES : Modélisez le contexte délimité de commande principal. Concentrez-vous sur la relation entre les Contrats, les Listes de prix, les Produits et les Commandes. NE modélisez PAS l'interface utilisateur ni le traitement des paiements.

ENTITÉS ET RÈGLES :
- Contrat : Possède des dates d'effet, appartient à un seul Compte client
- Liste de prix : Liée au Contrat, contient des règles de tarification par paliers
- Ligne de commande : Doit valider le prix par rapport au Contrat actif au moment de la création
- Compte client : Peut avoir plusieurs Contrats (actuels/historiques)

FORMAT : Syntaxe Mermaid classDiagram. Incluez les modificateurs de visibilité (+/-/#). Affichez la multiplicité sur TOUS les associations. Utilisez des notes pour les règles métier complexes.

CONSTRAINTES : Maximum 12 classes. Appliquez les principes SOLID. Aucune héritage plus profond que 2 niveaux. Préférez la composition à l'héritage.

VALIDATION : Après la génération, listez 3 faiblesses potentielles de conception dans ce modèle.

Cas B : Modélisation des processus métier (BPMN)

Défi : L’IA confond la notation BPMN et manque les chemins d’exception.

✅ Description complète du problème

CONTEXTE : Traitement des réclamations d'assurance santé. Public : Auditeurs de conformité et développeurs juniors. Ton : Formel et précis.

TÂCHE : Créer un diagramme de processus conforme à la norme BPMN 2.0 pour une « Demande d'autorisation préalable ».

PORTÉE DU PROCESSUS :
DÉPART : Le médecin soumet une demande d'autorisation via l'intégration au dossier médical électronique (DME)
FIN : La décision est communiquée au DME + notification envoyée au membre

POINTS DE DÉCISION CLÉS :
1. La procédure est-elle couverte par le régime du membre ? (Si non → refus automatique + voie d'appel)
2. La documentation clinique est-elle complète ? (Si non → mise en attente pour révision par l'infirmier)
3. Une révision par le directeur médical est-elle requise ? (Seuil : >50 000 $ ou expérimental)

GESTION DES EXCEPTIONS : Modéliser les événements de dépassement de délai pour chaque étape de révision (SLA de 48 heures). 
Modéliser le chemin d'escalade si le SLA est dépassé.

FORMAT : Diagramme de flux Mermaid avec un style ressemblant à BPMN. Utiliser des sous-graphes pour les couloirs « Révision clinique » et « Validation administrative ».

EXIGENCE DE SORTIE : Fournir le code du diagramme ET un tableau Markdown mappant chaque nœud de décision à la section spécifique du document de politique qui le régit.

Cas C : Élaboration des récits utilisateurs et des critères d’acceptation

Défi : L’IA génère des récits génériques manquant de testabilité.

✅ Description complète du problème

CONTEXTE : Équipe Agile migrant un système de paie legacy COBOL vers une architecture cloud-native. 
L'équipe utilise Gherkin/Cucumber pour le BDD.

ENTRÉE : [Coller un extrait de la spécification du système legacy ou une transcription d'entretien]

TÂCHE : Extraire les récits utilisateurs pour le module « Calcul de retenue d'impôt ».

EXIGENCES PAR RÉCIT :
- Respecter les critères INVEST
- Format du titre : En tant que [rôle], je veux [capacité], afin de [valeur métier]
- Critères d'acceptation : Minimum 5 scénarios Gherkin par récit
- Inclure les cas limites : Employés multi-états, ajustements de paie rétroactifs, 
  plafonds de saisie-arrêt, exemptions de traité fiscal

CONSTRAINTES : Chaque récit doit pouvoir être complété en ≤3 jours. Marquer tout récit 
qui semble trop volumineux avec l'étiquette « [BESOIN DE SÉPARATION] ».

FORMAT : Markdown structuré avec un en-tête YAML contenant :
  - story_id
  - priority (MoSCoW)
  - estimated_points
  - dependencies

Cas D : Enregistrements de décisions d’architecture système (ADR)

Défi : Amener l’IA à raisonner sur les compromis plutôt que de simplement lister les options.

✅ Description complète du problème

CONTEXTE : Nous choisissons une plateforme de streaming d'événements pour la télémétrie IoT 
(10 millions d'appareils, pic de 50 000 messages/seconde). L'équipe possède une solide expérience avec Kafka, mais 
la direction souhaite réduire la charge opérationnelle.

TÂCHE : Rédiger un ADR comparant Apache Kafka, AWS Kinesis et Pulsar.

STRUCTURE (Suivre le modèle ADR de Michael Nygard) :
1. Titre et statut
2. Contexte (inclure nos contraintes spécifiques ci-dessous)
3. Facteurs de décision (pondérés)
4. Options envisagées (matrice avantages/inconvénients)
5. Décision + Justification
6. Conséquences (positives ET négatives)

FACTEURS DE DÉCISION (Pondérés) :
- Complexité opérationnelle (35 %) - l'équipe est petite (3 ingénieurs)
- Coût à grande échelle (25 %)
- Garanties d'ordre des messages (20 %)
- Risque de verrouillage fournisseur (15 %)
- Communauté/écosystème (5 %)

CONSTRAINTE : Être radicalement honnête sur les inconvénients. Ne pas recommander uniquement 
sur la base de la popularité. Si aucune option n'est adaptée, le dire et proposer des alternatives.

TON : Technique, fondé sur des preuves, sans langage marketing.

4. Astuces et conseils

🎯 Techniques de précision

1. Définissez d’abord votre ontologie : Avant de demander tout diagramme, demandez à l’IA de créer un glossaire ou un modèle de domaine. Alignez-vous sur la terminologie avant de générer des artefacts. « D’abord, définissez les entités clés et leurs relations sous forme de points. Attendez mon approbation avant de générer le diagramme. »

2. Les contraintes négatives sont puissantes : Dire à l’IA ce qu’elle NE DOIT PAS faire est souvent plus efficace que ce qu’elle DOIT faire. « N’incluez pas les opérations CRUD dans ce diagramme de séquence. N’utilisez pas l’héritage. Ne supposez pas une communication synchrone. »

3. Fournissez des contre-exemples : Montrez à quoi ressemble une mauvaise sortie. « Voici un exemple d’un diagramme trop complexe que nous avons rejeté la semaine dernière [coller]. Évitez ce modèle car… »

4. Utilisez des formats d’entrée structurés : Fournissez les exigences sous forme de YAML, JSON ou de listes numérotées plutôt que de prose. L’IA analyse les données structurées de manière plus fiable.

5. Protocole d’affinement itératif : N’acceptez jamais la sortie de première passe pour des diagrammes complexes. Intégrez l’affinement dans votre description de problème (PD) : « Après la génération, critiquez votre propre sortie par rapport à ces 5 critères de qualité. Puis régénérez en traitant tous les problèmes identifiés. »

⚠️ Pièges courants à éviter

5. Liste de vérification des directives

Avant de soumettre toute description de problème à l’IA, vérifiez :

• Rôle/Persona défini avec un niveau d’expertise approprié

• Contexte métier fourni (pas seulement des spécifications techniques)

• Limites du périmètre explicitement énoncées (dans/ hors périmètre)

• Entités/termes clés définis ou référencés

• Format de sortie spécifié avec des détails de syntaxe et de version

• Contraintes listées (techniques, commerciales, stylistiques)

• Critères de qualité définis pour l’auto-évaluation

• Cas limites/exceptions traités

• Stratégie de décomposition prévue pour les sorties complexes

• Protocole d’itération établi

6. La méta-compétence : la description du problème comme outil de réflexion

L’essentiel à retenir : Rédiger une description de problème pour l’IA est avant tout un exercice de clarification de votre propre réflexion.

Si vous avez du mal à rédiger une description de problème claire, vous n’avez pas un problème de sollicitation, mais un problème de spécification des exigences. L’IA se contente de révéler l’ambiguïté qui aurait de toute façon causé des problèmes en aval.

Utilisez ce flux de travail :

1. Élaborez votre description de problème

2. Demandez à l’IA : « Quelles questions auriez-vous besoin de voir répondues pour accomplir cette tâche parfaitement ? »

3. Répondez à ces questions, en affinant votre description de problème

4. Seulement alors, demandez le livrable réel

Cela transforme l’IA en un partenaire d’élaboration des exigences, et non pas simplement un moteur de génération. La qualité de votre description de problème reste, comme elle l’a toujours été, le meilleur prédicteur de succès, que votre collaborateur soit humain ou artificiel.

EXIGENCE DE FORMAT : Générez le diagramme de classes en syntaxe PlantUML 
compatible avec l'importation dans Visual Paradigm. Incluez toutes les annotations de stéréotypes 
(<<entité>>, <<service>>, <<répertoire>>). Utilisez uniquement les notations de relations 
prises en charge par VP. N'utilisez PAS d'extensions personnalisées ou de décorateurs non standard.

class OrderService {
  +processOrder(order: Order): void
}
class Order {
  +orderDate: Date
}
OrderService --> Order : utilise

<<service>> class OrderService {
  +processOrder(order: Order): void
}
<<entity>> class Order {
  +orderDate: Date
}
<<repository>> class OrderRepository {
  +findById(id: UUID): Optional<Order>
}
OrderService --> OrderRepository : dépend de
OrderService ..> Order : utilise [1..* crée]

Ce guide synthétise les meilleures pratiques issues de l’analyse système traditionnelle (IEEE 830, BABOK, spécifications UML) et de la recherche moderne en ingénierie de prompts pour l’IA. Adaptez les cadres à votre contexte organisationnel et affinez-les continuellement en fonction des boucles de rétroaction sur la qualité des sorties.