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

Marc-Eric BOBILLIER CHAUMON, Éric BRANGIER
Cet article relate une recherche portant sur les effets du changement d'environnement de programmation chez des informaticiens. Depuis quelques années en effet, les innovations techniques en matière d'outils de conception (réseau technique, interfaces graphiques, accès réparti des données et des traitements ...) ont bouleversé les repères traditionnels de l'informaticien. Plus concrètement, Il s'agit du passage : Techniquement, il est clair que ces différentes innovations offrent de nouvelles possibilités de développement grâce à des interfaces homme-machine plus ergonomiques et des traitements plus rapides. Mais ces évolutions ne sont pas neutres pour ceux qui les reçoivent et/ou les subissent ; principalement parce qu'elles induisent de profondes remises en cause dans les acquis cognitifs et opératoires des informaticiens. Ces derniers sont ainsi amenés à apprendre ou à réapprendre des comportements de travail, des logiques d'activité, des stratégies cognitives qui correspondent aux exigences des nouveaux environnements de conception. Dans le même temps, ils doivent aussi démontrer de réelles capacités d'insertion dans les nouvelles structures organisationnelles naissantes. C'est à l'analyse de ces différentes mutations que cet article est consacré. Cette étude, menée dans une entreprise de 800 informaticiens, porte sur les impacts du changement d'environnement de développement. Dans une première partie, nous présenterons quelques caractéristiques de l'activité de conception informatique, en montrant que les aspects des environnements de programmation façonnent à la fois les cognitions en œuvre chez les informaticiens et les aspects socio-organisationnels de leur activité. Ceci nous amènera, dans une deuxième partie, à exposer la problématique et la méthodologie de cette recherche. Enfin, dans une dernière partie, nous nous livrerons à l'analyse et à l'interprétation des résultats.

Quelques caractéristiques de la conception informatique

Notre étude se fonde sur la compréhension des aspects cognitifs et psychosociaux de l'activité de conception informatique.

Les dimensions cognitives de l'activité de conception informatique

Pour la plupart des auteurs, la conception informatique est une activité de résolution de problème dont la double tâche consiste à définir un problème et trouver sa solution. Un certain nombre de traits sont caractéristiques des problèmes de conception (Falzon, 1995, Visser et Hoc, 1990) :

Les dimensions sociales de l'activité de conception informatique

Les premières études réalisées dans ce domaine (Boguslaw, 1965 ; Schon, 1967) indiquaient déjà que les informaticiens percevaient la technique comme un élément régulateur des transformations organisationnelles. Plus précisément, les informaticiens auraient tendance à concevoir l'avenir des organisations sur la base de quatre postulats fondamentaux (Balle et Peaucelle, 1972) :
  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.
Balle et Peaucelle faisaient aussi remarquer que le changement n'est pas homogène entre les organisations. Il dépend de la culture informatique qui est envisagée à travers une conception principalement normative des organisations et vise généralement à réduire les entreprises à des entités presque entièrement automatisables. Pour Pavé (1993) l'informatisation requiert une modélisation préalable de l'activité dans le but de l'automatiser. Aussi, l'action informatique s'apparente-t-elle à une forme d'aménagement coercitive du monde. Mais, plus récemment, l'apparition de logiciels plus souples (systèmes experts, intelligence artificielle, multimédia ...) et de méthodes de conception plus participatives (prototypage, maquettage ...) ont permis aux utilisateurs d'intervenir au coeur même du processus de développement, et de s'opposer ainsi au diktat technique des informaticiens. Du coup, l'utilisateur a progressivement repris le pouvoir sur l'informatique, en contrôlant les budgets et parfois en externalisant l'informatique vers des sociétés extérieures (Delmond, 1995 ; Ducateau, 1995 ; Galland, 1995). Ceci étant dit, il n'en demeure pas moins que la culture informatique reste encore le meilleur vecteur pour assurer le grand dessein de la rationalisation, en introduisant dans les organisations une codification des activités, une transformation des langages professionnels, une transposition des règles de gestion des entreprises, une redéfinition des procédures de travail, une réduction des effectifs ... En somme, une formalisation des pratiques rattachées à l'information (Humphrey, 1989 ; Alsène, 1990). Par ailleurs, comme nous le laissions entendre plus haut, l'informatique n'impose pas en soi un seul type d'organisation du travail, mais en rend possible diverses formes . En ce sens la rationalisation qui accompagne l'introduction d'une nouvelle technologie serait liée aux possibilités ou non d'apprentissage par les individus, et à leur participation ou non à la dynamique de changement qui s'instaure (Prigent, 1995 ; Marinko, Jenry et Zmud, 1996). En fait, ces transformations prendraient leurs origines dans les interactions informaticiens/environnements de programmation. Aussi, plus qu'un simple outil de production de logiciels, l'environnement de développement serait également l'outil qui code en machine les possibilités de transformations socio-organisationnelles. Il serait donc à la fois un objet technique et social (Brangier et Bobillier Chaumon, 1996).

Quelques aspects du changement d'environnement de programmation

L'environnement de programmation se présente à la fois comme une structure virtuelle nécessitant une activité cognitive de résolution de problème, et comme un outil permettant la transformation des organisations. Dans une étude portant sur le changement de systèmes de développement réalisée auprès d'une trentaine de firmes allemandes et suisses, Frese et Hesse (1995) ont remarqué que les informaticiens jugent la facilité d'utilisation et d'apprentissage des nouveaux outils comme des critères plus importants (40% des réponses) que l'obtention de fonctionnalités techniques plus évoluées. Ainsi, les critères " sans défaut ", " facile à combiner avec d'autres outils " ou " performants " sont mentionnés par seulement 5% des participants. Pour ces auteurs, ce sont les changements d'outils trop rapides et trop fréquents qui obligent les informaticiens à multiplier les (ré)apprentissages. Ce qui génère une surcharge de travail, du stress et finalement un rejet du système. A l'inverse, les systèmes qui se révèlent compatibles avec les pratiques de travail antérieures des développeurs diminuent les temps de formation aux outils et favorisent leur appropriation. Une autre étude réalisée par Rabin (1995) sur une dizaine de services informatiques confirme ces résultats. Ce chercheur s'est intéressé aux entreprises qui avaient décidé de procéder au changement brutal de leur langage de programmation : passage d'un paradigme procédural employé depuis une vingtaine d'années vers un paradigme orienté objet. Le bilan de ce transfert technologique fut catastrophique : rallongement des temps de développement, augmentation des erreurs de conception, baisse de la qualité des applications, accroissement des coûts de formation, et bien sûr insatisfaction des clients. Les développeurs éprouvèrent les plus grandes difficultés à comprendre et à programmer avec le nouveau paradigme. Celui-ci exigeait une logique de conception totalement différente de celle qu'ils maîtrisaient jusqu'alors. A travers cette recherche, Rabin (1995) souligne que le choix du nouveau langage s'est davantage fait en fonction de considérations marketing (être parmi les premiers à utiliser la technologie objet) et économiques (diminuer les coûts de développement par la réutilisation objet) qu'à partir d'une véritable réflexion sur les capacités d'évolution et d'adaptation des informaticiens. Finalement, le peu d'études dont nous disposons sur ce thème semble montrer que le choix d'une nouvelle technologie de conception ne peut se faire sans une prise en compte préalable de l'existant. Ce qui soulève la question plus fondamentale de l'adéquation des nouveaux environnements de programmation à la culture technique et professionnelle des informaticiens. Plus les caractéristiques du système cible sont éloignées du système source, plus les risques des ruptures cognitives et opératoires entre les deux environnements seront importants, et plus grand aussi sera le risque de rejet du nouveau dispositif par l'informaticien. Dans ces conditions, il semble donc que la transition d'un système de travail vers un autre correspond à une situation d'acquisition mentale, résultant à la fois du déterminisme technologique des nouveaux dispositifs, de l'expérience professionnelle acquise, et des stratégies individuelles et collectives fondées à partir de ce que les individus pensent de ce qu'ils font ou ont à faire face à ces changements.

Problème et méthode

Problème posé

Un problème, rarement abordé dans les approches sur l'environnement de programmation, est donc de considérer qu'il affecte plus ou moins directement : Du coup, 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 trois hypothèses :
  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

Contexte de la recherche

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.
Dans la mesure du possible, nous avons essayé de construire un échantillon qui soit homogène et représentatif3 de l'ensemble des développeurs de chaque service. Par ailleurs, notre cadre d'observation porte exclusivement sur l'étape de maquettage conçue comme un cycle de résolution / implémentation, où l'individu est engagé dans la résolution d'un problème (ici, concevoir la maquette), puis dans la programmation de la solution retenue.
Déroulement de l'enquête et recueil de données

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

La présentation des résultats se focalise sur les aspects cognitifs et sociaux du changement d'environnement de programmation en reprenant, pas à pas, le cas de l'environnement procédural, de l'environnement objet et du passage du procédural à l'objet.

Les aspects cognitifs du changement d'environnement de programmation

Le cas de l'environnement de programmation procédural : Pacbase sur site-central

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 :

Aussi, si quelques-uns furent tentés de profiter de ces nouveaux espaces de liberté, la grande majorité appréhende avec circonspection ces nouvelles voies de développement par crainte de se perdre dans les méandres du développement client serveur. Finalement, il ressort que l'informaticien novice éprouve des difficultés pour s'émanciper techniquement, c'est-à-dire pour s'affranchir des guides de conception. Il recherche la tutelle “technique” de NSDK alors que cet environnement se garde justement d'imposer des trames pour l'action. Il cherche des repères dans un environnement qui n'offre que des contingences d'action. Il n'en sera que plus désorienté : " Avant, on avait le confort de la certitude. C'était sécurisant. Ce repère qu'on avait a disparu. Il est difficile de ne plus se référer à un signal aussi fort ". Pour ces diverses raisons, des erreurs de résolution dues à des transferts de compétences inappropriés vont apparaître. D'autant plus que les aspects techniques du maquettage sont nouveaux pour le novice. Jamais en effet, il n'a eu à s'en soucier sur le site-central. Pressé par ses obligations de résultats et incité par ses automatismes cognitifs hérités de l'ancien système, l'informaticien a très vite tendance à réutiliser les stratégies intellectuelles qu'il connaît le mieux, à savoir celles issues de Pacbase (site-central) : " Le problème, c'est d'avoir cette logique micro, client-serveur. Elle est contraire au site-central, où c'était assez rigide, où il y avait des écrans, et on allait sur telle fonction, on faisait la réception, etc. Là, on doit se débrouiller tout seul pour laisser à l'utilisateur la possibilité de se balader comme il veut. C'est pas évident. ". La plupart de ces analogies se révèlent cependant incompatibles avec le contexte de conception graphique. Plus précisément, les informaticiens se raccrochent à des anachronismes, en conservant des pratiques qui n'ont plus aucun fondement rationnel et fonctionnel dans le nouvel environnement de travail. En cela, ils expliqueraient les nombreuses erreurs de maquettage commises par les informaticiens novices, et plus particulièrement celles produisant :

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

L'analyse des données met en évidence des organisations du travail différentes selon les trois cas considérés : les environnements de programmation procéduraux s'accompagnant d'organisation fermée, tandis que les l'environnements orienté objet et client-serveur s'accommodent d'organisation plus ouverte. Aussi, l'évolution technologique de Pacbase vers NSDK est associée à de nouvelles formes de coopération au travail.
La coopération intragroupe augmente.

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).

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 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

Ces différents résultats font apparaître que les informaticiens, confrontés à l'évolution technologique de leur environnement de conception, doivent faire face à l'articulation de trois réalités : opératoires, cognitives et socio-professionnelles. Tout d'abord, les situations de travail évoluent sur le plan du contenu de la tâche et de leur organisation, ce qui amène les informaticiens à revoir leur manière de structurer leur activité. Ensuite, les changements techniques obligent les individus à apprendre d'autres raisonnements de conception et à déterminer de nouveaux modes d'interaction homme-machine. Enfin, l'évolution technique impose aux informaticiens de 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. Ainsi, la mutation des systèmes informatiques se caractérise par de nouvelles formes d'articulation entre l'individu, le système et son activité. La tâche elle-même se modifie (la prescription informatique évolue vers une définition par objectifs, et de nouvelles tâches de diagnostic et de coordination apparaissent) tandis que les conditions d'exercice de l'activité se transforment (les repères disparaissent, les modes d'analyse et de résolution deviennent plus globaux). De nouveaux compromis cognitifs et sociaux sont à construire dans des situations de plus en plus aléatoires et de moins en moins répétitives. L'évolution technique s'accompagne de la redéfinition d'un nouvel ordre socio-organisationnel ; elle dérégule des pratiques organisationnelles antérieures (en termes de pratique, de jeux de pouvoir, d'autonomie et de reconnaissance) pour y substituer d'autres formes de réglementation. Dans cette perspective, le transfert technologique ne doit plus être considéré comme un simple basculement technique : il doit être pensé comme un processus complexe de changement et d'innovation dans les organisations. Plus que la simple implantation d'une technique, le transfert 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 mais conduit aussi et surtout à des transfert de compétences (Bobillier Chaumon, 1997) et aux reconfigurations des modèles organisationnels en place. Le changement technique ouvre un nouvel espace de représentations (cognitives, organisationnelles et socio-professionnelles) qui implique un repositionnement des informaticiens en termes de raisonnements, d'identité et de culture. 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 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 les enjeux organisationnels. 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 homme-machine plus riches et par des systèmes de coopération socio-professionnels plus intenses et variés.

Conclusion

Au final, ce qui semble déterminer l'appropriation et l'acceptation des nouvelles technologies de conception informatiques par les informaticiens, c'est moins la complexité technique intrinsèque de ces dispositifs que la série de ruptures qu'ils engendrent (1) sur les modes de raisonnement, (2) sur les conditions de mise en œuvre de l'activité et (3) sur les principes de coopération au sein du cycle de travail. Le changement d'environnement de programmation n'est donc pas neutre. Il implique de profondes transformations (cognitives, organisationnelles et culturelles), par essence déstabilisantes, qui peuvent inquiéter les informaticiens car il est difficile de rompre avec un passé qu'ils connaissent et maîtrisent bien. C'est pourquoi, nous pensons qu'il faut ramener les enjeux sociaux et humains au cœur des préoccupations du changement technologique, bien avant la recherche d'une quelconque optimisation des processus de développement existants. Dans cette perspective, anticiper et comprendre ces mutations, c'est se donner les clefs pour gérer au mieux la transition technologique. Et, identifier les transformations en jeu, c'est se donner les moyens de répertorier et/ou d'adapter les techniques dont l'entreprise a besoin et de créer les conditions pour un accompagnement optimal du changement.

Bibliographie

1 Pacbase : est un atelier de génie logiciel permettant la conception de programmes informatiques sur site-central.
2 NSDK : est environnement de programmation de 4ème génération dédié à la conception de logiciels développés avec une architecture client-serveur.
3 Nous avons pris des personnes jeunes (moyenne d'âge 30 ans) et expérimentées (au moins 5 ans d'ancienneté dans l'entreprise) et estimé expertes dans leur langage de programmation respectif (3 ans minimum d'expérience avec les environnements de développement). Enfin, nous avons veillé à ce que leurs projets de travail portent sensiblement sur le même domaine (activités bancaires et financières) et qu'ils en soient à des étapes de développement pratiquement identiques.