– Le mode de contrôle [contrôle ou re-planification] : le module «Contrôle» ne réagit pas
de la même manière lorsqu’il a déjà entamé une phase de re-planification. Par exemple,
il demandera plusieurs planifications à un niveau micro avant de demander une
re-planification à un niveau macro. Le mode de contrôle permet de renseigner l’état du module.
– Le but à résoudre : le module «Contrôle» a besoin de connaître le but ou sous-but qui pose
problème pour pouvoir tenter différentes méthodes de re-planification.
– Le schéma erroné : le module «Contrôle» connaît aussi le schéma dont la réalisation n’a
pas été faite ou a été mal faite, en d’autres termes il connaît l’action qui n’a pas abouti.
– Un compteur d’essai : le module «Contrôle» doit pouvoir changer de mode de re-planification
et passer en macro re-planification lorsque la micro re-planification ne fonctionne pas. Le
compteur permet de connaître le nombre d’essais réalisés en micro re-planification pour
tenter de résoudre un problème donné.
La nécessité et l’utilisation de ces données sont détaillées au fur et à mesure de la description
de l’algorithme de traitement du composant «Contrôle». Le traitement effectué par ce module
peut se décomposer en trois étapes : (1) réception ou construction des messages de contrôle ;
(2) appréciation et prise en compte ou non des messages ; (3) traitement des messages en
fonction des informations qu’ils contiennent et du mode de contrôle dans lequel se trouve le
module (contrôle ou re-planification).
Spécification 12 Les messages que le module «Contrôle» reçoit sont constitués des
informa-tions suivantes : source (signal extérieur, contrôle, CS, micro re-planification) / description
(action mal faite, action non réalisable, procédure non réalisable, stratégie non réalisable,
ou-bli, micro re-planification impossible, pre/post-conditions ok, schéma planifié accompli) / but
à résoudre / schéma erroné.
Dans la première étape du traitement, le module «Contrôle» réceptionne les messages. Pour
simplifier, on considère que ce module ne reçoit, pendant un cycle d’exécution, qu’un seul
message à la fois
4
. Il peut recevoir un message du monde extérieur. Dans le modèle que
nous proposons ici, un raccourci a été pris dans l’environnement de façon à simplifier la
modélisation des mécanismes externes aux mécanismes exécutifs. Les signaux extérieurs sont
directement modélisés dans l’environnement sous forme de messages. Pour être au plus prêt
de la réalité, il faudrait modéliser les mécanismes cognitifs relatifs à la perception du signal de
l’environnement et à son interprétation avant de les intégrer au module «Contrôle» (modules
intermédiaires entre le monde extérieur et le module de contrôle). Les messages que nous
modélisons dans le monde extérieur correspondent aux interventions de l’examinateur ou
aux indices environnementaux d’erreurs (par exemple, message d’erreur d’un site internet
4
Il faudrait, en réalité, utiliser une file de traitement des messages pour pouvoir traiter différents messages
au cours du même cycle d’exécution.
8.3. Spécifications théoriques du modèle
ou message d’erreur vocal au téléphone). Les informations que contiennent ces messages
sont donc déjà analysées en terme de description du problème. Ultérieurement, d’autres
types de messages pourraient être pris en compte par le module «Contrôle», comme les
interruptions (par exemple, le téléphone sonne alors que la personne est en train de faire
une activité). En terme de signaux internes, deux modules du modèle peuvent envoyer un
message au module «Contrôle» : le CS, si le schéma planifié est terminé (i.e. le but du
schéma planifié est accompli), et le module «Micro re-planification», si aucune solution au
niveau micro n’a été trouvée. Enfin, le module «Contrôle» peut lui même générer un message
lors de la vérification des pré et post conditions des schémas sélectionnés et désélectionnés
par le CS. C’est ce que l’on appelle le contrôle des actions réalisées par rapport au plan.
À l’origine, ce traitement est proposé par Cooper dans le gestionnaire des conflits. Cooper
souligne cependant le fait que le principe, plus complexe que celui implémenté, devrait être
pris en charge par les processus de haut niveau du SAS. C’est donc le module «Contrôle»
qui vérifiera, dans notre modèle, les conditions des schémas. Lors de la vérification des pré
et post conditions, un raccourci de modélisation sera pris pour identifier le problème ou
détecter l’erreur. Nous utiliserons le même type de raccourci que celui utilisé pour traiter les
signaux de l’environnement. De cette manière, nous évitons d’entrer dans la modélisation des
mécanismes de perception et d’interprétation de l’erreur. Différents types d’erreurs seront
pré-reconnus dans les mécanismes de vérification des pré et post conditions
5
. De l’analyse
de l’expérimentation réalisée (cf. Chapitre 6), nous avons dégagé quatre types d’erreurs, qui
selon leur nature et le mode de contrôle du module, donnent lieu à des traitements différents
en termes d’ajustement et de re-planification. On considère que si des pré-conditions d’un
schéma ne sont pas vérifiées, alors que ce schéma aurait dû être sélectionné d’après le plan,
on se trouve devant un problème d’oubli d’une étape ou de mauvais séquençage. Si les
post-conditions d’un schéma qui vient d’être désélectionné ne sont pas vérifiées, plusieurs cas de
figure se présentent : soit l’action a été mal faite, soit l’action est non réalisable, soit la
procédure choisie ne marche pas, soit la stratégie choisie ne marche pas.
Lors des expérimentations, nous nous sommes aperçus que les sujets ne contrôlent pas
tou-jours très bien leurs actions. Certains sujets jeunes commettent des erreurs d’inattention
lorsque la séquence d’actions est bien connue (exemple : remplissage erroné de leur adresse
dans le formulaire) ou lorsqu’ils négligent la vérification du résultat de leur action (exemple :
oubli de mettre le formulaire dans l’enveloppe avant de la fermer). Avec l’altération cognitive,
5
Dans l’implémentation du CS proposée par Cooper, les algorithmes de vérification des pré et post
condi-tions des schémas ne sont pas génériques et sont redéfinis pour chaque schéma. Nous pouvons donc facilement
y insérer nos mécanismes de reconnaissance d’erreur.
des troubles du contrôle apparaissent, et c’est dans ces cas que les sujets ne vont pas
s’aperce-voir de leurs erreurs ou ne vont pas s’ajuster face à un problème. Pour pous’aperce-voir rendre compte
de ces observations dans le modèle, une notion d’attention portée aux messages reçus a été
introduite dans le module «Contrôle». Ce dernier ne sera sensible aux informations reçues
que si l’intensité de leur signal est suffisamment importante par rapport au degré d’attention
que l’on porte à la tâche en cours de réalisation. En d’autres termes, les messages reçus sont
associés à une force de signal et ne seront traités que si cette force dépasse un certain seuil
d’attention. La force du signal associée aux messages reçus dépendra d’un bruit aléatoire,
afin de modéliser les différences individuelles et les erreurs de négligence de contrôle chez les
sujets jeunes. Le seuil d’attention de contrôle variera selon le niveau d’altération cognitive
pour modéliser les erreurs de contrôle observées chez les personnes souffrant de troubles
exé-cutifs. L’utilisation d’un système sub-symbolique permet une souplesse dans le traitement
des informations relatives au contrôle que ne pourrait pas assurer une représentation
pure-ment symbolique. Ce processus d’évaluation de l’intensité du message correspond à la phase
d’appréciation, deuxième étape de l’algorithme de traitement du module «Contrôle».
Spécification 13 Chaque message reçu par le module «Contrôle» est associé à une force de
signal.
Spécification 14 Le seuil d’attention de contrôle correspond au seuil de force de signal
en-dessous duquel les messages ne sont pas pris en compte pour le traitement du module
«Contrôle». Ce seuil varie selon les sujets et selon leur niveau d’altération cognitive.
Le contrôle du déroulement de l’action (vérification des pré et post conditions) se fait dans
