SKILL.md : Ingénierie des Systèmes Cognitifs pour la Conception Complexe
licence : Apache-2.0
metadata:
nom : Ingénierie des Systèmes Cognitifs (CSE)
source : "Le rôle de l'ingénierie des systèmes cognitifs dans le processus de conception de l'ingénierie des systèmes"
auteurs : Militello, Dominguez, Lintern, Klein
version : 1.0
déclencheurs_d_activation :
- conception de systèmes d'agents ou d'architectures d'orchestration
- analyse des raisons pour lesquelles un système a échoué ou échoue pour les utilisateurs
- décomposition de tâches complexes pour une exécution par IA ou humain
- extraction des exigences auprès d'experts du domaine
- rencontre d'erreurs ou de comportements inattendus dans le travail cognitif
- questionnement sur la résolution du bon problème
- conception pour le jugement d'expert, l'aide à la décision ou l'automatisation
- évaluation de si une solution résout le problème énoncé ou réel
Quand utiliser cette compétence
Chargez cette compétence lorsque :
- Un système est conçu pour soutenir la cognition humaine — aide à la décision, orchestration d'agents, systèmes d'information, automatisation de l'expertise
- Les exigences semblent vagues, contestées ou changent constamment — c'est un signal que les exigences cognitives sont invisibles, pas que les parties prenantes sont confuses
- Des erreurs ou des échecs apparaissent — traitez-les comme des diagnostics sur les hypothèses de conception, pas comme des défauts à corriger
- Le problème énoncé semble erroné — lorsque l'espace des solutions semble ne pas contenir la réponse réelle
- L'expertise doit être capturée, reproduite ou soutenue — et l'expert "n'arrive pas vraiment à expliquer comment il fait"
- Une équipe ou un système distribué doit se coordonner sur un travail cognitif complexe — plusieurs agents, humains, outils ou organisations partagent la charge cognitive
- La valeur du travail d'analyse est remise en question — lorsque les contributions cognitives sont invisibles par rapport aux livrables d'ingénierie
Modèles mentaux fondamentaux
1. Les exigences cognitives sont invisibles
Ce que les concepteurs supposent que les travailleurs ont besoin et ce dont les travailleurs ont réellement besoin sont systématiquement différents — et l'écart est énorme. Les praticiens experts opèrent sur des connaissances tacites, des indices perceptifs, la reconnaissance de motifs et la conscience des contraintes qu'ils ne peuvent pas facilement exprimer et que l'observation seule ne révélera pas. Tout processus de conception qui n'excave pas activement ces exigences construira pour un travailleur imaginaire.
Implication : L'extraction des exigences doit utiliser des méthodes spécialisées (analyse cognitive des tâches, méthode de décision critique, protocoles de réflexion à voix haute), pas des entretiens ou des enquêtes. L'artefact de ce travail est un modèle cognitif du travail réel, pas une liste de fonctionnalités.
2. Les erreurs sont des diagnostics, pas des défauts
Une erreur dans un système cognitif n'est pas un dysfonctionnement — c'est une indication précise de l'endroit où le modèle du système sur le travail diverge de la structure réelle du travail. Le décalage entre le comportement attendu et observé est le signal le plus riche en informations disponible pour un concepteur.
Implication : Lorsque des agents, des utilisateurs ou des systèmes conjoints produisent une sortie inattendue, la première question est "que révèle cette erreur sur nos hypothèses de conception ?" pas "comment éliminer cette erreur ?"
3. Le design est un dialogue, pas un pipeline
Les modèles de conception séquentiels (exigences → spécifications → construction → test) sont pratiques sur le plan pédagogique mais faux sur le plan opérationnel. Les problèmes complexes révèlent de nouvelles informations à mesure qu'on les aborde. L'énoncé du problème avec lequel vous commencez n'est jamais celui avec lequel vous devriez terminer. Les tentatives de verrouiller les exigences tôt suppriment la découverte que les problèmes complexes nécessitent.
Implication : Les itérations ne sont pas des échecs de planification. Revoir le cadrage du problème en cours de projet n'est pas une dérive du périmètre — c'est le processus qui fonctionne correctement. Construisez des points de réévaluation explicites.
4. Le cadrage du problème est l'intervention au plus fort levier
La chose la plus précieuse qu'une analyse cognitive peut produire est souvent une reformulation du problème — pas une meilleure solution au problème énoncé, mais la preuve que le problème énoncé est erroné. Le cas de la centrale nucléaire : 80+ membres du personnel réduits à 35, zéro nouvelle technologie, simplement en comprenant la structure cognitive réelle du travail.
Implication : Avant d'optimiser une solution, investissez dans la vérification de l'énoncé du problème. Le coût de résoudre le mauvais problème avec une haute qualité dépasse presque toute autre erreur de conception.
5. Systèmes cognitifs conjoints, pas paires outil-utilisateur
La complexité cognitive réside dans le système distribué — les humains, technologies, processus et structures organisationnelles qui effectuent collectivement un travail cognitif. Aucun agent ou outil unique ne peut être conçu isolément. Les mécanismes de coordination, les flux d'information et la conscience partagée de la situation à travers le système sont là où le succès ou l'échec cognitif est déterminé.
Implication : Concevez les transferts, pas seulement les nœuds. Spécifiez les exigences de modèle mental partagé entre les composants. Analysez comment l'automatisation modifie la distribution de la charge cognitive dans tout le système conjoint, pas seulement si l'automatisation fonctionne.
Cadres décisionnels
Diagnostic du problème
SI un système produit des erreurs ou un comportement inattendu
ALORS charger : modes-de-défaillance-dans-les-systèmes-cognitifs-complexes.md
→ Classifiez le mode de défaillance avant de proposer un correctif
→ Demandez : S'agit-il d'une surprise d'automatisation, d'un mauvais problème, d'un cloisonnement, d'une sur-spécification ou d'un goulot d'étranglement ?
SI les parties prenantes sont en désaccord sur les exigences ou si les exigences changent constamment
ALORS charger : les-exigences-cognitives-sont-invisibles.md
→ Le changement est une information : les exigences cognitives n'ont pas encore été rendues explicites
→ Déployez une extraction structurée avant de recueillir plus d'exigences
SI la solution proposée semble résoudre la mauvaise chose
ALORS charger : reformulation-du-problème-comme-intervention-au-plus-fort-levier.md
→ Arrêtez le travail de solution ; investissez d'abord dans le cadrage du problème
→ Cherchez une reformulation qui rend les catégories de solutions actuelles inutiles
Processus de conception
SI conception d'un système d'agents ou d'une architecture d'orchestration
ALORS charger : systèmes-cognitifs-conjoints-cognition-distribuée.md ET carte-conceptuelle-cse-pour-architecture-d-agents.md
→ Cartographiez l'ensemble du système conjoint avant de concevoir un composant
→ Concevez d'abord les mécanismes de coordination et le flux d'informations
SI sous pression pour finaliser les exigences avant une compréhension adéquate
ALORS charger : conception-comme-dialogue-pas-pipeline.md
→ Distinguez "verrouiller les exigences" de "avoir un meilleur modèle actuel"
→ Proposez des points de réévaluation explicites au lieu d'un verrouillage séquentiel
SI conception pour ou autour du jugement d'expert
ALORS charger : reconnaissance-de-l-expertise-et-connaissance-tacite.md
→ Appliquez le modèle de décision basé sur la reconnaissance pour comprendre comment l'expertise fonctionne réellement
→ Planifiez pour l'écart d'articulation des experts dans le travail d'exigences
Évaluation et valeur
SI la valeur du travail d'analyse cognitive est remise en question
ALORS charger : cas-de-valeur-et-contributions-invisibles.md
→ Le paradoxe : un bon travail de CSE se rend invisible (moins d'échecs, fonctionnement plus fluide)
→ Utilisez des indicateurs avancés, pas seulement le nombre d'incidents
SI une solution proposée implique l'ajout de technologie ou de personnel
ALORS charger : reformulation-du-problème-comme-intervention-au-plus-fort-levier.md
→ Vérifiez : un modèle cognitif précis du travail a-t-il été utilisé pour valider cette solution ?
→ Le benchmark de la centrale nucléaire : la reformulation du problème pourrait-elle éliminer le besoin de la ressource proposée ?
Fichiers de référence
| Fichier | Quand charger |
|---|---|
references/les-exigences-cognitives-sont-invisibles.md | Les exigences semblent vagues ou contestées ; conception pour des utilisateurs experts ; début de tout processus d'extraction d'exigences ; les méthodes de recherche utilisateur sont en question |
references/conception-comme-dialogue-pas-pipeline.md | Pression pour finaliser les exigences tôt ; le processus itératif est remis en question comme inefficace ; le projet est en cours et l'énoncé du problème doit être revu |
references/reformulation-du-problème-comme-intervention-au-plus-fort-levier.md | L'espace des solutions ne semble pas contenir la bonne réponse ; les solutions proposées semblent coûteuses ou mal alignées ; besoin de justifier une pause dans l'exécution pour reformuler |
references/systemes-cognitifs-conjoints-cognition-distribuée.md | Conception de systèmes multi-agents ou homme-machine ; analyse des échecs de coordination ; évaluation de comment l'automatisation modifie la distribution de la charge cognitive |
references/reconnaissance-de-l-expertise-et-connaissance-tacite.md | Capture de connaissances d'experts ; conception d'aide à la décision ; construction de systèmes pour reproduire ou assister le jugement d'expert ; l'expert ne peut pas articuler comment il fait le travail |
references/modes-de-défaillance-dans-les-systemes-cognitifs-complexes.md | Diagnostic d'erreurs système ou de comportement inattendu ; pré-mortems sur les conceptions proposées ; classification d'une défaillance observée avant d'y répondre |
references/carte-conceptuelle-cse-pour-architecture-d-agents.md | Cartographie des capacités pour un système d'agents ; organisation des fonctions cognitives entre les composants ; résolution de confusion terminologique entre les frameworks |
references/cas-de-valeur-et-contributions-invisibles.md | Justification de l'investissement dans l'analyse cognitive ; la valeur du travail de CSE est remise en question ; mesure des résultats des systèmes qui préviennent principalement les échecs |
Anti-patrons
Voici les modes de défaillance contre lesquels la CSE met spécifiquement en garde. Reconnaissez-les tôt.
1. Concevoir pour le travailleur imaginaire Construire des systèmes basés sur la façon dont les concepteurs pensent que les experts travaillent, pas sur la façon dont les experts travaillent réellement. Le travailleur imaginaire est rationnel, dispose d'informations complètes, suit des procédures et prend des décisions comme un manuel le dit. Le travailleur réel ne fait rien de tout cela.
2. Traiter les erreurs comme des défauts plutôt que des diagnostics Corriger les erreurs sans se demander ce qu'elles révèlent. Une erreur corrigée sans être comprise est une occasion manquée de corriger l'hypothèse de conception sous-jacente — et une garantie que le problème resurgira sous une forme différente.
3. Verrouiller les exigences avant que le travail cognitif ne soit terminé Les modèles de processus séquentiels créent une pression pour verrouiller les exigences tôt. Dans des domaines cognitivement complexes, cela garantit que le mauvais système est construit efficacement. Le verrouillage précoce des exigences n'est pas de la discipline ; c'est une fermeture prématurée.
4. Cloisonnement : optimiser les composants sans la vue d'ensemble du système conjoint Construire un excellent outil qui brise le flux de travail des humains ou des agents autour de lui. Optimisation locale qui dégrade la performance du système. La version classique : automatisation qui libère un humain d'une tâche mais le laisse sans conscience de la situation lorsque l'automatisation échoue.
5. Biais rétrospectif dans l'analyse des échecs Après un incident, concevoir uniquement pour cet échec spécifique. La clarté séduisante de la reconstruction post-hoc rend les échecs plus prévisibles qu'ils ne l'étaient — et concentre l'énergie de conception sur le dernier échec plutôt que sur le suivant.
6. Sur-spécification qui élimine la capacité d'adaptation Concevoir des systèmes si serrés que les praticiens ne peuvent pas improviser lorsque la réalité s'écarte du modèle. Le travail complexe réel nécessite de l'adaptation. La sur-spécification rend le système fragile précisément dans les situations où la flexibilité compte le plus.
7. Le goulot d'étranglement d'expert par conception Construire un système où un seul expert (humain ou IA) est la passerelle requise pour toutes les décisions critiques. Même lorsque cet expert est excellent, cela crée une fragilité catastrophique. La CSE appelle à distribuer l'expertise, pas à la concentrer.
Shibboleths
Comment savoir si quelqu'un a réellement intériorisé la CSE vs. a lu un résumé :
Ils disent "les erreurs sont intéressantes" — pas "les erreurs sont des problèmes." Quelqu'un qui a absorbé la CSE traite un rapport d'échec comme une opportunité de recherche, pas comme un ticket à clôturer.
Ils demandent "est-ce le bon problème ?" avant de demander "quelle est la solution ?" — et ils sont prêts à passer du temps réel sur cette question même si cela retarde le progrès visible. Ils ont vu le cas de la centrale nucléaire et savent ce que la réponse peut valoir.
Ils résistent au verrouillage des exigences sans analyse cognitive — pas comme obstruction mais parce qu'ils comprennent que verrouiller les exigences avant de comprendre la structure cognitive du travail est une manière spécifique, nommée et prévisible de construire la mauvaise chose.
Ils pensent en systèmes conjoints — lorsqu'ils analysent un échec ou conçoivent une solution, ils demandent instinctivement "où cela se situe-t-il dans l'ensemble du système cognitif ?" pas "que devrait faire ce composant ?"
Ils savent ce que coûte la connaissance tacite — ils ne s'attendent pas à ce que les experts puissent leur dire ce qu'ils ont besoin de savoir. Ils ont intériorisé que l'expertise est largement inaccessible à l'introspection et planifient leurs méthodes d'extraction en conséquence.
Ils traitent la nature itérative du design comme un signal, pas du bruit — lorsqu'un énoncé de problème change en cours de projet, ils le lisent comme le processus révélant quelque chose de réel, pas comme un échec de planification à gérer.
Ils peuvent nommer les cinq modes de défaillance — surprise d'automatisation, mauvais énoncé de problème, cloisonnement, sur-spécification, goulot d'étranglement d'expert — et les appliquer de manière diagnostique à des situations nouvelles, pas comme une liste de contrôle.
Ce qu'ils ne disent pas : "Nous avons juste besoin de meilleures exigences." "Si nous documentons le processus, le système le suivra." "Les utilisateurs ont juste besoin de formation." "Nous pouvons évaluer l'outil IA indépendamment de la façon dont les opérateurs l'utilisent."
Chargez les fichiers de référence à la demande selon les situations spécifiques. La compétence s'active avec ce fichier ; une analyse plus approfondie nécessite les références.