Introduction

1Le contexte socio-économique contemporain est caractérisé, notamment, par plusieurs types d’expérimentations présentées comme des alternatives partielles à l’entreprise industrielle standard, à la société de consommation et à l’emprise des multinationales. Certaines, s’inspirant des principes de l’open source, proposent de fournir des produits et des services rapidement disponibles et perfectibles par des « communautés » d’utilisateurs bienveillants prêts à donner de leur temps et à partager des connaissances. D’autres, sur le modèle de « l’entreprise libérée », visent à remettre en cause le mode de management hiérarchique, en donnant plus de place aux producteurs dans les décisions stratégiques. Par ailleurs, l’émergence des Fab Labs et celle des hackerspaces sont accompagnées de discours promettant d’accélérer les processus d’innovations marchandes. Grâce à leur caractère ambivalent, ces différents types d’initiatives suscitent un grand intérêt de la part de certains dirigeants, qui mettent en place des expérimentations en entreprise (Autissier & Métais-Wiersch, 2016 ; Bréchignac, 2017).

2Ces « innovations » organisationnelles s’inscrivent dans le prolongement de mouvements militants qui s’enracinent dans la contre-culture des années 1960, ce qui leur confère simultanément des dimensions politiques et économiques. D’ailleurs, certains observateurs ont très tôt perçu cette profusion « d’innovations » comme la manifestation d’une réelle transmutation du capitalisme (Azaïs et al., 2001 ; Lojkine, 2002). Qu’ils en fassent la critique – en pointant leurs contradictions – ou l’éloge, de nombreux analystes partagent une même croyance : les acteurs du « libre » et de l’ouverture (open source, open space, open data, open design, etc.), ceux de l’autoproduction hors-marché et de l’auto-organisation réticulaire, sont en capacité « d’ouvrir des voies à l’exode de la société du travail et de la marchandise » (Gorz, 2007). D’autres commentateurs sont plus nuancés (Loveluk, 2015). Ils soulignent, en effet, la diversité des choix technico-économiques concernant internet – horizontalité et gratuité versus verticalité et marchandisation – et la variété des modes de régulation qui s’y déploient – contrôle par des oligopoles versus autorégulation.

3En s’inspirant de cette profusion d’utopies numériques, des cabinets de consultants et des experts en organisation proposent des méthodes et des techniques de rationalisation du travail. Il en va ainsi des méthodes dites agiles, présentées par leurs promoteurs comme des moyens rationnels de fluidifier le fonctionnement des entreprises et de réduire les « temps de cycle », dans un contexte économique réputé caractérisé par « l’accélération de l’innovation ». Au-delà des discours promettant une flexibilité accrue de l’organisation, comment expliquer que des directions d’entreprise et une partie de leurs collaborateurs adoptent des méthodes présentées comme expérimentales et antihiérarchiques ? Leur mise en œuvre dans des entreprises complexes et diversifiées est-elle compatible avec les dispositifs et les pratiques existants ? Quel est le coût humain des efforts d’application de ces méthodes ?

4Pour apporter quelques éléments de réponse, nous montrons tout d’abord que, dans ses principes de justification, la méthode agile présente plusieurs points communs avec le courant de l’open source et celui de l’entreprise libérée. Cette proximité explique l’adhésion des informaticiens et des dirigeants à la mise en œuvre de cette méthode, malgré les paradoxes qui la caractérisent. Ensuite nous présentons les résultats d’une étude portant sur l’introduction de « l’agilité » dans la division informatique d’une multinationale. Nous examinons les conséquences et les tensions qu’engendre la tentative d’appliquer et de généraliser la méthode agile – une version indigène mettant l’accent sur le changement de culture professionnelle et l’automatisation – à l’ensemble des services informatiques. Ces tensions concernent en particulier : le management ; la transformation des différentes spécialités informatiques ; ainsi que la volonté de changer la culture. Puis nous montrons que ces tensions ne peuvent être surmontées que par les initiatives et l’engagement personnel d’informaticiens, ce qui interroge la pérennité de la méthode.

Open source, entreprise libérée et méthode agile : des principes communs pour une expérimentation permanente

5Dans cette section, nous identifions la proximité entre, d’une part, les principes de l’open source ainsi que ceux de l’entreprise libérée et, d’autre part, ceux des méthodes agiles.

L’open source : miser sur la collaboration auto-organisée des experts

6Revendiquant des sources d’inspiration disparates où se mêlent anticapitalisme, rejet des bureaucraties et croyance dans la vertu émancipatrice de la technique, le mouvement du logiciel libre (free software) promeut : a) la conception de logiciels ouverts – leur code source doit être compréhensible, utilisable et modifiable par tous ; b) et la diffusion gratuite de ces logiciels. Au milieu des années 1980, Richard Stallmann, alors chercheur au MIT, donne naissance à ce mouvement, en réaction à la privatisation et à la fermeture progressive des systèmes d’exploitation et des logiciels. « Le but de Stallmann était de produire un système d’exploitation libre, de façon à garantir à tous les citoyens-usagers le contrôle de leur outil de travail » (Crémer & Gaudeul, 2004). On peut retenir ici que, sous un discours éthico-politique, le mouvement du logiciel libre s’apparente à la défense d’un groupe professionnel : les utilisateurs – avant tout des experts informatiques – doivent garder collectivement le contrôle sur le fonctionnement, la réparation, l’amélioration de leurs productions qui sont aussi leurs instruments de travail. Dans ce sens, il n’existe pas – il ne devrait pas exister – de hiérarchie au sein du collectif réticulaire des informaticiens, volontaires et non sélectionnés, pas plus que ne devrait émerger de contrôle centralisé. Fondamentalement, il s’agit de conserver un pouvoir d’agir entre égaux, de ne pas être sous la domination d’une entreprise – ni de certains de ses employés – ni des actionnaires qui en financent le développement.

7Se distinguant progressivement du « libre », l’open source s'attache, quant à lui, aux avantages d'une méthode de développement au travers de la réutilisation du code source, indépendamment des questions idéologiques ou philosophiques (Raymond, 1998). N’étant plus « free » – gratuits –, les logiciels open source entrent dans une logique marchande. Les promoteurs de l’open source retiennent avant tout la possibilité de mobiliser une large « communauté » d’experts pour améliorer rapidement des composants logiciels dont le code est accessible. Sont mis en avant la dimension organisationnelle, le mode de développement et de diffusion, au détriment de l’éthique initiale. C’est essentiellement une méthode de rationalisation du travail intellectuel, non un mouvement de contestation du mode de production et de propriété.

8Toutefois, dans les faits, pour que des « communautés » d’utilisateurs et de développeurs parviennent à réaliser des logiciels open source, il ne leur suffit pas de partager – ou d’affirmer partager – des valeurs communes. Il est nécessaire, tout d’abord, qu’un cercle initial de militants compétents se constitue autour de valeurs de désintéressement et s’engage à réaliser un premier programme : le noyau d’instructions. Puis, sur la durée, de nombreux processus doivent être mis au point : a) pour opérer une sélection parmi les volontaires souhaitant participer activement au développement ; b) pour prendre en charge le fonctionnement du collectif (Auray, 2004) ; c) pour constituer les différents groupes de travail – eux-mêmes sinon hiérarchisés, du moins, diversement impliqués – définir les règles de coopération et structurer les échanges, tout en préservant l’identité fondatrice (Demazière et al., 2007). En d’autres termes, les contraintes opérationnelles du développement informatique rendent indispensable le travail d’organisation et de régulation de la « communauté », éloignant le collectif réel de son idéal.

9De son côté, le mouvement hacker, s’inspirant « de la contre-culture des années 60 et des mouvements autonomes » (Eychenne, 2012, p. 76), considère les formes d’organisation du travail, héritées de l’industrialisation, comme dépassées : le travail ne doit pas être prescrit ou imposé par une autorité quelconque, mais envisagé « sans séparation entre la conception et l'exécution, avec une coopération directe » (Giffard, 2007). Les hackers prônent donc le retour à une forme particulière d’autogestion (Lallement, 2015), grâce à laquelle les travailleurs retrouvent du sens dans leur activité professionnelle, notamment en maîtrisant toute la chaîne de production et pas seulement un élément parcellaire. Les hackerspaces constituent une réalisation concrète de ces ambitions : leurs fondateurs cherchent à supprimer toute emprise d’une autorité extérieure aux groupes de producteurs. Mais pour que leur projet perdure, ils sont confrontés à des contraintes semblables à celles que rencontrent les initiateurs de communautés de l’open source : il faut penser, organiser, structurer les individus qui fréquentent ces lieux. Et tout comme dans les communautés du libre, des animateurs-administrateurs sont nommés pour « susciter l’entraide mutuelle, stimuler des contributions, lancer des projets, organiser les échanges, structurer des discussions, réguler les interactions, voire trancher dans les désaccords » (Demazière et al., 2007).

L’entreprise libérée : la fin des hiérarchies ?

10Le second courant d’expérimentations qui se présente comme une nouvelle promesse d’alternative à l’organisation bureaucratisée est celui qualifié d’entreprise libérée (EL). Ce qui la caractérise c’est, initialement, une manière d’envisager le management, la direction d’entreprise, en « faisant confiance » aux salariés, en considérant que l’être humain est, par nature, travailleur et qu’en conséquence il faut « libérer » la collaboration entre producteurs, réduire les échelons hiérarchiques, leur substituer des « leaders naturels » et des « chefs d’équipes » élus. L’ouvrage de Tom Peters, paru en français en 1993 (Entreprise Libérée. Liberation Management), semble actuellement faire l’unanimité pour marquer le début de la diffusion de cette « philosophie » managériale. En France, c’est Isaac Getz qui en est l’un des plus actifs promoteurs, qualifiant l’EL d’« innovation radicale » (Getz, 2012).

11Comme le pointent Patrick Gilbert et ses collègues, ce courant gagne à être replacé dans la perspective plus large des projets et démarches qui, en s’inspirant notamment de l’approche sociotechnique, ont visé, à partir des années 1970, à favoriser la participation, plus ou moins contrôlée, des salariés dans l’entreprise (Gilbert et al., 2017). Groupes semi-autonomes, cercles de qualité, etc., ces démarches, encouragées en France sous l’effet des lois Auroux, ont donné lieu à des expérimentations dont plusieurs recherches ont souligné les limites (Linhart, 1994 ; Martin, 1995). D’une part, le management participatif s’avère souvent une tentative pour récupérer les modes de régulation autonomes de « la base ». D’autre part, même quand elles présentent un caractère réellement participatif, ces démarches entrent en tension avec les dispositifs de GRH individualisant, ce qui favorise le conformisme plus que l’innovation. Plus récemment, Anni Borzeix et ses collègues ont montré que la participation en entreprise pouvait donner lieu à des usages très contrastés : instrumentalisée en participation-accompagnement du changement organisationnel ; exercice d’une activité productive réellement collaborative ; ou pour chercher à donner du sens au travail (Borzeix et al., 2015).

12Quant aux applications empiriques des principes de l’EL, Patrick Gilbert et ses collègues identifient une tendance à dépasser certaines des limites du management participatif, tout en rencontrant des problèmes d’une autre nature : insuffisance des modes de régulation, pertes de repères, lassitude des plus impliqués, dépendance vis-à-vis de la figure du leader, etc. (Gilbert et al., 2017). D’autres chercheurs mettent en avant que la large prise de parole, vécue positivement au départ, évolue avec le temps vers plus de spécialisation et vers un retour à la structure (Picard, 2015). Ces études montrent également des formes d’exclusion – de l’isolement jusqu’au licenciement – ainsi que des formes de sur-engagement et de sur-adhésion. Elles pointent les tensions entre recherche d’égalité et absence d’autorité managériale. Enfin, l’éloignement des managers vis-à-vis du fonctionnement quotidien fait que ces derniers n’ont plus la connaissance des contraintes réelles du travail.

13Après avoir présenté succinctement certaines caractéristiques des mouvements de l’open source et de l’EL, venons-en à la présentation de la méthode agile.

La méthode agile : des principes communs avec les courants de l’open source et de l’entreprise libérée

15Parmi la dizaine de méthodes empiriques développées pour mettre en œuvre ces quatre valeurs, celle dite Scrum, introduite en 1996 par Ken Schwaber, est considérée par les cabinets de consultants comme l’une des plus abouties (Schwaber, 1996). Le terme scrum est emprunté au vocabulaire du rugby et signifie « mêlée » (Takeuchi & Nonaka, 1986). Il est employé comme métaphore de la rapidité et de la souplesse d’action qu’est supposé refléter le jeu au sein d’une équipe soudée. Deux grands principes la caractérisent. Tout d’abord, la volonté de fournir rapidement des applications, même imparfaites, mais tout de suite utilisables, étant entendu que l’accélération des cycles de production (sprints) devrait permettre de corriger très rapidement les éventuels manques ou dysfonctionnements constatés.

17À un niveau plus opérationnel, ces deux principes structurants se déclinent en une série de recommandations visant à dépasser les limites des méthodes « classiques » de conception de projets informatiques. Ces limites, par ailleurs bien connues (Alter, 1986 ; Pavé, 1989), sont caractérisées par :

18- une conception du temps linéaire et séquentiel, selon un découpage rigide en étapes – jalons – sans rétroaction ;

19- une division du travail d’autant plus poussée que le projet est important, avec l’intervention successive d’équipes spécialisées et cloisonnées ;

20- la définition des fonctionnalités détaillées effectuée le plus souvent sans prendre en compte les contraintes des équipes de développement ni celles de l’exploitation ;

21- la conception et la réalisation des différentes catégories de tests indépendamment les unes des autres, ce qui retarde la mise en service des applications ;

22- l’impossibilité de tirer les leçons des expériences, car lorsque l’on analyse les raisons de dysfonctionnements d’une version N, les fonctionnalités de la version N+1 et parfois N+2 sont déjà définies.

23Pour dépasser ces limites, l’application des principes de l’agilité vise (Barrand, 2012), avant tout, à promouvoir, parmi l’ensemble des informaticiens, une révolution culturelle caractérisée par :

24- une conception du temps itératif – une version de base minimale est vite déployée, les corrections et compléments éventuels pouvant rapidement être apportés ultérieurement ;

25- des équipes pluridisciplinaires – concepteurs, développeurs, testeurs, etc. – et autogérées – un responsable d’équipe facilitant les prises de décisions collectives – d’une dizaine de personnes, de préférence localisées dans un même lieu, voire un même bureau ;

26- et la définition des fonctionnalités limitées et rapidement prototypées, conséquence du premier point. L’idée est d’offrir, au plus vite, un minimum de possibilités, que l’on pourra toujours enrichir si les utilisateurs-clients en manifestent le souhait.

Les points communs aux principes des trois courants

27Au niveau des ambitions générales, les trois courants ont en commun de vouloir changer les mentalités, agir au niveau des valeurs, modifier les représentations. De plus, ces évolutions souhaitées sont très proches, puisque les trois courants, s’inscrivant en cela dans une tendance plus générale des dispositifs de gestion (Craipeau & Metzger, 2007 ; Benedetto-Meyer & Metzger, 2008 ; Boussard, 2008 ; Maugeri & Metzger, 2014), promeuvent l’autonomie des producteurs et encouragent leur responsabilisation individuelle, chacun est appelé à devenir entrepreneur de soi pour atteindre les objectifs. Les fonctions hiérarchiques ne disparaissent pas totalement, mais dorénavant les producteurs sont encouragés à être leur propre chef et à coopter leur manager de proximité (EL) ou leur scrum master (Agile). Dans la méthode agile comme dans le courant de l’open source, domine le principe de livrer des composants logiciels perfectibles grâce aux interventions spontanées des membres de la communauté.

28De plus, pour que les expérimentations perdurent, un noyau d’animateurs-organisateurs s’avère déterminant. Dans l’open source, il s’agit du noyau d’experts les plus réputés et les plus engagés ; dans le cas de l’EL, ce rôle est exercé par un « leader charismatique » – un dirigeant ayant décidé de débureaucratiser – qui fixe la stratégie de l’entreprise et « libère les salariés » (Getz, 2012). Comme dans le mouvement hacker, le fonctionnement des EL et celui de la méthode agile reposent sur une activité de production idéologique, exercée soit par des conférenciers présentés comme « libertaires », soit par des salariés-pionniers convaincus de l’intérêt de convertir leurs collègues. Il faut également tenir compte du principe d’ouverture ou d’agora, selon lequel les cloisons de l’entreprise libérée sont ouvertes, conformément à une logique panoptique, tout comme la méthode agile préconise de regrouper dans un seul lieu l’ensemble des équipes concernées par un projet. Ainsi, le principe de la motivation dans le travail, par adhésion à des valeurs, constitue un moteur commun aux trois courants.

29Cette proximité entre les principes de justification des trois courants nous permet, tout d’abord, d’expliquer pourquoi une fraction des dirigeants d’entreprises peuvent être tentés d’appliquer, dans leur organisation, la philosophie de la méthode agile : convaincus d’avoir à lutter dans un environnement économique caractérisé par « l’accélération de l’innovation », les décideurs trouvent dans les promesses de flexibilité et de transparence un ensemble de propositions originales, qu’ils sont d’autant plus amenés à expérimenter qu’elles s’accompagnent d’une promesse de réduction des coûts salariaux, ne serait-ce que par la réduction du nombre de cadres. De leur côté, une partie des experts informatiques trouvent dans les principes de l’agilité des modalités d’auto-organisation qui peuvent s’apparenter à une reprise en main, par le groupe professionnel, de la production.

30On peut alors se demander si la mise en œuvre de la méthode agile révèlera des contradictions et engendrera des difficultés de même type que celles rencontrées par les courants de l’open source et de l’EL.

La méthode agile appliquée au département informatique d’une multinationale

Précisions concernant le recueil de matériaux

31Pour répondre, nous analysons la mise en œuvre de la méthode Scrum au sein de la division informatique d’une multinationale appartenant au secteur des technologies de l’information et de la communication.

32Chercheurs au sein de la division R&D de cette multinationale – et non de la division Informatique – nous n’avions pas à « accompagner » le déploiement de la méthode agile. Nous avons négocié avec les responsables des projets agiles et les avons convaincus de l’intérêt de comprendre, de façon distanciée, les conséquences de l’application locale de la méthode sur les différents métiers concernés.

33Pour mener à bien cette recherche, nous avons observé, pendant toute sa durée, l’une des séances de formation à la méthode agile, dispensée en interne aux informaticiens de cette entreprise (trois jours en présentiel). Inscrits à cette formation, présents dans la salle de cours, nous avons pratiqué l’observation non-participante, en nous attachant plus particulièrement à noter les attitudes et les discours des formateurs, ainsi que les réactions et les questions des apprenants. Ces observations nous ont permis d’identifier les points de vue respectifs des différentes catégories de professionnels, ainsi que les problèmes que représentaient pour eux la perspective de mettre en œuvre la méthode agile.

34Nous avons complété ce premier recueil de matériaux d’une part par la lecture de documents internes (discours des dirigeants, transparents de présentation, supports de cours, guides méthodologiques) et d’autre part par des entretiens approfondis d’une durée d’une heure environ, conduits en face-à-face auprès de douze informaticiens (architectes, concepteurs, développeurs, testeurs) ayant suivi la formation. Nous avons également interrogé trois chefs de projets chargés de mettre en œuvre la méthode. Nous nous sommes enfin entretenus avec cinq des pionniers, ces informaticiens (concepteurs, chefs de projets, développeurs) ayant pris des initiatives pour se rapprocher des objectifs de « l’agilité ». Au total, une vingtaine d’experts ont ainsi été rencontrés sur soixante-huit formés à ce moment-là.

36Enfin, pour traiter et recouper les données ainsi recueillies, nous avons procédé à une analyse par mots clés et à une analyse de contenus, structurée autour des grands axes de problématique. Nous avons effectué ces analyses par traitement manuel, sans utiliser de méthode lexicométrique.

La méthode agile indigène

37Cette entreprise a connu de nombreuses transformations, parmi lesquelles la fusion des divisions informatique, marketing et R&D, suivie de la séparation, puis du rapprochement entre la production de logiciels et le développement des infrastructures. Ces réorganisations successives, accompagnées de l’introduction de nouvelles manières de travailler et de gérer les ressources humaines, visent la baisse des coûts de production des applications et la réduction des temps de cycle. C’est dans ce cadre qu’il faut comprendre l’intérêt récent d’une partie du top management pour l’introduction de la méthode agile. Cet intérêt est manifeste dans les discours et les interviews des dirigeants de la multinationale.

38Pendant les trois années qui ont précédé notre enquête, plusieurs chefs de projets, concepteurs et développeurs, travaillant dans différentes entités du groupe et sur des applications distinctes, avaient déjà pris des initiatives pour introduire localement certaines composantes de la méthode agile Scrum. Nous les appellerons les « pionniers » de l’agilité. Au moment où débute notre étude, la direction souhaite étendre et harmoniser la mise en œuvre de la méthode. Une version indigène de la méthode Scrum est ainsi codifiée, ses caractéristiques distinctives concernent :

39- l’impératif d’utiliser un logiciel d’automatisation des tests. Les responsables manifestent ainsi leur volonté de transformer le travail de toutes les catégories d’informaticiens et pas seulement les testeurs. En effet, la mise en œuvre de ces outils implique, de proche en proche, de rendre automatisables tous les composants logiciels des applications « agiles » ;

40- une analyse en continu des données d’usages – les « retours d’exploitation » – au service de la conception. L’idée est de concevoir des applications dotées de leur propre programme d’enregistrement et de suivi des traces d’usages (fonctionnalités utilisées par catégories d’utilisateurs-clients, durée, etc.). Ces données sont supposées pouvoir être analysées et interprétées, dès leur mise à disposition, par les experts du marketing, pour qu’ils améliorent ou abandonnent certaines fonctionnalités ;

41- enfin, pour symboliser l’impression de « rupture », l’emploi d’un vocabulaire spécialisé, mais non stabilisé : certains de nos interlocuteurs utilisent le terme d’agilité pour désigner l’ensemble de la méthode, d’autres en cantonnent l’usage à une partie seulement du processus de production.

42Ainsi, la volonté de généraliser progressivement une nouvelle manière de produire les logiciels reflète certains éléments présents dans les principes de l’open source (auto-organisation en petites équipes) et de l’EL (cooptation des chefs d’équipes). Toutefois, en imposant l’automatisation d’une partie des tâches, la version indigène limite la portée de l’autonomie et conditionne le contenu même des différentes spécialités informatiques.

« On est vraiment dans une méthode où chacun a une expertise, mais où tout le monde peut tout faire. L’idée c’est que l’équipe, elle s’entraide, elle résout des problèmes […] Tous les matins, on fait la liste de ce qu’on a à faire et tout le monde y contribue. Ce ne sont pas des tâches réservées pour untel ou untel […], il y a vraiment la volonté de faire évoluer la culture des équipes, jusqu’ici hyper segmentées, plus que de faire évoluer les compétences » (Responsable de projet).

43Comme le montre cet extrait d’entretien, les tenants de la méthode indigène emploient des techniques bien rodées, comme la mise en open space des équipes et les réunions quotidiennes pour établir collectivement le plan de travail de la journée (daily scrum meeting). Derrière un discours mettant l’accent sur l’autonomie et la responsabilisation, se profile de fait une pression – relayée par les équipes – à s’impliquer individuellement pour transcender les limites de l’hyperspécialisation.

Des réalités organisationnelles et matérielles qui limitent l’application de la méthode

44Notre enquête montre que très peu de projets informatiques sont développés intégralement (« full agile ») ou partiellement (« pseudo-agile ») selon les principes et avec les outils de la méthode préconisée. C’est qu’en effet plusieurs types d’obstacles se dressent entre l’intention réformatrice et le système d’information réel, dans ses dimensions organisationnelles et technologiques.

45Ainsi, la proximité géographique entre les différents spécialistes (concepteurs, développeurs, etc.) peut certes favoriser la constitution « d’équipes pluridisciplinaires », réunies en un même lieu et prêtes à s’engager dans la mise en œuvre de la méthode. Ou bien encore, l’adhésion de certains informaticiens à l’esprit de l’open source en fait des promoteurs enthousiastes de la méthode, parfois sans avoir une idée exacte de sa version indigène : une partie des architectes réseaux et des chefs de projet de la multinationale ont en effet été des militants de l’open source et/ou continuent à être actifs au sein de ce courant. Il en résulte, indépendamment des incitations de la direction, des tentatives localisées d’introduire une sorte de méthode agile « bricolée », mixte du modèle indigène et des grands principes de l’open source.

« Au départ, je n’étais pas formée au mode agile, ça s’est fait sur le tas. En fait, c’est lors de la formation que je me suis rendue compte que l’on ne pratiquait pas un vrai mode agile… C’est-à-dire que les développeurs planifiaient dans leurs livraisons certaines choses, ils nous les livraient et nous, on les validait a posteriori. […] En fait, pour moi, c’est comme s’il y avait un planning de développement en mode agile et un planning de validation en décalage avec ce planning » (Responsable intégration validation).

46En effet, pour que la méthode indigène soit mise en œuvre, d’autres conditions organisationnelles doivent être remplies. D’une part, tous les membres de l’équipe doivent avoir été formés et être convaincus, voire convertis. Et d’autre part, des coachs affectés à temps plein sur les projets « agiles » s’avèrent souvent nécessaires pour accompagner cette transformation. Mais l’allocation de ces coachs requiert l’approbation de leurs différents managers.

• 4 La fonction de coach agile a été introduite par les promoteurs de la méthode indigène. Ces salariés (...)

« Je suis convaincu que si nos managers n’impulsent pas les choses, on ne sert à rien. C’est-à-dire qu’on va avoir des beaux succès ou des petites victoires sur un, deux, trois projets, avec des gens qui vont prendre le virus (entre guillemets) et qui vont vouloir y aller. Mais si l’organisation reste sur des principes orthogonaux à ce qu’on met en place, dès que le coach ne peut pas être là, les vieilles habitudes vont reprendre… » (Coach Pôle Agile 4).

47En d’autres termes, comme le déclare avec franchise notre interlocuteur, lui-même très engagé dans la diffusion de la « culture » agile, il n’y a rien de naturel à ce que les informaticiens, à titre individuel, s’impliquent dans l’effort que nécessite l’apprentissage d’une nouvelle façon de faire. De plus, la mise en œuvre de la méthode entre forcément en tension avec les structures et les modes d’organisation actuels. Le soutien de toute la ligne managériale est alors convoqué pour étayer la « révolution agile », en particulier en défendant des indicateurs de réussite permettant d’arbitrer favorablement entre : respect des délais de livraison des lots et allocation de temps pour monter en compétence sur la nouvelle méthode. On ne peut alors que pointer la contradiction entre l’esprit de la méthode – prônant l’auto-organisation, l’absence de hiérarchie, la transmutation du rôle de manager en ambassadeur – et la nécessité de s’appuyer sur l’encadrement pour qu’il contribue à sa propre déstabilisation.

48S’ajoutent des difficultés de mise en œuvre, liées à la composition même des équipes informatiques. En effet, celles-ci sont supposées pouvoir être polyvalentes. Or, dans les faits, les choix opérés, notamment pour les « gros » projets informatiques, ont toujours privilégié le recours à une pluralité de sous-traitants pour les différentes parties du processus de développement. Il est alors difficile de réunir en un même lieu, au sein d’une ou plusieurs équipes autonomes, des salariés appartenant au donneur d’ordres (la multinationale) et aux différentes entreprises sous-traitantes (SSII). Il est surtout délicat de les faire travailler en toute transparence, quand certains aspects de la conception ou du développement sont confidentiels. En général, le donneur d’ordres conçoit les fonctionnalités, sous-traite les différents lots de développement et se garde les tests d’intégration. Or, pour ces versions « intégrées », les membres de l’équipe de tests ne peuvent, comme le préconise la méthode, intervenir directement sur le « code » des différents lots (développés par des équipes différentes de plusieurs SSII). Pour envisager l’automatisation intégrale des tests, il faudrait, par exemple, repenser l’ensemble de la division interne (multinationale) et externe (SSII) du travail, trouver des lieux adaptés pour réunir des salariés d’entreprises distinctes, s’assurer d’un minimum d’homogénéité entre leurs compétences et d’adhésion aux principes de la méthode. Ces exigences, on le voit, impliqueraient une forte implication de la ligne managériale.

49D’autres difficultés proviennent de la structure même des réseaux informatiques, entre filiales et à l’échelle internationale. En effet, idéalement, la méthode agile suppose que les équipes informatiques puissent prendre en compte, dès le développement, les considérations liées aux contraintes matérielles de l’exploitation. Une telle exigence est d’autant plus facile à respecter que l’application est indépendante des spécificités des réseaux existants : c’est, notamment, le cas des applications « web ». A contrario, il est beaucoup plus difficile, pour des raisons de coûts et de compatibilité des infrastructures, d’appliquer la méthode agile aux autres logiciels. Ces derniers, en effet, ont été conçus de manière à être interfacés avec les nombreux composants du système d’information de la multinationale, ces interfaces étant elles-mêmes spécifiques aux machines des différents réseaux nationaux.

« Pour faire du full agile, il faudrait que les exploitants soient capables d’anticiper pour dire : "il va falloir tant de machines, et puis tant d’électricité, tant de climatisation, etc.". Et donc, il y a clairement des questions techniques qui se posent, de proche en proche, des questions qui provoquent des blocages. Par exemple, même quand on sait fournir des machines automatiquement, on ne sait pas ouvrir des flux réseaux automatiquement et, du coup, on a des machines, mais elles ne peuvent pas se parler, on ne peut pas y accéder et on ne peut rien en faire » (Responsable développement-tests).

50Ainsi, l’hétérogénéité technologique, elle-même le reflet de la diversité des situations des filiales étrangères et l’héritage de choix économiques antérieurs, réduit l’application de la méthode agile indigène à une partie de la production informatique. Il est donc très difficile de déployer la même version d’une application au même moment dans toutes les parties du réseau international. Il est bien sûr théoriquement imaginable d’envisager une homogénéisation des infrastructures, mais cela nécessiterait de convaincre l’ensemble des responsables des différentes zones géographiques, alors que chacun d’entre eux possède ses propres contraintes logistiques et financières. De plus, un tel scénario implique de conduire des négociations complexes entre les experts en sécurité informatique des différentes entités du Groupe, ayant chacun des visions et des enjeux différents.

Tensions liées aux métiers et au management

51Si l’on s’intéresse maintenant aux projets qui mettent en œuvre tout ou partie de la méthode, on constate un certain nombre d’évolutions, encore limitées, mais qui, si elles étaient poursuivies, remettraient en cause les spécificités des différents métiers de l’informatique. On se souvient de l’impératif méthodologique assigné aux équipes « agiles » d’être plus polyvalentes et auto-organisées. Cette polyvalence sous contrainte de coopération ne va pas de soi. Elle requiert l’acquisition de savoirs, savoir-faire et compétences relationnelles, en tension avec celles jusqu’ici mobilisées dans une organisation où la division du travail est très poussée. Comme nous le commentait avec lucidité ce responsable :

« Quand on est dans un projet intégré d’une dizaine de personnes, des rôles qui étaient très segmentés comme celui de l’architecte ou du testeur vont être un peu bousculés. Parce que ce qu’on leur demande, c’est finalement de partager avec tous les autres ce qu’ils savent, pour que tout le monde puisse faire un peu tout » (Responsable projet appliquant la méthode agile).

52Cette mise en visibilité attendue de son activité, de ses productions intermédiaires, voire de ses trucs et astuces, ne peut s’envisager qu’à condition d’être certain d’obtenir la même transparence de la part de ses pairs – les autres membres de l’équipe – et d’être convaincu qu’il ne sera pas fait un usage détourné de ce que l’on met en partage. Or, comment garantir cet arrière-fond de confiance quand l’entreprise recourt toujours à des dispositifs de gestion individualisés et que les perspectives d’évolution professionnelles en dépendent ?

53Par ailleurs, comme l’ont indiqué plusieurs de nos interlocuteurs, l’accès à la polyvalence informatique présuppose certaines dispositions, plus communes chez les développeurs open source – habitués à rechercher d’eux-mêmes des informations dans toutes les bases de données, tutoriels, etc. – que chez les testeurs de la multinationale, jusqu’ici encouragés à demeurer dans l’exécution de protocoles. La mise en œuvre de la méthode agile présente un risque d’exclusion progressive d’une partie des informaticiens : la mise à disposition ponctuelle d’un « coach » constitue certes une « ressource », mais l’expérience montre qu’elle doit être complétée par de nombreuses initiatives locales (voir dernière section).

54Ajoutons que, dans le cas de la méthode indigène, l’impératif de polyvalence entre en tension avec l’obligation d’utiliser le logiciel d’automatisation des tâches. En effet, l’automatisation des tests conduit à standardiser la plupart des tâches ce qui, de fait, réduit la polyvalence à une déqualification. En réalité, les testeurs « agiles » doivent non seulement apprendre à se servir de l’outil d’automatisation des tests, mais aussi acquérir l’appétence nécessaire pour rechercher sur le web (forums, groupes de discussion, tutoriels, etc.) des réponses aux questions que la mise en œuvre de cet outil pose :

« Pour que ça marche bien, il faut que tout le monde soit en capacité de tester tout, qu’on puisse vérifier à chaque étape. Plus on écrit du code pour faire des choses automatiques, plus il y a d’erreurs. C’est une constante de l’informatique : à chaque fois que l’on introduit des dispositifs pour automatiser, il y a des erreurs. Alors, on écrit des programmes pour détecter les erreurs – des sortes de meta-tests – mais on fait aussi des erreurs dans le code de détection des erreurs, etc. » (Responsable développement-tests).

55Sans incitation financière et sans l’octroi de temps d’apprentissage suffisants, une telle nécessité entre en tension avec les dispositions et les impératifs productifs d’une partie des intéressés. De plus, si les testeurs sont les plus directement concernés par la mise en œuvre de la méthode agile, le rôle et la place des architectes informatiques vont également être mis en cause :

« Autrefois, on attendait de l’architecte qu’il ponde un document. Et tant qu’il ne l’avait pas fait, quelque part, il ne se passait rien. Dorénavant, là, avec l’agilité, on se met dans un tout autre modèle, où il va falloir affiner les choses au fur et à mesure, et où il faut tout de suite partager avec les autres une première ébauche » (Responsable projet).

56La volonté d’aplanir les hiérarchies entre spécialistes se manifeste ainsi par une double perte de contrôle pour les architectes : l’organisation temporelle des cycles productifs et la définition de l’architecture informatique leur échappent partiellement.

58Par ailleurs, l’activité des exploitants devra également être repensée, puisqu’ils devraient être capables d’anticiper, dès la phase de conception, sur les contraintes d’exploitation à prendre en compte :

« Avec la méthode agile, l’exploitant devra expliquer ce qui, d’après lui, va être sensible dans le service à venir, et de quoi il aura besoin pour être sûr que ce service fonctionnera bien, qu’il pourra faire face aux différents imprévus, etc. On va donc solliciter l’exploitant, à l’avance, avant même d’avoir le service, on va lui demander d’essayer d’identifier ce qui est important pour pouvoir exploiter quelque chose qui n’existe pas encore » (Responsable projet).

59Enfin, comme nous l’avons précédemment souligné, la mise en œuvre de la méthode agile engendre la nécessité de remettre en cause ou au moins de réaménager le rôle des managers et des chefs de projet. Ils sont supposés devenir les accompagnateurs des équipes, notamment en aidant à résoudre les difficultés que ces dernières rencontrent vis-à-vis des autres composantes du système d’information. On pourrait parler d’un rôle d’ambassadeur, missionné par l’équipe pour négocier en son nom des concessions mutuelles avec ses pairs, les autres managers transmutés en ambassadeurs. Si certains managers peuvent voir dans cette reconversion prescrite une opportunité, d’autres s’y reconnaissent d’autant moins qu’ils ne possèdent ni les prédispositions ni les compétences pour exercer ce nouveau rôle.

Dépasser les contradictions en… les déplaçant

60La mise en œuvre de la méthode indigène soulève de nombreuses difficultés pratiques. Pour tenter de résoudre certaines de ces contradictions, plusieurs initiatives ont été prises par des informaticiens, parmi lesquelles le dispositif « pôle agile » nous parait emblématique.

61Créé à l’initiative de plusieurs coachs de la méthode, il s’est construit progressivement par le « bouche-à-oreille ». Bénéficiant dorénavant d’une reconnaissance formelle de la part de la direction – cette activité entre dans leur charge de travail, elle est « budgétisée » à hauteur de 25 % de leur temps – formant un petit groupe de six volontaires (développeurs, chefs d’équipes agiles, etc.) « hors hiérarchie, agissant de façon collégiale et sans process » (Coach Pôle agile), ils partagent ponctuellement leur expérience auprès de ceux qui débutent dans la mise en œuvre de « l’agilité ». Se déplaçant à la demande de l’équipe projet, ils en rencontrent les membres, sans intervenir sur le contenu applicatif. Les animateurs du « pôle agile » constituent ainsi un des maillons complémentaires pour rendre opérationnelle la volonté de changer la culture, en expérimentant des modes d’organisation alternatifs, au sein même de la multinationale.

62On notera que cette initiative est parfaitement conforme avec les discours encourageant l’auto-organisation : le pôle – auto-organisé – vise à améliorer la coopération au sein des équipes « pluridisciplinaires », sans intervenir sur le produit ou le projet – laisser s’auto-organiser les équipes. S’ils interviennent, c’est pour aider les équipes à dépasser les contradictions inhérentes à la méthode, en les aidant à identifier les éventuelles fonctions manquantes au sein des équipes et en les guidant en matière d’animation. Ces interventions consistent, par exemple, à mettre en place une séance de créativité, une rétrospective, à organiser des moments d’échanges entre projets agiles, moments appelés « foires agiles ».

« En partant du constat que chaque pratiquant Scrum Master ou autre est un peu isolé, l’idée était d’enrichir des échanges en proposant des moyens de rencontre ou de partage, de retour d’expérience sur le sujet… typiquement, un webinaire, sur un retour expérience, peut rentrer dans ce cadre-là » (Coach Pôle agile).

63Ils sont conscients de leur véritable apport : « les trois quarts du temps, les gens n’ont pas besoin d’un coach en tant que tel, mais plutôt d’un prétexte pour prendre un moment de recul. Collectif, j’entends » (Coach Pôle Agile).

64Victimes de leur succès, ils cherchent dorénavant à recruter d’autres « coachs », de façon informelle, au gré des rencontres et des opportunités et évoquent la possibilité de structurer progressivement leur fonctionnement (formation au rôle de coach, réunions régulières, etc.).

65Ainsi, leur invention organisationnelle leur demande du temps et des efforts de plus en plus incompatibles avec la poursuite de leurs propres projets informatiques. Devenus experts en méthode indigène, ils s’avèrent dépendants du succès de sa généralisation. Or, l’extension de l’agilité à l’ensemble de l’organisation est, comme nous l’avons vu, impossible pour des raisons d’infrastructure technique (hétérogénéité des équipements) et de stratégie économique (sous-traitance). Il est alors probable que les plus engagés dans la conversion à la méthode s’épuisent dans cet effort et connaissent à leur tour des déconvenues. D’autant que la mise en œuvre de la méthode indigène, devenue un immense projet à part entière, place les responsables devant un dilemme : privilégier l’affectation des ressources à la réalisation des projets informatiques ou à la conversion à l’agilité ?

Conclusion

66Notre étude identifie donc trois niveaux de difficultés que rencontrent, au sein d’une multinationale, les promoteurs de la méthode agile voulant l’étendre à l’ensemble des services informatiques.

67Premièrement, il est d’autant plus difficile d’appliquer la méthode que les activités concernées comportent une part déterminante de composants matériels, logistiques, avec leurs contraintes d’interopérabilité, de sécurité, de maintenance, etc. Dit autrement, les promoteurs de l’agilité dans les départements informatiques internes, en voulant d’abord changer la culture des professionnels, semblent oublier que de tels changements sont longs, progressifs et incertains : ils ne peuvent être que consécutifs à des évolutions préalables des façons de faire, lesquelles sont articulées, en particulier, à la maîtrise des environnements matériels et organisationnels de la pratique (Sainsaulieu, 1985 ; Dubar, 1991 ; Alter, 1993).

68Deuxièmement, les promoteurs de la méthode justifient son déploiement par les gains de temps attendus dans la fourniture de logiciels plus conformes aux attentes des utilisateurs. L’expérience montre toutefois que les contraintes structurelles – l’imbrication de réseaux informatiques dont l’harmonisation nécessiterait des investissements importants, ainsi que l’exigence d’un accord entre toutes les parties prenantes – engendrent des difficultés importantes, ce qui, finalement, entre en tension avec la volonté de réduire le temps de production.

69Enfin, pour résoudre les difficultés de toutes sortes impliquées par l’application locale de la méthode, l’appui du management intermédiaire est indispensable. Or, précisément, l’un des principes de la méthode consiste à supprimer ces échelons hiérarchiques en convertissant les managers en ambassadeurs. Ce type d’injonctions paradoxales apparaît alors comme l’une des occurrences organisationnelles de ce que Vincent de Gaulejac et Fabienne Hanique appellent la « société paradoxante », où l’individu est pris au piège d’un inextricable réseau d’exigences incompatibles, caractéristiques d’une société où « le paradoxe devient la norme » (de Gaulejac & Hanique, 2015, p. 14).

70Par ailleurs, cette étude permet de circonscrire l’autonomie réelle dont peuvent disposer les informaticiens en milieu fortement contraint. En effet, dans ses principes, la méthode agile entend redonner des capacités d’agir et d’initiative aux différentes catégories d’informaticiens. Or, l’application de ces principes varie selon le niveau organisationnel. D’une part, au sein des grandes entreprises, le fait de travailler dans des équipes de petite taille – moins de dix personnes – comme le préconise la méthode, permet de redonner du sens au travail ; les informaticiens, devenant progressivement plus polyvalents, peuvent avoir l’impression de (re)prendre la main sur le produit de leur activité. Mais à un deuxième niveau, l’articulation entre les différents logiciels, l’interfaçage entre les différents systèmes d’information d’une multinationale, l’imbrication entre les différents niveaux décisionnels font que la mise en œuvre de la méthode agile se heurte à des contraintes extrêmement coûteuses à traiter et requiert de très nombreuses coordinations. Ces contraintes limitent drastiquement les marges de manœuvre des informaticiens « de base » et remettent en cause leur latitude de choix. Cette tension entre l’autonomie relative au sein de petites équipes et l’autonomie illusoire à plus grande échelle, peut engendrer frustration et découragement, réduisant alors les prises d’initiatives.

71Sur un plan plus théorique, ces constats confirment la proximité, identifiée dans la première section, entre la méthode agile, l’entreprise libérée et l’open source. Et ce, qu’il s’agisse : a) de leurs principes – volonté de changer la culture et de promouvoir l’autonomisation, réduction des fonctions de management ; b) ou qu’il s’agisse des difficultés rencontrées lors de leur mise en œuvre – tension avec les modes de GRH existant, risque d’instrumentalisation de l’engagement des salariés, tendance à renforcer le recours aux règles de gestion, épuisement/découragement des plus impliqués, etc. On peut alors en inférer que, sans précautions particulières, l’expérimentation des principes communs à ces trois méthodes alternatives risque d’engendrer des situations paradoxantes, sources de nouveaux dysfonctionnements. En effet, vouloir changer la culture et donner de la liberté d’agir aux acteurs ne peut que se heurter aux contraintes structurelles – technologiques, gestionnaires et financières – dès lors que celles-ci ne sont pas préalablement repensées et que rien n’est entrepris pour corriger l’inégale distribution des capacités à être autonome. L’accroissement de ces capacités passe, par exemple, pour les acteurs, par l’identification des marges d’autonomie réelles dont ils disposent, pour éviter désillusions et démotivation.

72Se dessinent alors des prolongements à cette étude. Il serait intéressant, tout d’abord, de connaître le devenir de la méthode quelques années après notre investigation : les constats établis dans les premiers temps d’introduction de l’agilité sont-ils confirmés, des solutions ont-elles été trouvées pour résoudre les tensions identifiées, la méthode est-elle en voie de généralisation ? Par ailleurs, il serait nécessaire de vérifier la pertinence de ces résultats sur un plus grand nombre d’entreprises et de métiers ayant mis en œuvre la méthode agile : autres entreprises de grande taille, mais aussi PME, appartenant à plusieurs domaines d’activités. De telles entreprises ont-elles rencontré des difficultés de même ordre, comment les ont-elles éventuellement résolues, dans quels départements internes ont-elles introduit la méthode agile ?

73De telles interrogations, si elles ne concernent apparemment que des configurations marginales, nous semblent relever d’une préoccupation bien plus générale et qui consiste, comme le formule Thomas Coutrot, à identifier le (ou les) type(s) de gouvernance d’entreprise susceptible(s) : de favoriser effectivement l’autonomisation des salariés, de prendre en compte les solutions innovantes qu’ils initient, sans pour autant accentuer la gestionnarisation de leurs pratiques, ni accroître la codification de leurs rôles (Coutrot, 2018).