Du serveur au client 
Marc-Eric Bobillier Chaumon, Christian Bessière
Marc-Eric.Bobillier-Chaumon@ictt.ec-lyon.fr ; Christian.Bessiere@ictt.ec-lyon.fr 
Laboratoire ICTT (Interaction Collaborative, Téléformation, Téléactivités)
Ecole Centrale de Lyon 36 av. Guy de Collongue, BP 163, 69131 Ecully cedex
Résumé — Ce papier restitue et analyse une expérience de changement technologique dans le domaine de la conception informatique : le passage d’une informatique centralisée à une informatique distribuée dans une entreprise de plus de 1000 salariés. Nous montrerons que ce changement technologique s’accompagne d’une modification de la configuration des compétences et de l’environnement socio-professionnel des informaticiens. Leur activité de conception évolue et leurs compétences changent de nature. Une dynamique d’évolution organisationnelle s’enclenche  à partir de la spécialisation fonctionnelle de chaque individu vers le développement d’un travail collectif.
Cette évolution “ interne ” à la communauté des informaticiens entrouvre une porte sur le monde des utilisateurs. Une communauté scientifique comme IHM peut mettre le pied dans l’entrebâillement et contribuer à la prise en compte de ces utilisateurs. Dans cette perspective, les “ nouvelles ” applications client-serveur que conçoivent les informaticiens peuvent aussi être vues comme des outils socialisés, comme des usages. L’interprétation humaine et sociale de la terminologie “ client-serveur ” renverse dès lors le point de vue : elle redéfinit la relation concepteur-utilisateur pour que les informaticiens deviennent les "serveurs" des clients.

1. Introduction
Cette recherche, menée entre 1993 et 1997, porte sur les effets du changement d’environnement de programmation chez des informaticiens spécialisés dans le développement d’applications bancaires dans une grande entreprise financière. A cette époque, les innovations techniques en matière d’outils de conception (réseaux techniques, interfaces graphiques, accès réparti des données et des traitements…) ont bouleversé les repères traditionnels de ces informaticiens [7].
Plus concrètement, Il s’agit du passage :
-	d’environnements procéduraux (langage Cobol, implémentation d’application sur gros ordinateurs type site-central, interface en mode textuel ayant des possibilités d’affichage réduites) ;
-	vers des environnements orientés-objet (langage C++ ou autres, architecture client-serveur implémentation sur station de travail, interface graphique multimédia).
Techniquement, il est clair que ces différentes innovations offrent de nouvelles possibilités de développement grâce à des interfaces personne-machine plus ergonomiques et des traitements plus rapides sur des réseaux plus performants [10]. Si, techniquement, ces évolutions sont perçues comme des innovations majeures dans le domaine de la programmation informatique ; socialement, elles ne sont pas neutres, mais ce phénomène est moins clairement perçu. Elles induisent pourtant de profondes remises en cause sur les acquis cognitifs et opératoires de ces informaticiens [2, 5, 9], mais également sur leurs modes de fonctionnement organisationnels et coopératifs [3]. Ils doivent alors apprendre ou réapprendre des comportements de travail, des logiques d’activité, des stratégies cognitives qui correspondent davantage aux exigences de ces nouveaux environnements de conception [8, 4]. Dans le même temps, ils doivent aussi démontrer de réelles capacités d’insertion dans les nouvelles structures organisationnelles naissantes [6]. 
Notre recherche de thèse a porté sur ces 3 aspects du changement, à savoir quels étaient les effets opératoires, cognitifs et socio-organisationnels du changement d’environnement de développement sur le métier informaticien [1]. Dans cette communication, nous avons souhaité privilégier le dernier aspect car cette dimension nous paraît encore peu abordée dans le champ de la conception informatique et plus généralement dans le domaine des interactions personne-machine. Ce papier va donc s’efforcer de montrer comment l’évolution des interactions entre les personnes dans une activité de développement informatique peut modifier les interactions personne-machine et ainsi ouvrir vers la prise en compte des utilisateurs finaux.
1.	Contexte de l’étude - Problème posé
Notre étude répond à la demande d’une entreprise informatique, employant près de 1000 informaticiens, qui souhaitait d’une part, accroître sa connaissance des métiers de l’informatique (sur le plan cognitif) et, d’autre part, développer une réflexion sur les difficultés humaines et socio-organisationnelles qu’entraînerait la migration d’un environnement de développement de type procédural (Pacbase) vers un environnement orienté objet. Pour cette société, dont 60% des informaticiens ne connaissent que le paradigme procédural, l’enjeu est double : optimiser les transferts de compétences entre les personnes issues des deux environnements et favoriser l’acceptation et l’appropriation de ces outils. 
Partant de ce constat, nous avons considéré que l’environnement de programmation pouvait être abordé comme un artefact de la situation de conception dans la mesure où il peut affecter certaines formes de raisonnement de conception  et certaines formes d’organisation sociale de l’activité de conception.
D’où un certain nombre de questions : le changement d’environnement de programmation participe-t-il à l’émergence de nouvelles compétences cognitives ? Et si oui, de quelles natures ? Autorise-t-il ou interdit-il de nouvelles formes d’organisation sociale ? Si oui, lesquelles ? Enfin, dans quelle mesure l’environnement de programmation est-il un facteur explicatif des effets constatés ? Et quelles en sont les limites ? 
Ces problèmes généraux se déclinent en deux hypothèses :
1. L’environnement de programmation constitue pour l’informaticien un cadre général d’organisation de son activité. 
2. L’environnement de programmation affecte le jeu organisationnel. Il impose ou propose des prescriptions, des modalités d’action particulières qui ont pour effet de restructurer le modèle de fonctionnement social en vigueur et de redéfinir les conditions de coopération entre les individus.
2.	Terrain et méthode
Notre intervention se déroule en situation réelle de travail. A ce titre, l'activité collective est considérée comme une activité située, c'est-à-dire comme une activité étudiée dans son contexte de production.
Deux groupes de 10 informaticiens ont été constitués : un groupe travaillant avec un atelier de génie logiciel Pacbase et un langage procédural dans un environnement sur site central avec une méthode de conception de type séquentielle “en cascade” ; et l’autre, avec un langage de quatrième génération (NSDK) et un langage orienté objet intermédiaire dans un environnement distribué client-serveur, avec une méthode de conception itérative par prototypage.
Ces deux échantillons sont représentatifs des informaticiens de l'entreprise par : 	
- l'âge : entre 30 et 45 ans, 	
- l'ancienneté : en moyenne, près de 10 années d'ancienneté dans l'entreprise, 	
- l'expérience de l'environnement : une dizaine d'années de pratique pour l'environnement site central et au moins 6 mois pour l'environnement client serveur,
- la formation : la plupart de ces personnes ont été recrutées dans les années 80 lorsqu'il y avait une grande pénurie d'informaticiens. Ne disposant d'aucune formation initiale en informatique, l'entreprise leur a alors dispensé une formation à l'environnement site central. Pour la majorité d'entre eux, elle représente d'ailleurs la seule connaissance en informatique. D'autres développeurs ont commencé à suivre des modules de formation au système client-serveur depuis une dizaine de mois. Ce sont ces derniers qui constituent le deuxième échantillon d'informaticiens ; 	
- les fonctions occupées dans le processus de développement : chaque échantillon était constitué, à part égal, d'informaticiens impliqués dans la conception, la réalisation ou la responsabilité du projet.
- le type de développement : chaque échantillon travaillait au développement d'une application bancaire et financière, comparable par leur durée et leur complexité et par le nombre de personnes impliquées dans ces projets.
Des entretiens et des observations de l’activité et de l’organisation du travail ont par ailleurs permis d’identifier les types de changements en œuvre.	
Plus précisément, les entretiens (exploratoires et semi-directifs) ont fourni des repères sur les grandes lignes de l'activité de développement et sur les relations entre informaticiens. La comparaison de ces données, sur la base d'une analyse thématique de contenu, a permis de privilégier certaines pistes d'investigation pour un examen plus ciblé de l'activité ; lors de l'observation.	
Ces observations se sont déroulées durant le développement des projets. Elles se sont focalisées sur le fonctionnement et les échanges de l'équipe de travail afin d'identifier la nature et le sens des interactions en œuvre. Notamment, le caractère de ces interactions, leur fréquence, les évolutions et/ou les remises en cause fonctionnelles et professionnelles ainsi que les jeux de pouvoir entre les acteurs du projet. 
3.	Principaux résultats
Ces différents résultats font apparaître, de manière générale, que les informaticiens, confrontés à l’évolution technologique de leur environnement de conception sont amenés à développer des comportements sociaux et relationnels d’un nouveau type, basés sur la coopération et la négociation avec de nouveaux partenaires. C’est sur ce dernier aspect que nos analyses vont principalement porter.
Plus précisément, l’analyse des données met en évidence des organisations du travail différentes selon les environnements de conception considérés : les environnements de programmation procéduraux (Pacbase sur site central) s’accompagnant d’organisation fermée, tandis que l’environnement NSDK et client-serveur s’accommode d’organisation plus ouverte. Aussi, l’évolution technologique de Pacbase vers NSDK est associée à de nouvelles formes de coopération au travail. 
1. La coopération intragroupe augmente. 
Sur la base des entretiens réalisés, un constat s’impose : l’augmentation significative de la coopération intra-groupe en environnement client-serveur. A cela, trois raisons qui ont pour origine la modularité de l’application, le nombre des connaissances nouvelles à acquérir et l’élargissement de la tâche (polyvalence requise).
De la conception modulaire … vers la collaboration
L’application développée sur le nouvel environnement client-serveur est de type modulaire, alors qu’elle était monobloc dans le précédent. Cela conduit à une réorganisation de l’équipe projet qui doit dorénavant travailler par cellules de développement spécialisées (pour la conception de différents modules applicatifs). Cet éclatement de l’équipe de conception requiert la mise en place d’un système de coopération intragroupe plus important de manière à (1) assurer la cohérence entre les différents blocs de l’application, (2) éviter de trop grandes distorsions entre ces modules lors de leur intégration finale.
“ Il y a un travail en équipe qui est plus important que sur Pacbase, du fait qu’il y a plein de briques dispersées un peu partout ”
Des connaissances … vers la reconnaissance mutuelle 
Le nouvel environnement nécessite également l’acquisition de très nombreuses connaissances, ainsi qu’une logique particulière de développement (événementielle). Face à cet afflux de compétences à maîtriser, l’informaticien développe des réseaux “d’informateurs” professionnels, spécialistes des domaines techniques et fonctionnels qu’il connaît peu. Cette collaboration crée ainsi les bases d’un univers de connaissances partagées qui permet de combler le manque d’expérience des développeurs.
“ On a besoin d’une bonne cohésion dans la mesure où le travail est peut être plus réparti et qu’il faut davantage se poser de questions. Même si on n’est pas des spécialistes, on va aborder ces sujets avec d’autres personnes”
De la monocompétence … vers la polycompétence partagée
De même, l’activité qui était hyper-spécialisée sur le site-central s’est élargie aux autres tâches de la conception informatique client-serveur (conception, réalisation, maintenance). L’informaticien doit donc davantage communiquer avec les membres de son équipe pour disposer de toutes les informations nécessaires à la construction de l’application et acquérir les compétences sur des domaines que jamais il n’avait eu à traiter auparavant.
2. La coopération intergroupe augmente aussi.
Si d’un côté la communication intragroupe a dû se développer pour faire face aux exigences des nouvelles tâches informatiques, de l’autre, on se rend compte aussi que la collaboration entre les équipes s’est également intensifiée.
Du passage d’un mode de fonctionnement autarcique vers un mode de fonctionnement polycompétent. 
L’accession aux nouvelles technologies s’est accompagnée de l’élargissement du cercle des intervenants. Mais ces nouveaux spécialistes (ergonome, spécialiste réseau ) se sont appropriés certaines tâches traditionnellement dévolues aux informaticiens. Ces derniers sont alors obligés de multiplier les interactions avec ces partenaires, alors que jusqu’à présent, ils étaient plutôt habitués à travailler en vase clos. 
“ On travaille plus en liaison les uns avec les autres car  le travail est plus réparti. Ce qui oblige les gens à sortir plus de leur cocon ”.
Les compétences en jeu dans la conception d’un projet ne sont donc plus, comme dans le cas du site-central, concentrées dans une seule équipe, mais distribuées entre différents acteurs qui sont eux-mêmes spécialisés dans des domaines d’interventions spécifiques. Cet éclatement des qualifications rend plus difficile le fonctionnement autarcique des équipes de développement qui prévalait dans l’ancien environnement. De fait, cette coopération s’avère nécessaire parce que le nombre de connaissances à manipuler est très grand et que les savoirs sont répartis entre plusieurs personnes (interdépendance cognitive).
“Les compétences sont plus éparpillées, et donc beaucoup plus difficiles à regrouper, et une même personne ne peut pas tout connaître.”.
Du dictionnaire central … vers un réseau de personnes ressource, une “ cognition de groupe ”
Une autre conséquence de la migration vers l'environnement client-serveur est la “ perte ” d’un dictionnaire fédéral d’entités de programmation c’est-à-dire d’une base de savoirs partagés. Ce dictionnaire regroupait toutes les entités qui pouvaient être réutilisées dans différents projets informatiques. Cela accélérait le développement en évitant de reconstruire ce qui existait déjà. Pour pallier la disparition de cet outil, les informaticiens ont intensifié les relations inter-projets et inter-équipes afin de s’informer sur la nature des développements en cours et échanger des bouts de programmes. En somme, l’accroissement des relations professionnelles a donc permis de combler le déficit de ressources techniques.
“ Sur Pacbase,: on allait se servir dans le dictionnaire. Maintenant, on dialogue avec les gens pour dire “voilà, j’aurai besoin de ça et de ça : tu les as déjà développés?” Il y a donc ce côté relation avec d’autres services, ou avec d’autres projets pour intégrer leur travail ”.
3. Le jeu organisationnel se redéfinit.
Moins de contrôle
Parallèlement, le basculement d’un système technique vers un autre a conduit à une redistribution des zones de pouvoir entre les différentes catégories de personnel participant au développement de logiciels. D’abord le chef de projet, responsable de l’équipe, voit sa position de relais de l’information devenir moins stratégique, court-circuitée en cela par les possibilités du nouveau système technique. Les messageries et autres applications de travail collectif (collecticiel) qui “ médiatisent ” les relations entre personnes, confidentialisent et déshumanisent le contrôle qu’il pouvait effectuer : 
“ Avant, j’avais des contacts très proches avec les administrateurs de données. Maintenant, ce n’est plus le cas, puisqu’on travaille plus par mail (messagerie). Je trouve que l’on a moins de contact avec eux. ”
Des rivaux
De plus, les nouveaux acteurs (prestataires extérieurs et spécialistes) renforcent l’équipe mais s’arrogent du pouvoir. Ils remettent directement en cause les zones d’influence et les niches d’expertise que les informaticiens “maison” avaient acquis dans l’ancien système. Ce pouvoir était lié aux connaissances techniques qu’ils maîtrisaient dans une zone déterminée ; celle de l'environnement site-central. Or, avec l’avènement de systèmes client-serveur, ces informaticiens “ maîtrisent moins ”. Ils redeviennent des novices qui doivent réapprendre au contact de ces experts extérieurs. Il en résulte un fort sentiment de dépendance à l’égard de ces partenaires. 
“ On n’a pas tellement de répondant par rapport à ce que les prestataires proposent du fait de notre méconnaissance. C’est dur de se dire que l’on dépend de personnes extérieures alors que nous étions bons sur l’ancien environnement. C’est frustrant d’être derrière”
Moins de pouvoir
La prise de pouvoir du prestataire dans le groupe pose un autre problème : celui de la reconnaissance accordée par l’utilisateur. En effet, aux yeux du client, l’interlocuteur privilégié est le prestataire car il maîtrise ces nouvelles techniques et sait proposer des solutions innovantes. Les informaticiens subissent là un véritable affront et ressentent une réelle frustration. Des scissions se révèlent même dans le groupe entre “pro” et “anti” prestataires, et les rétentions d’informations, les conflits intragroupes deviennent les expressions symptomatiques de ce malaise.
“ Les utilisateurs voient d’ailleurs très bien que la compétence est chez les prestataires, et cela peut jouer contre notre image de marque. On peut être dévalorisé. Il peut y avoir une sorte de perte de confiance à l’égard du service. () C’est un petit peu malsain, c’est pas très bon, cela fait des clans ”
Des tactiques
Pour réduire cette menace, certaines équipes redistribuent stratégiquement les tâches de manière à cantonner le prestataire dans la programmation, loin de l’utilisateur final.
“ Il y a des équipes qui déchargent la réalisation sur les prestataires, en gardant le côté fonctionnel en interne. Travailler sur ces deux aspects -c’est bien- car on dépend moins des prestataires, et on a des compétences plus larges”.
Une autre conséquence de cette collectivisation du travail se manifeste par le glissement de responsabilités au profit des nouveaux partenaires du développement (prestataires, responsables réseaux et bases de données…). La réalisation de certaines tâches par ces acteurs (analyse et conception graphique de la maquette par le prestataire, gestion de la base de données par des spécialistes sybase…) est interprétée par l’informaticien à la fois comme un effritement de ses zones de responsabilité et comme un risque de déqualification. En effet, alors qu’il pensait retrouver une certaine légitimité technique par la maîtrise de ces nouveaux domaines, il se rend compte que cette expertise lui échappe pour être confiée à des spécialistes, souvent extérieurs à l’entreprise et plus compétents techniquement que lui. Du coup, l'informaticien a l'impression d'être à nouveau enfermé dans sa spécialité (la programmation), sans possibilité d'élargir son domaine de connaissances, ni d'avoir une maîtrise complète du processus de développement.
“ J’ai l’impression de plus me cantonner au rôle d’analyste programmeur qu’avant, où j’avais l’impression de faire un peu de choses (partie système et exploitation). Je sais que cette partie-là [gestion des bases de données], je ne m’en occuperai plus du tout. Je serai donc moins bon ”.

Et la place de l’utilisateur… (enfin)
L’expertise de l’informaticien est de plus en plus contestée par l’utilisateur. Ce dernier a maintenant pour référence les avantages et la convivialité de la micro-informatique et n’est plus dupe des propositions ou de l’argumentaire de l’informatique classique. Il devient extrêmement exigeant quant à la qualité, au coût et au délai des prestations fournies : la “balance” du pouvoir entre informaticien et utilisateur s’est donc inversée.
“ Avant, on pouvait facilement sortir l’argument : “la technique ne permet pas de le faire”. Là, les gens sont peut-être plus au courant des choses qui se font grâce aux outils de bureautique : “Dans word, on peut faire cela, donc c’est facile, et donc vous pouvez le faire”. On perd un peu notre pouvoir ”.
En somme, en changeant de système informatique, les informaticiens se sont peut-être libérés du carcan de Pacbase, mais ils sont devenus, paradoxalement, plus interdépendants des autres équipes nouvellement impliquées dans le processus de conception informatique et surtout s’ouvre la voie d’une relation avec les utilisateurs.
5. Discussion- Conclusion
Ces différents résultats font apparaître que la mutation des systèmes informatiques se caractérise par le développement de nouvelles formes d’articulation entre l’individu, le système et son environnement socio-professionnel. L’activité de conception évolue, et du coup, les compétences qui la supporte changent de nature aussi ; partant de la spécialisation fonctionnelle de chaque individu pour aller vers le développement d’un travail collectif, donc vers une transformation organisationnelle.
Dans cette perspective, l’évolution des interactions personne-machine ne doit plus être considérée comme un simple basculement technique et cognitif : elle doit aussi être pensée comme un processus complexe de changement et d’innovation dans les organisations [6]. Plus que la simple implantation d’une technique, le changement technologique conduit en effet à des modifications et/ou à des ajustements des structures socio-organisationnelles et humaines en place. Il provoque, bien sûr, des changements de matériels et de logiciels mais conduit aussi et surtout à des transfert de compétences et aux reconfigurations des modèles organisationnels existants.
La situation de migration technologique en conception informatique est en fait soumise à une dynamique de changement, faisant coïncider mutations techniques, acquisitions mentales et transformations sociales. 
Les changements observés sont structurels, et non conjoncturels. Lorsqu’elle est conquise, l’ouverture organisationnelle est souvent gardée. Elle inaugure des marges de liberté nouvelles. Ces changements sont d’abord des changements dans la structure des communications. En changeant d’environnement de programmation, les informaticiens découvrent de nouvelles formes d’interactions collectives ; certains peuvent les refuser et y résister, d’autres s’en emparer pour maîtriser de nouvelles zones d’incertitude, et ainsi gagner en légitimité et en pouvoir. Mais dans tous les cas, il s’agit d’une transformation de la structure même des communications : passage d’une communication hiérarchique, comme le veut le modèle du site-central ou des centaines de terminaux sont connectés à un gros ordinateur central, à une communication distribuée, comme le permet l’architecture client-serveur. Ainsi, en changeant d’environnement de programmation, les informaticiens découvrent, non seulement une technologie nouvelle, mais aussi et surtout une nouvelle organisation sociale des interactions. C’est cette dernière qui est porteuse des transformations organisationnelles observées : on passe d’une approche centralisée du développement sur le site-central (un informaticien = un programme ou un sous-programme) à une conception socialement distribuée sur le client-serveur (plusieurs intervenants = un programme). Les connaissances, les raisonnements et les méthodes de programmation sont alors co-produits, co-construits et finalement régulés par des interactions personne-machine plus riches et par des systèmes de coopération socio-professionnels plus intenses et variés.
 Ces résultats qui soulignent l’apparition de nouvelles formes d’articulation entre l’individu, le système technique et son environnement socio-professionnel ont certes été obtenus dans le cadre d’une étude limitée à une seule entreprise, durant une période déterminée et dans un environnement technique et humain donné. Ils peuvent cependant fournir des indicateurs précieux pour comprendre et accompagner les changements technologiques en œuvre, et notamment, ceux qui se déroulent avec le Web.
En effet, le développement exponentiel de ces technologies dans les entreprises n'est pas sans rappeler le formidable déploiement de l'informatique centralisée des années 80, période durant laquelle la ferveur techniciste prenait le pas sur l'individu. Aujourd'hui, les bénéfices supposés d'un site commercial Internet ou bien encore les avantages présumés d'un réseau extranet ou intranet suscitent un empressement qui conduit bien souvent l'entreprise, et les informaticiens en particulier, à privilégier la technologie sur les conditions humaines et sociales de son implantation.	
Dans cette vision technocentrique, l’homme occupe à nouveau une position résiduelle. On se focalise prioritairement sur l'interfaçage entre les machine (pour une transmission optimisée et sécurisée des données -d'où, paradoxalement, un certain retour au système centralisé-) au détriment de l'interface personne-machine. On ne parle d'ailleurs des utilisateurs qu'à travers les systèmes avec lesquels ils interagissent. Du coup, cet utilisateur, étant doué d'une formidable capacité d'adaptation, on lui demande tout simplement de s'adapter, sous peine d'être dépassé, voire rejeté. 
C'est pourquoi, nous pensons que les communautés techniques et scientifiques devront, comme ils l'ont fait pour le client-serveur, replacer l'utilisateur au centre des processus de conception et de diffusion des nouvelles technologies Web. Car, c'est par cette  approche "anthropocentrique" [11] qu'il sera possible de développer des systèmes qui intègreront véritablement les dimensions humaines et sociales de ces nouvelles modalités d'interaction personne-machine. 
La conclusion revient au titre de ce papier et propose de prendre au sérieux, c‘est à dire aussi dans son sens métaphorique originel, l’expression “ client-serveur ” : le “ serveur ”, machines, réseaux et logiciels et les professionnels qui les conçoivent et les mettent en œuvre sont au service de l’utilisateur “ client ”.
Bibliographie
[1]	Bobillier Chaumon M.E. Le transferts de compétences dans le cadre de changements technologiques : le cas du maquettage en conception informatique. Thèse de Doctorat, Université de Metz, Janvier 1999. 
[2]	Bobillier Chaumon M. E. Aspects psycho- ergonomiques du passage d’un environnement de conception site-central vers le client serveur. In Colloque  sur "Le Raisonnement : Questions vives et Prospectives". Université de Paris VIII  et Société Française de Psychologie -St Denis, 9-10 déc.1998. 
[3]	Darses F.; Falzon P. La conception collective : une approche de l'ergonomie cognitive, In G. de Terssac, E. Friedberg (Eds) "Coopération et conception",1996, Toulouse, Octares Edition, pp 123-147. 
[4]	Détienne F. Reasonning from a schema and from an analog in software code reuse”. In Koenemann-Bellibeau, T. Moher, S.P Robertson (Eds) “Empiricals Studies of Programmers : 4th workshop“ ,1991,  pp 5-22.
|5]	Frese M. et Hesse W. Analyse psychologique du travail des développeurs. In Forum Logiciel, août 1995,  pp 2-10.
[6]	Humphrey J. Au delà de la critique du déterminisme technologique. In Sociologie du travail, 2/89, 1989, pp 163-175
[7]	Rabin S. Transitioning Information Systems cobol developers into objet cobol technicians. In Object Magazine (janvier 1995),  pp 71-76.
[8]	Scholtz J., Wiedenbeck S., An analysis of novice programmers learning a second language. In C.R Cook, J. Scholtz, Spohrer (Eds), “Empiricals studies of programmers : Fifth workshop”, 1993, Ablex, pp 187-205.
[9]	Teasley B., Leventhal L.M, Rholman  S. Positive test biais in software testing by professionals : wath’s right and what’s wrong. In C.R. Cook, J.C. Scholtz, C. Spoher (Eds), “Empiricals Studies of Programmers : Fifth Workshop”, 1993, Eds Ablex, Norwood.
[10]	Winograd T. From programming environments to environments for designing. In Communications of the ACM, Mai 1995, Volume 38,  n°5, pp 45-52.
[11] Wisner A. Du contenu à la forme de la cognition située. (aspects psychologiques de l'anthropotechnologie) In R. Patesson (Ed) Intervenir par l'ergonomie, 1996, Vol 2, SELF, pp 94-99