[cedar] Re: enseigner?

  • From: douglas edric stanley <destanley@xxxxxxx>
  • To: cedar@xxxxxxxxxxxxx
  • Date: Sat, 22 Jun 2002 21:53:42 +0200

Je voudrais dès l'année prochaine faire un cours régulier sur les
pratiques numériques et la programmation [...]
Vous comprenez qu'il s'agit d'un travail en amont, qu'il s'agit
d'une sorte de préformation. Est-ce qu'il y a d'autres profs parmi
vous qui pratiquent ce genre d'enseignement. Si oui, quelles
méthodes utilisez vous, à quel niveau dans le cursus scolaire? etc.
Pour un échange de point de vue (et éventuellement de didacticiels)

J'arrive un peu tard pour répondre à cette question qui me concerne assez directemment, je vais tenter d'y répondre quand-même...

[Contexte pedagogique]

Comme j'ai déjà pu expliquer ici et ailleurs, je traite directemment
la question de la programmation dans le milieu des arts plastiques
depuis déjà quelques temps. A l'Ecole d'art Aix-en-provence j'ai
animé plusieurs workshops sur la programmation, où, par exemple, j'ai
pu inviter des étudiants d'autres écoles pour élargir le débat sur ce
sujet, pour aider ceux qui ne pouvaient pas bénéficier d'un tel
enseignement chez eux, mais surtout pour voir si on assistait ou pas
à l'emergence de quelque chose de mannière plus générale (le fait que
je rencontre de plus en plus de gens dans votre cas me fait dire oui
- mais avec des réserves). J'ai fait ce même workshop ailleurs, avec
plus ou moins de succès. Pendant le restant de l'année, je dirige la
mise en place des projets se servant de la programmation, et
plusieurs étudants de chez nous ou d'ailleurs ont pu assister à cette
recherche approfondie. Vous pouvez regarder dans les archives pour
les details de tout ce travail.

Maintenant j'affiche clairement cette orientation ("atelier
programmation") pour radicaliser le débat : ce qui a malheureusement
donné un malentendu que j'ai recemment repéré chez les étudiants
("Douglas ne s'occupe *que* de la programmation") mais je suis prêt à
prendre ce risque dans l'espoir de dévoiler les ideologies et faire
bouger des ésprits (j'en ai marre des positions moues et consensuels
sur ce sujet).

Mon collègue Peter Sinclair organise des workshops autour de MAX/MSP,
et certains de ce liste ont pu participer. Son travail dans l'école
s'oriente de plus en plus sur la création de dispositifs sonores
temps-réel (et donc programmés). Constatant une direction, nous avons
organisé (Peter, Jean Cristofol, Norbert Hillaire, et moi-même) une
semaine de conférences autour du titre "CODE|ART" cette année,
espérant encrer notre volonté d'explorer cette question avec une base
théorique plus explicite, critique, et plus engagé. Peter aurait donc
des choses également à dire sur ce sujet.

Nous avons aussi un spécialiste d'interfaçage
(robotique/informatique) qui travaille plutôt par rapport aux projets
et un spécialiste de l'électronique qui utilise (et enseigne donc) de
la programmation dans les circuits (PIC et cie).

[Langages et environements]

Oui, on utilise Director. Personellement, c'est ma spécialité. Je
connais le Lingo à fond, alors je finis (pour le meilleur et le pire)
à m'en servir la plupart du temps. Certains étudiants aiment
RealBASIC aussi; je ne le connais pas à fond, mais l'enseignement
théorique et architecturale est le même. J'enseigne aussi le BASIC
pour la robotique (BasicSTAMP, PIC divers, etc), et de temps en temps
du C pour Lego Mindstorms (NQC) ou Gameboy Color/Advance. Encore une
fois, quelque soit le langage, l'enseignement est le même: les
étudiants qui auraient bien suivi est saisi l'essentiel peuvent
passer d'un environement à un autre avec les mêmes logiques, il faut
juste leur tenir un peu la main, ou rester dans l'achitecture du
programme, la façon d'attaquer le problème, etc. On touche de plus en
plus au PHP, qui nous intéresse pas mal en ce moment.

Peter m'a introduit à MAX/MSP, et oui c'est génial. Pour ceux qui ne
le conaissent pas, renseignez-vous. Je pense que c'est vraiement *la
réponse* pour le artistes, l'avenir en somme, et marche bien pour les
installations. Il faudrait simplement qu'ils perfectionnent le
système multimedia pour avoir une solution plus globale - oui, NATO
aurait du répondre à cette ambiguité, mais les auteurs sont des
*(§%$! - j'en parle d'expérience.

Je compte également invité l'année prochaine un jeune chercheur du
MediaLab (Casey Reas) qui a travaillé sur cette question
(programmation par/pour artistes) avec John Maeda et son logiciel
d'apprentissage "Design by Numbers". Il a notamment prolongé le
logiciel pour ajouter de l'interactivité et le 3d. Son logiciel
s'appelle "Processing"... Comme j'ai deux ans d'expérience avec le
langage DBN à l'école (1er + 2ème années), Casey et moi pensions que
ce serait intéressant de prolonger cette expérience, justemment parce
qu'elle n'était pas que positive. Pour ceux qui aimeraient suivre
cette piste, il y a un livre du même nom - "Design by Numbers"
(anglais, désolé) - qui explique le langage (DBN est également
téléchargeable gratuitement du site du MIT). C'est très pédagogique
comme projet, part d'une bonne volonté, et semblerait répondre à mon
projet *d'enseignement de la programmation aux jeunes artistes*, mais
je suis quand-même déçu pour plusieurs raisons. On verra avec Casey
si on peut répondre à ces réserves l'année prochaine. D'ailleurs, vos
étudiants les plus motivés seraient les bienvenus dans ce workshop
réduit (je prendrai, comme d'habitude, des d'étudiants extérieurs).

[Pratique de l'enseignement]

Si je regarde la production de l'atelier depuis quelques années, on
peut distinguer trois types d'usage:

1) de la pure "commande" sans intérêt. L'étudiant a une idée plutôt
vague de ce qu'est la programmation, ne comprends pas vraiement les
enjeux, et veux quelque chose qui est probablement sans pensée
plastique forte. Beacoup d'idées reçues dans cette catégorie, et
d'une mécompréhension totale de l'interactivité, des processus
émergeants, etc. Malheureusement je me trouve à aider ces projets
sans intérêt de temps en temps (par gentilesse?) - j'en ai même fait
un il y a quelques jours, et je vous recommande d'éviter cette
situation comme de la peste.

2) l'etudiant engagé, à fond dans la programmation comme forme
d'expression. On a une petite poignée de ceux-ci, mais c'est rare
comme oiseau. Certains ne conaissaient pas la programmation avant
d'arriver chez nous, d'autres la connaissaient avant mais n'avait pas
de pensée "plastique" de la programmation, ou c'était trop sommaire -
en tout cas, ce sont toujours des trajets assez singuliers.
Evidemment je suis très proche de ce cas de figure, et on peut même
parler d'un groupe de recherche assez forte des ex-d'Aix et des
aixois actuels qui tombent dans cette catégorie. Ces étudiants, c'est
important de le noter, sont presque toujours lourdement sanctionné
d'une façon ou d'une autre - l'audace d'avoir choisi cette forme
d'expression, soit dans les diplomes, soit après, rencontre de réels
problèmes. Il n'y a pas encore - quoi qu'on en dise - un intérêt
clair (théorique/politique) pour ce genre d'approche. Il faut tout
(re)inventer.

3) l'étudiant débrouilleur, ou très intéressé. Ceux-ci sont aussi
très intéressants. On a eu de très beau diplômes dans cette
catégorie. Il s'agit de gens qui ne veulent pas êtres des "codeurs",
mais sont prêts à s'investir dans une compréhension néanmoins de la
chose, et même s'attaquer eux-même à la réalisation, même foireuse.
Souvent, avec ceux-ci on programme le projet "ensemble" ou avec ceux
de la catégorie 2. Ces projets sont souvent ceux qui sont les plus
compris en dehors de l'école, parce qu'ils engagent des questions
d'interface, de politique, ou d'espace très acessibles et novateurs,
mais qui ne prennent pas leur sens dans des processus génératifs. La
plasticité du travail vient d'ailleurs que de la programmation
(image, installation, dispositif général, etc)... Il faudrait
clarifier, par contre, une chose - qui distingue cette catégorie de
la première: ces étudiants sont prêts à passez le temps *nécessaire*
dans la programmation, que ce soit eux ou d'autres qui tapent les
lignes de codes finales. Ce temps est très important, et c'est dans
ce processus itératif, les labeurs de la construction, que le vrai
travail intéressant se dégage. Ce ne sont absoluement pas alors des
gens qui font de la "commande" de dispositif programmé. On peut
parler plus d'une collaboration, et j'entends cela dans un sens très
différent que ce qu'on a connu dans la passé où un artiste collabore
avec un programmeur en suivant pas à pas le travail. Ma méthode
d'enseignement est plus compliqué que cela: l'étudiant en question
doit faire une grande partie du parcours de recherche.

[...]

De toute façon je pense, comme pour les autres techniques, que les
élèves n'ont pas à tout savoir faire mais à savoir ce qu'on peut
faire avec et les chemins pour y arriver, libre à eux de s'investir
dans le dessin, la peinture ou le macramé.

Bien que j'ai pu adhérer à cette logique à des moments données, je pense de moins en moins que ce soit une position souhaitable, en tout cas qu'il s'agit d'un terrain dangereux. Dans l'ultime, oui, on peut "se servir" de la programmation sans vraiment la maitriser (voire plus haut). Mais dans la plupart des cas, c'est - comme on dit en anglais - un "cop-out", du dilletantisme, et on finit avec des objets sans beaucoup d'intérêt, pour toutes les raisons que je viens de citer.

La différence vient peut-être de ce que je viens d'expliquer sur la
catégorie 3: il faut que celui qui ne saisit pas toutes les nuances
de la programmation fait *néanmoins* tout le véritable travail de
recherche. Vous allez me dire: mais comment peut-il faire cette
recherche s'il ne maîtrise pas la programmation? Eh bien, c'est
complexe, mais d'abord il n'y a pas encore - et ne sera jamais,
j'espère - de metier arrêté et défini de la programmation, même les
programmeurs professionnels sont dans la doute permanente. Les
inventions et suprises peuvent (encore) venir alors de partout: vous
n'avez pas à maîtriser la programmation pour trouver des processus
significatives, parce qu'il n'y a pas à proprement parlé d'objet ou
d'outil défini.

Je pense qu'il faut être très clair là-dessus: la programmation n'est
pas un outil comme un autre, encore moins que la peinture par rapport
au dessin (parce qu'eux aussi ne sont pas des outils comme des autres
- ou même des "outils" du tout). C'est une mode de pensée, un
processus, une politique...

Je pousse alors les étudiants à se perdre dans cette matière, et j'ai
eu un exemple très heureux la semaine dernière d'un étudiant qui a
découvert quelque chose sans que j'intervienne, alors qu'il ne
comprennais pas comment il y est arrivé. On a pu, à partir de là,
extraire la trouvaille, et du coup il a une nouvelle mode de création
qu'il explore...

[...]

Pour trouver un terrain d'entente avec les "autres" disciplines qu'on
peut recontrer dans une école d'art, il faudrait trouver des espaces
transversales où la programmation se déborde, mais de l'intérieur.
Par exemple, Jean Cristofol et moi commençons à travailler sur les
différentes choses en jeu dans telle ou telle type de travail
programmé dans l'école ou à LOEIL: une taxonomie plus sophistiqué que
"interactif", "génératif", "calculé". Il faudrait parler des notions
d'emergence, de simulation, d'emulation, etc., en tout cas des modes
de pensée bien spécifique à l'intérieur de la programmation qui
parlent à d'autres pensées plastiques. Trouver des processus
d'abstraction plus débordants que for(i=10;i<100;i++). Ce qui est
intéressant, c'est que nous commençons à avoir assez d'expériences
passés et en cours chez nous pour avoir des directions qui se
dégagent et pouvoir percevoir leur relief.

[...]

J'ai été longue. J'en reste là. Evidemment il y a beaucoup d'autres
choses à dire...

--
Douglas Edric Stanley
destanley@xxxxxxx

http://www.abstractmachine.net

Professeur d'Arts numeriques, L'école supérieur d'art d'Aix-en-provence
Artiste/Chercheur, Laboratoire Esthétique de l'interactivité,
Université de Paris 8

Other related posts: