Evolutions de l'activité et de l'organisation du travail lors du changement d'environnement de programmation chez les informaticiens.

• 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++, implémentation sur station de travail type client-serveur, interface graphique multimédia).

Quelques caractéristiques de la conception informatique

Les dimensions cognitives de l'activité de conception informatique

• ces problèmes tendent à être larges et complexes : non réductibles à des problèmes locaux ou à des sous-systèmes indépendants ;
• ils sont mal définis dans la mesure où des spécifications du problème manquent ; solutionner le problème consiste, en partie, à introduire des contraintes ;
• il existe de grands degrés de liberté dans l'état initial du problème ;
• il n'existe pas de chemin de solution prédéterminé : à chaque fois il faut réinventer le chemin ;
• il y a plusieurs solutions admissibles à un problème : le produit final n'est qu'un possible parmi d'autres ;
• l'évaluation de la solution est différée à l'établissement de la solution finale ;
• la résolution de problème exige la maîtrise et la mise en œuvre de multiples connaissances portant à la fois sur le domaine de l'utilisateur (connaissances fonctionnelles) et sur le domaine informatique (connaissances techniques) ;
• enfin, bien que la personne possède des procédures quasi-automatiques, le raisonnement n'est pas procéduralisé. En d'autres termes, le raisonnement ne se déroule pas de manière automatique et irréfléchie mais s'ajuste (opportunément et circonstanciellement) au contexte.

Les dimensions sociales de l'activité de conception informatique

1. la transformation des entreprises n'est pas seulement un processus qui doit être subi, il doit être précipité ;
2. le changement est une transformation naturelle de l'organisation, et seule l'informatique permet de la gérer convenablement ;
3. pour diverses raisons (histoire et culture de l'entreprise), les responsables ne sont pas à même de réaliser seuls les transformations ;
4. en revanche, les informaticiens sont les mieux placés pour mener à bien cette mission de transformation organisationnelle.

Quelques aspects du changement d'environnement de programmation

Problème et méthode

Problème posé

• certaines formes de raisonnement de conception ;
• et certaines formes d'organisation sociale de l'activité de conception.

1. L'environnement de programmation constitue pour l'informaticien un cadre général d'organisation de son activité mentale.
2. L'environnement de programmation façonne les stratégies cognitives de résolution de problème.
3. 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.

Cadre méthodologique

Notre étude répond à une demande d'une entreprise d'informatique, employant 800 informaticiens, qui souhaite 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 seul paradigme procédural pour logique de conception, l'enjeu est double : optimiser les transferts de compétences entre les deux environnements et favoriser l'acceptation et l'appropriation du ces outils. Caractéristiques de la population étudiée Notre méthodologie est comparative. Elle vise à mesurer les écarts et les points de convergence entre différents types de développeurs appartenant à des services distincts : Trois situations de travail ont été analysées :

1. Une équipe de cinq informaticiens travaillant avec un environnement de programmation procédural (Pacbase1), dans une architecture site-central ;
2. Une équipe de quatre informaticiens expérimentés dans le " nouvel " environnement de programmation orienté objet (NSDK2) dans une architecture client-serveur ;
3. Une équipe de quatre informaticiens effectuant la transition du site-central vers le client-serveur.

Notre démarche porte sur une situation réelle et complexe. Pour cerner les principaux phénomènes en œuvre dans ces situations de travail, trois techniques d'enquête s'appuyant sur l'analyse de protocoles verbaux (Bainbridge, 1990) ont été utilisées :

1. Des entretiens : Au cours d'entretiens exploratoires, menés de manière semi-directive, trois thèmes étaient systématiquement abordés : les facteurs techniques, les facteurs organisationnels et les facteurs humains des environnements de développement. Sur la base de ces entretiens exploratoires (intégralement retranscrits), nous nous sommes livrés à une analyse thématique dont l'objectif était de trouver des régularités conceptuelles dans les processus discursifs des interviewés. Cette technique nous a permis d'obtenir des informations générales sur l'organisation de l'activité.
2. Les protocoles verbaux liés au travail sur l'écran : les verbalisations recueillies sont des verbalisations simultanées à la conception de programmes. Elles fournissent des indicateurs de l'activité en temps réel. La verbalisation est en effet une situation où les représentations mentales des sujets et les procédures liées à l'activité s'expriment assez clairement dans les situations de résolution de problème (Visser et Morrais, 1988).
3. Observations et analyse de documents : elles portaient sur l'activité de conception et avaient pour but de collecter toutes les informations dont le développeur pouvait se servir (documents papiers, aides au travail), ainsi que des difficultés auxquelles il pouvait être confronté au cours de la programmation.

Présentation des résultats

Les aspects cognitifs du changement d'environnement de programmation

L'organisation de l'activité apparaît comme planifiée et hiérarchisée. L'environnement de programmation Pacbase impose par défaut un squelette de maquettage et un système de grille de saisie pour concevoir la maquette. De plus, les écrans récupérés sur des projets antérieurs fournissent des guides stables et fiables pour le développement de la maquette. " Il est toujours plus facile de critiquer et de recomposer autour de quelque chose qui existe que de créer quelque chose qui n'existe pas encore " Dans de telles conditions, l'activité de l'informaticien est assujettie aux paradigmes de conception de Pacbase. Toute dérogation par rapport à la démarche prescrite se solde par un blocage du système. Aussi, ces canevas structurent-ils l'activité de manière hiérarchique. Le développeur peut être vu comme un être relativement passif qui répond aux sollicitations de son environnement de développement : " Il y a un déroulement logique qu'il vaut mieux respecter, parce que sinon Pacbase nous jette ! Ó Sur l'environnement site-central, la logique de conception est subordonnée à la structure fonctionnelle du squelette de Pacbase. L'informaticien se soumet aux questions du squelette de maquettage pour développer les interfaces et déterminer les séquences d'interaction homme/machine. Sa marge de manoeuvre est relativement restreinte au regard des possibilités techniques offertes par l'outil : organisation séquentielle des écrans, mode transactionnel du dialogue, gestion locale des traitements (un traitement touche uniquement l'écran dans lequel il se trouve), interface en mode textuel, etc. La logique de conception est qualifiée de fonctionnelle, puisque orientée par et pour le système : " L'enchaînement des écrans sur site-central est assez strict : on a un premier écran qui débranche sur un autre, puis sur un autre... il y a donc une certaine rigueur d'enchaînement qu'il convient de suivre (...) on ne se casse donc pas la tête et on ne cherche pas à savoir ". L'informaticien doit ainsi exprimer sa solution sous formes de structures hiérarchisées, correspondant à l'organisation des fonctions de base du squelette de Pacbase : " Donc, là je suis ce que le squelette me dit de faire. (...) je m'insère donc dans les fonctions de 10 à 40 pour contrôler ce que l'utilisateur a saisi, et lui envoyer des messages, traiter des informations, mettre à jour les bases de données, etc. selon ce qu'il a demandé ". On remarque cependant que pour minimiser les risques d'incompatibilité entre la solution produite et la solution requise, le développeur récupère des écrans préexistants pour en extraire des solutions appropriées au problème posé. Dans ce cas, la réutilisation et l'affectation de ces solutions de maquettage sont analogiques : " Il m'est arrivé de créer de toutes pièces une maquette, mais je perds tellement de temps à essayer de me rappeler ce que j'ai mis là, que je reprends en général un modèle, quitte à modifier structurellement. Mais, j'ai quand même un modèle ".
Le cas de l'environnement de programmation NSDK en client-serveur

L'environnement NSDK se démarque de Pacbase par l'absence de prescriptions fonctionnelles et techniques fortes ; d'où une plus grande liberté laissée à l'informaticien dans l'aménagement de son activité de conception. Du coup, l'organisation de celle-ci devient plus opportuniste dans la mesure où l'utilisateur a la possibilité d'ajuster circonstanciellement son plan d'action aux incidents rencontrés durant la conception, ou bien en fonction de découverte de procédures ou de stratégies qui se révèlent plus économiques et/ou plus intéressantes d'un point de vue cognitif ou technique. L'informaticien devient en quelque sorte l'artisan de sa propre démarche. Si quelques étapes-clefs du maquettage demeurent néanmoins proches de celles mises en oeuvre dans le site-central (définition d'entités constitutives, présentation normalisée des écrans, etc.), le déclenchement de ces phases répond tout de même davantage à des opportunités de conception qu'il ne dépend des contraintes émanant de l'outil. En d'autres termes, l'activité se déploie plus selon un mode erratique, au gré des circonstances et des découvertes de la conception, que sur un modèle hiérarchique, tributaire d'un moule de conception. : " NSDK est assez différent de Pacbase parce que dans Pac, il y a des étapes qui doivent être suivies. Avec NSDK, tout se définit au fil de l'eau, c'est-à-dire au cours du déroulement de la conception, lorsqu'on en a besoin. " Le langage de programmation interprété de NSDK favorise d'ailleurs ce tâtonnement dans la structuration de l'activité en permettant une simulation régulière et rapide de l'interface produite : " On peut tester chaque fenêtre en temps réel (...) En fait, c'est du tâtonnement, c'est de l'ajustement un petit peu à chaque fois. Il y a donc une liberté pour le programmeur qui est tout autre " NSDK est un environnement nouveau pour l'informaticien. Il n'existe donc pas de projets préexistants qui pourraient lui fournir des sources d'inspiration fiables, à l'instar de Pacbase. L'autre particularité est liée à la logique événementielle de la maquette et à la richesse des possibilités de conception. En effet, dans ce type d'interface, l'ordonnancement des opérations n'est pas déterminé a priori lors de la conception des fenêtres, mais dépend essentiellement de l'arrivée des données et des objectifs de l'utilisateur. L'informaticien dote ainsi la maquette de Òvirtualités comportementalesÓ, c'est-à-dire de conduites possibles que l'utilisateur pourra déclencher selon ses objectifs d'action : " On doit imaginer tout ce que l'utilisateur pourrait ou risque d'être amené à faire. (...) il faut cerner toutes les possibilités, c'est-à-dire que si dans un cas, ils veulent modifier et supprimer, il faut forcément qu'il y ait quelque chose dans la ligne ". Par ailleurs, une action de l'utilisateur sur l'interface peut engendrer plusieurs réactions possibles de la maquette (événements). Cette programmation événementielle de l'interface nécessite que l'informaticien anticipe très tôt les effets de ces événements sur les autres constituants de la maquette. C'est ce que nous appelons la gestion prévisionnelle et contextuelle des événements. Dès lors, pour gérer l'ensemble de ces ressources et réaliser efficacement ces différentes tâches de conception, l'informaticien se livre à une construction itérative de la solution, c'est-à-dire à un cycle d'exécution, de test et de correction de la solution. Dans ce cas, l'élaboration des procédures de résolution est dynamique.
Le cas intermédiaire ; anciennement site-central en train de devenir client-serveur

La transition est difficile à négocier. En passant du site-central au client-serveur, l'informaticien se trouve donc affranchi du carcan du site-central. Il doit alors se séparer d'un modèle d'organisation très réglementé de la tâche pour adopter un mode de gestion plus opportuniste. Conceptuellement, cela signifie qu'il doit faire abstraction de la plupart de ses automatismes de planification pour mettre en place des conduites de travail plus souples et réactives. En d'autres termes, il ne s'agit plus pour lui d'ajuster son plan d'action aux prescriptions du système, mais de l'adapter circonstanciellement au progrès de la résolution. Ce changement technique constitue en fait un passage difficile pour ces débutants car culturellement, cela signifie rompre avec des règles et des normes de conception qui restent malgré tout profondément enracinées en eux. Pour la plupart de ces développeurs en effet, Pacbase constitue la seule expérience et l'unique référence en termes d'outils de programmation: pendant de nombreuses années, il leur dictait chaque but et chaque action à réaliser. Aussi, confrontés à l'apprentissage de NSDK, ces débutants deviennent pour la première fois de leur carrière, les seuls initiateurs de leur activité. Ils doivent fixer et organiser eux-mêmes les étapes de la conception, décider des différentes actions à entreprendre et sélectionner les ressources de l'environnement à utiliser. Ils ne peuvent plus compter sur les canevas techniques pour guider leur activité, ni sur des modèles techniques pour les aider à planifier leurs solutions. Du coup, cette liberté d'action qui aurait pu paraître à bien des égards comme un acquis fondamental de la transition technologique, se révèle paradoxalement problématique pour ces novices. L'absence brutale de repères les déstabilise plus qu'elle ne les rassure. Ce malaise se manifeste d'ailleurs clairement au travers de la gestion qu'ils font des ressources de l'environnement durant la conception. Deux conduites extrêmes se démarquent ainsi :

• D'un coté, il y a ceux qui s'autocensurent volontairement en n'exploitant que quelques possibilités techniques de l'environnement. Les solutions proposées sont alors relativement pauvres et peu originales. En fait, ils prennent très peu de risques pour éviter de commettre des erreurs de conception. " J'ai l'impression que l'on est tellement obligé de se limiter, pour ne pas que cela dérive trop que cela en revient à des écrans comme ça [site-central] ".
• De l'autre, il y a les informaticiens qui se livrent à une surexploitation anarchique et superfétatoire des possibilités de l'outil. L'informaticien teste toutes les ressources de l'environnement et planifie une solution qui se révèle finalement assez excentrique. " Le plus difficile, c'est le maquettage : arriver à des écrans qui ne soient pas des arbres de Noël, qui ne clignotent pas de partout. "

• des comportements incohérents de la maquette : l'informaticien met davantage en oeuvre une gestion locale des événements (reprise du contexte site-central où un traitement touchait un écran et un seul) qu'une gestion contextuelle (un événement peut avoir des répercussions sur l'ensemble de l'interface) ;
• l'enchaînement arbitraire des fenêtres : l'enchaînement des fenêtres suit plus souvent la logique séquentielle et synchrone héritée de Pacbase, que celle événementielle et asynchrone prônée par NSDK ;
• l'ambiguïté des termes désignant les objets graphiques : les intitulés donnés aux objets graphiques (boutons, menus) s'inspirent des noms des commandes Pacbase ;
• la mauvaise répartition des commandes sur la fenêtre : la répartition de ces fonctions sur l'interface NSDK se base sur celle de Pacbase. On trouve ainsi un maximum d'informations concentré sur une seule zone de l'écran (fenêtre ou menu).

Les aspects socio-organisationnels du changement d'environnement de programmation

Sur la base des entretiens réalisés, un constat ressort : 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).

• Aspect modulaire de la conception.
  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 "
• Déficit de connaissances techniques.
  Le nouvel environnement nécessite l'acquisition de 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 "
• Polyvalence requise.
  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.

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 par :
- le passage d'un mode de fonctionnement autarcique à 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 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, bien que celle-ci 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. " .
- l'absence de dictionnaire fédéral c'est-à-dire d'une base de savoirs partagés. Une autre conséquence de la migration vers l'environnement client-serveur est l'absence d'un dictionnaire fédéral d'entités de programmation. 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 ".
Le jeu organisationnel se redéfinit.

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) 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. " Ensuite, les nouveaux acteurs (prestataires extérieurs et spécialistes) qui, tout en renforçant l'équipe, 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 du client-serveur, ces informaticiens ne maîtrisent plus rien. Ils redeviennent de simples novices qui doivent tout 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 " 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 " 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 " . 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. 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 "

Interprétation des résultats

Conclusion

Bibliographie

• Alsène E. (1990) Les impacts de la technologie sur l'organisation. In Sociologie du travail, n83/90, pp 321-337
• BAINBRIDGE, L. (1990). Verbal protocol analysis. Evaluation of human work: a pratical ergonomics methodology. Wilson J.R. et Corlett E.N. (Eds). London : Taylor and Francis, 161-179.
• BALLE, C. PEAUCELLE, J-L. (1972).Le pouvoir informatique dans l'entreprise. Paris : les éditions d'organisation.
• BOBILLER CHAUMON, M.E., (1997) Changements techniques et évolution des compétences : d'une dépendance technique à une interdépendance collective, in Compétences et contextes professionnels : perspectives psychosociales, Brangier, E., Dubois, N., Tarquinio, C., (Eds), Actes du 3ème colloque international de l'ADRIPS, Metz : Laboratoire de Psychologie.173-181.
• BRANGIER, E., BOBILLIER-CHAUMON, M-E., (1996).- Réflexions sur l'intervention en ergonomie de la programmation .- In PATESSON, R. (Ed), Intervenir par l'ergonomie, SELF, Bruxelles. Vol 2, 176-183.
• Delmond D.H. (1995) Perception, rôle et mode de gestion de l'informatique dans les entreprise : le cas des services études. In Actes du 10¡ Colloque CREIS, Responsabilités sociales et formation des acteurs de l'informatisation, Belgique, Namur, pp. 57-68.
• Ducateau C.F. (1995) Contribution à la réflexion sur les responsabilités sociales de l'informaticien concepteur de logiciel. In Actes du 10¡ Colloque CREIS, Responsabilités sociales et formation des acteurs de l'informatisation, Belgique, pp. 149-157
• Falzon P. (1995) Les activités de conception : réflexions introductives in Performances Humaines et Techniques : L'activité des concepteurs, 74, Toulouse, pp. 6-11
• Frese M. et Hesse W. (1995) Analyse psychologique du travail des développeurs. In Forum Logiciel, août 1995, pp 2-10. Galand B. (1995) La ville artificielle. Les réseaux : de la responsabilité des informaticiens à celle des utilisateurs. In Actes du 10¡ Colloque CREIS, Responsabilités sociales et formation des acteurs de l'informatisation, Belgique, Namur, pp187-197
• Humphrey J. (1989) Au delà de la critique du déterminisme technologique. In Sociologie du travail, 2/89 pp 163-175
• Marinko M.J ; Jenry J.W., Zmud R..W. (1996) An attributional explanation of indivudual resistance to the introduction of information technologies in the workplace. Iin Behaviour & Information Technology, Vo 15, n8 5, pp 313-330
• Pavé F. (1993) Les nouvelles technologies de l'information et de la communication et l'organisation du travail. In Freeman C., Mendras H. (Eds) Le paradigme informatique : technologie et informatique sociales, Paris, Descartes, pp 77-121
• Prigent V. (1995) L'appropriation d'une nouvelle technique de communication dans l'entreprise. In Humanisme et Entreprise, n895-112, pp 81-102.
• Rabin S. (1995) Transitioning Information Systems cobol developers into objet cobol technicians. In Object Magazine (janvier 1995), pp 71-76.
• SCHON, D.A., (1967) Technology and Change, New York : Delta Book.
• Teiger C. (1993/3) L'approche ergonomique : du travail humain à l'activité des hommes et des femmes au travail. In Education permanent :comprendre le travail, n116, pp 71-96.
• Visser W., Hoc J-M. (1990) Expert software design strategies. In Hoc J-M., Green T.R.G., Samurcay R. And Gilmore D.J. (Eds) Psychology of programming, Academic Press, pp 235-250.
• Visser W., Morrais A., (1988) " Concurrent use of different techniques for gathering data on the programming activity " , RR 939, INRIA, Rocquencourt.