Parent : [[INDEX-IA]]

IA — Traitement de l'information : décomposition et intention réelle

Pattern 1 — Décomposer une demande complexe en intentions empilées

Problème : Une demande complexe traitée comme une unité produit une réponse qui rate plusieurs sous-besoins.

Solution : Identifier (1) l'intention de surface, (2) l'intention profonde, (3) les contraintes implicites, (4) le livrable attendu. Traiter chaque couche séparément avant de synthétiser. Si les couches sont contradictoires, signaler avant de répondre.

Exemple : "Explique-moi le machine learning" peut cacher : veut-il comprendre le concept, choisir un framework, ou justifier un budget à son boss ? Le livrable change radicalement selon la couche réelle.

Pattern 2 — Détecter l'intention réelle vs la demande formulée

Problème : Répondre littéralement à ce qui est dit produit une réponse techniquement correcte mais inutile.

Solution : Chercher le verbe d'action implicite (décider, convaincre, débloquer, apprendre, déléguer). La demande formulée est souvent un moyen, pas une fin. Poser mentalement : "Avec ma réponse, que va-t-il pouvoir faire ?"

Exemple : "Quels sont les avantages du cloud ?" — intention réelle probable : justifier une migration. Répondre en argument de décision, pas en encyclopédie.

Pattern 3 — Gérer les informations contradictoires

Problème : Choisir arbitrairement entre deux sources contradictoires sans le signaler induit une fausse confiance.

Solution : Nommer explicitement la contradiction. Exposer les deux positions avec leurs sources/logiques. Ne trancher que si une position est clairement plus robuste et expliquer pourquoi. Sinon, livrer les deux avec leurs conditions d'application.

Exemple : "Source A (2019, n=200) dit X ; Source B (2023, n=2000) dit Y. Dans votre contexte, Y est plus applicable car…"

Anti-pattern — Prioriser par volume plutôt que par impact

Problème : Un LLM surpondère naturellement les informations fréquentes dans le contexte, pas celles qui sont vraiment importantes.

Solution : Prioriser par conséquence sur le livrable final, pas par fréquence. Demander : "Si l'utilisateur ne retient qu'une chose, laquelle change réellement son action ?" La mettre en premier.

Exemple : Dans un debug avec 10 erreurs, l'erreur racine qui génère les 9 autres doit être traitée en premier, même si elle occupe 2 lignes sur 50.