{"word_count": 3720, "character_count": 23504}
Vous arrivez au bureau, vous prenez votre café et des nouvelles des collègues, vous allumez votre ordinateur. Différentes applications s’ouvrent, seules ou avec votre aide. L’une de ces applications ou un bouquet d’entre elles vont vous accompagner toute la journée jusqu’au soir. Certaines vont vous exaspérer, d’autres vous faciliter la vie. Difficile toutefois de s’imaginer la somme de travail que ces logiciels ont nécessité. Ne voyant que le produit fini, et sa plus ou moins grande compatibilité avec ce que vous avez à faire, il est encore plus difficile de mesurer l’ensemble des choix politiques qui ont été faits pour cadrer votre activité. Alors, ouvrons le capot.  Cette note de blog s’appuie sur 12 ans d’enquête sur l’informatisation du travail dans les grandes bureaucraties publiques et privées, Pôle emploi principalement, mais également l’inspection vétérinaire et le travail temporaire ont été étudié directement tandis que différents travaux d’étudiant.e.s apprenti.e.s ont permis d’apprendre à connaître un nombre plus important de secteurs.  Premier Choix : Au commencement était la commandeNumérisé, dématérialisé, en ligne, virtuel ou encore à distance, les formes actuelles du travail de bureau et les outils manipulés pour l’effectuer peuvent donner le sentiment d’une évaporation des lieux et des temps. Remonter à la source de l’application permet de comprendre les décisions qui ont été prises pour vous.Il faut au début de l’histoire qu’un individu ou un groupe d’individu s’imagine que quelque chose manque dans votre boite à outils informatiques. Comment ce sentiment leur est-il venu ? Les arguments les plus classiques sont la modernité et l’efficacité. Mais de tels motifs pourraient être invoqués à n’importe quel moment. C’est la raison pour laquelle ce qui déclenche la création d’un nouveau logiciel est bien souvent un changement de cap au sein des directions, un changement de l’environnement ou de la concurrence. Lorsqu’une assurance décide par exemple de dématérialiser la gestion des sinistres avec ses clients, elle doit repenser les logiciels mis à la disposition des agents qui traitent ses dossiers clients.   &#160;&#160;Une fois cette idée en tête il faut l’expliciter, l’exposer, la formaliser. Ce n’est pas facile de savoir où aller car développer suppose de connaître finement le métier et de fait la personne qui propose de changer de logiciel est rarement la personne amenée à l’utiliser le plus fréquemment. De plus on ne sait pas toujours de quoi demain sera fait. Faut-il mieux équiper le travail actuel, la façon dont le travail est réalisé aujourd’hui, ou en profiter pour changer le travail afin de l’adapter aux évolutions à venir ? On constate par exemple aujourd’hui un développement des procédures de protection des données personnelles. On dit également que le télétravail est amené à se développer. Mais comment prévoir dès aujourd’hui, dans les métiers de la banque notamment, à quel point sera toléré demain le fait de gérer des fichiers clients sur un ordinateur familial ?La question devient vertigineuse à mesure que le nombre de personnes convaincues qu’il faut changer de logiciel augmente. Les vues sur ce qu’il faudrait pouvoir faire avec le nouvel outil deviennent de plus en plus nombreuses, jusqu’à créer des tensions entre diverses fonctionnalités contradictoires. L’avenir du travail dépend fréquemment des luttes entre différents acteurs de pouvoir dont les vues divergent sur l’avenir. Dans une organisation, différentes options s’opposent entre les financiers, les comptables, les RH, les managers, les techniciens. Il faut alors qu’une autorité arbitre, fasse des déçus. On peut le voir dans l’intérim, par exemple, où les outils de gestion de la performance favorisent les fonctionnalités commerciales, au détriment des options relatives à la sécurité des intérimaires. Tout le monde ne peut pas être servi pour une raison simple : chaque fonctionnalité supplémentaire, en informatique, suppose des jours*hommes supplémentaires, l’unité de mesure du coût d’un développement. Pour un budget donné, les responsables du développement « priorisent » ou « convergent », termes qui signifient en fait : on privilégie une définition du travail sur une autre qui se trouve subordonnée. Et l’arbitrage n’est pas technique, ce sont bien les priorités de la direction qui se trouvent favorisées. La seule option qui s’impose donc à chacun est de chercher à faire prévaloir ses vues auprès des homologues ou des arbitres.Mais les membres de l’organisation ne demeurent pas en vase clos dans ce jeu de concurrence. Des nouveaux joueurs sont invités à participer, les conseillers et les conseillères des Sociétés de services en ingénierie informatiques (SSII) et autres cabinets de consulting, qui peuvent eux aussi orienter la commande. En effet, il existe nombre d’organisations qui recourent aujourd’hui à des prestations informatiques pour s’équiper, savoir ce qui se fait de mieux et ce que l’on pourrait faire pour elle. Toutes les organisations ne disposent pas toujours de l’expertise technique pour relativiser ou mettre en perspective ce que leur annonce les prestataires. Le ministère du Travail a par exemple retenu, il y a 10 ans, pour développer le système d’information des Missions locales (Associations locales en charge de l’insertion des jeunes gens sur le marché du travail et financées à ce titre par l’Etat), un prestataire spécialisé dans la comptabilité et sans expérience dans le monde de l’emploi ou de la formation professionnelle. Celui-ci a proposé une application tout à fait cohérente avec les attentes du ministère du Travail en matière de reporting et de suivi financier des missions locales mais sans prise en compte des caractéristiques du métier d’accompagnement des jeunes. Un tel décalage est toutefois assez rare, les consultants visant d’abord la reconduction de leur contrat et donc une relative satisfaction du donneur d’ordre et de ses équipes.Une fois le principe d’un nouvel outil arrêté, on voit alors naître un jeu à trois : la maîtrise d’ouvrage tout d’abord qui donne au logiciel sa silhouette en utilisant des mots pour le décrire. La maîtrise d’œuvre ensuite qui traduit ces mots en fonctionnalités techniques, elles-mêmes traduites en un coût en termes de jours*hommes. Le donneur d’ordre enfin, qui finance. Manque alors un acteur central, le « métier », c’est-à-dire celles et ceux qui sont en mesure d’expliquer à quoi vous servez et ce que vous faites de vos journées.&#160;Second Choix : l’expression des besoins La commande ne suffit pas. Il est commun d’aller ensuite au-devant des utilisateurs et utilisatrices que l’on cherche à équiper pour savoir comment ils aimeraient faire leur travail et ce dont ils ont besoin. Et les professionnels de l'informatique de rigoler : "l'expression de besoin c'est un peu la lettre au père noël". Problème. Tous les travails n’ont pas la même matière. Il y en a même qui reposent sur le travail des autres, comme c’est le cas des managers. Un exemple simple : mettons que vous êtes conseillère à Pôle emploi et que la direction juge nécessaire que vous disposiez d’un nouveau logiciel pour suivre les chômeurs. On va vous demander à vous et à vos collègues comment vous exercez votre métier. Toutes et tous n’allez pas répondre la même chose mais un chemin va se dessiner. Des fonctions vont être ajoutées, pour garder des traces des entretiens de suivi, indiquer l’expérience et les savoir-faire des demandeurs d’emploi, les mettre en relation avec des employeurs à la recherche de candidats, etc. Mais mettons que votre N+1, votre n+2 ou n+3 rattrape les développeurs par le col en précisant : ce logiciel doit aussi nous permettre d’évaluer le rendement des équipes et de faire du reporting. La maîtrise d’ouvrage va alors devoir redécouper, redéfinir les fonctionnalités à destination des agents pour qu’il devienne compatible avec ce qu’attendent les chefs. A priori, l’on pourrait se dire que l’efficacité est une notion évidente. Que nenni. Les attentes de la hiérarchie en matière d’efficacité sont loin d’être identiques à celles de leurs équipes. Les « chef.fe.s » cherchent avant tout à savoir si les objectifs sont atteints. Les conseillers si le travail est bien fait.&#160;&#160;Quand on parle d’améliorer l’outil de travail, il faut alors toujours se demander : « Améliorer ? Oui, mais du point de vue de qui ? Et selon quels critères ? » Un logiciel peut être très pratique pour celui qui surveille le travail et très pénible pour celui qui le réalise. Ou inversement.Et encore, l’on se situe ici dans une forme de cadre idéal où les utilisateurs visés sont effectivement interrogés. Il arrive que le bureau des méthodes, qui n’existe plus en tant que tel mais qui prend des formes nouvelles telles que les « directions métiers », placées à proximité de la direction, détermine à la place des travailleurs et des travailleuses à quoi ressemble le travail quotidien. Or, êtes-vous bien sûr que votre hiérarchie partage votre définition du travail bien fait ?&#160;Troisième choix : Le saut dans l’inconnuC’est à ce moment que l’abîme s’ouvre. Pourquoi ? Car votre organisation est en train de dépenser des sommes considérables pour améliorer un outil de travail qui n’est pas encore développé. Que faire alors des outils déjà là, utilisés tous les jours pour que tourne la boutique ? Doit-on les mettre à jour ? Le bon sens dirait… Oui ! Car la législation ne cesse d’évoluer, les comportements de votre public ou de vos clients aussi, sans parler du volume de données qui ne cesse d’augmenter et ralentissent des machines elles aussi vieillissantes. Sauf que tout cela a un coût qui se trouve en concurrence avec les dépenses de développement du nouveau logiciel. C’est là qu’un pari devient nécessaire et ne peut être « objectif » : accélérer le temps de développement ou bien maintenir la routine au goût du jour ?D’autant que cette question, un peu philosophique, a en fait une multitude de répercussions qui peuvent modifier très concrètement les conditions de travail dans une organisation.&#160;&#160;Du point de vue de l’engagement au travail d’abord. Ne pas mettre à jour revient à prendre le risque de réduire la production, certes, mais aussi de dégrader dangereusement l’ambiance de travail. Combien de temps peut-on dire : « Patience, le nouvel outil arrive » ? Sachant qu’un outil structurant pour le travail peut prendre 4, 6 ou 8 ans à être livré dans son ensemble, des durées qui excèdent assez largement l’ancienneté moyenne des managers à leur poste.Du point de vue de la hiérarchie des tâches ensuite. Pour apaiser l’ambiance, une maîtrise d’ouvrage peut faire le choix de maintenir une équipe de mise à jour de l’ancien bouquet d’application. Mais à bien y réfléchir, gérer une telle équipe n’est pas si évident que cela. L’on se retrouve en effet avec un groupe de travailleurs et de travailleuses qui sait que ce qu’il met à jour et actualise est voué à disparaître. Qui sait que ce qu’il maintient en vie est étiqueté comme démodé. Qui sait qu’à la fin du processus l’expérience accumulée sera dévaluée à comparer aux expert.e.s du nouveau système. Si le travail s’appuie en grande partie sur une relation de commandement/obéissance, la relation peut difficilement se maintenir dans le temps sans perspective d’avenir pour celle ou celui qui reçoit les ordres. Dans ce contexte, il devient envisageable de se retrouver avec un outil mis à jour à contrecœur, par des travailleurs et des travailleuses qui cherchent à s’en aller.Du point de vue technique enfin. Il apparaît nécessaire de prévoir un transfert et une interopérabilité possible entre les systèmes anciens et les nouveaux. En effet, les données représentant la mémoire de l’organisation et, de plus en plus, la matière première du travail, l’apparition d’une nouvelle application n’autorise pas à faire table rase des données collectées antérieurement. On ne peut pas effacer les dossiers clients par exemple. Il faut alors trouver des ponts, fabriquer des tuyaux, assurer une compatibilité entre les données antérieures et les modalités de leur traitement par le nouveau logiciel. Or, rien n’est moins évident. En effet, les transformations de l’activité qui ont présidé à la commande d’un nouveau logiciel, et les évolutions de l’activité qui sont survenues au cours de son développement conduisent le plus souvent à des évolutions des concepts utilisés pour décrire les « actes métiers », c’est-à-dire les tâches et les procédures. On ne parle plus le même langage à dix ans d’intervalle. Le maintien de deux systèmes fragilise donc l’ensemble de l’édifice dans la mesure où les nouveaux outils sont forcément tirés vers le passé par cette nécessité de tuilage. Du point de vue de la modernisation tant recherchée au début de l’aventure, le temps de développement de l’outil nouveau constitue ainsi un risque majeur. Il n’est pas exclu qu’entre le démarrage et la livraison… l’outil s’avère obsolète. D’où une question centrale dès le début : comment faire quelque chose qui colle aux pratiques et aux technologies de demain ? &#160;Quatrième choix : le développementUn enjeu majeur du développement réside dans la question de la sous-traitance. A priori il s’agit là d’un arbitrage purement budgétaire et « RH » (est-ce que je dispose de la force de travail nécessaire au codage dans mes rangs ?). Pour autant, engager un prestataire qui va proposer à ses équipes de « pisser de la ligne de code » n’est pas sans influence sur les fonctionnalités de l’outil. En effet, la traduction des spécificités techniques en suite de 0 et de 1 conduit inévitablement à des impossibilités de traduction, qui nécessite de savoir comment faire pour contourner l’obstacle. Plus fréquemment, il n’est pas possible de coder exactement ce que voudraient les commanditaires. Qui décide alors des modalités de résolution de ces difficultés ? Le codeur lui-même ? Son employeur ? La maîtrise d’ouvrage engageant son employeur ? Comme dans la vie politique, le périmètre des parties prenant part à la décision compte !Aussi, un des choix massifs en matière de développement informatique réside dans les méthodologies utilisées. On a affaire ici à un paradoxe. Il est difficile pour les profanes, utilisateur de logiciels et applications, de se représenter les avantages respectifs de telle ou telle façon de coder. Mais dans le même temps, certaines méthodes de développement deviennent en vogue et acquièrent des supporters en dehors même des équipes de développement. Sur quelle base la méthode est-elle retenue ?Le point commun de toutes les méthodes réside dans un seul mot : Pro-jet. Les équipes de développement fonctionnent en mode projet, c’est-à-dire qu’elles réunissent la carpe et le lapin sous la férule d’un ou de plusieurs chef.fe.s dudit projet qui essaient de faire en sorte que chacun fasse sa part du boulot en temps et en heure. Ce qui est en jeu dans cette modalité de production ce sont effectivement les délais, mais, derrière, les façons de gérer ces délais et leur dépassement. Comme son nom l’indique, un projet est un pronostic, un plan sur une comète, qui peut rencontrer des difficultés imprévues. C’est bien la gestion de ces imprévus qui fait de la méthodologie un choix.&#160;&#160;Dans les méthodes dites « en V », traditionnelles, l’esprit d’ingénieur règne. L’enjeu est de faire quelque chose qui fonctionne et l’on prend le temps qu’il faudra pour que cela fonctionne. Lorsqu’une fonctionnalité ne peut pas être développée c’est qu’elle n’était pas vraiment nécessaire. Pour passer l’obstacle, la maîtrise d’ouvrage peut accepter de « réduire la voilure » en proposant un ersatz de fonctionnalité, peut chercher à prioriser, en favorisant des fonctionnalités qui sont plus simples à développer ou tout simplement abandonner la fonctionnalité. Il est aussi possible d’en appeler au sponsor – qui détient les cordons de la bourses – pour obtenir une rallonge afin de passer l’obstacle en mobilisant davantage de jours*hommes. Cela peut conduire au développement d’une innovation subtile… ou d’une usine à gaz. Au cours des années 1990, l’Agence nationale pour l’emploi (ANPE) avait pour ambition de développer un logiciel unique prenant en compte l’ensemble des facettes de l’ensemble des métiers présents au sein de l’établissement. Après de longues années de développement, parfois douloureuses mais couronnées de succès en phase de test, l’application a pu être lancée… à la poubelle. Le volume de données brassées dans la vraie vie de l’établissement (Plusieurs millions d’inscrits) s’est malheureusement avéré trop important pour assurer des temps de traitement ajustés au rythme de travail des conseillers en présence des chômeurs. Le sablier tournait, tournait, tournait.Le principal défaut de cette méthode « en V », très rationnelle au sens où prime l’enjeu de produire une application qui se tienne, c’est bien son côté ingénieur. Si les utilisateurs ne se retrouvent pas dans l’outil développé, il est trop tard et la discussion s’arrête là où commence la recette. Car contrairement à la cuisine, la recette en informatique arrive à la fin, puisque le terme désigne le moment où l’outil est présenté à des utilisateurs clés pour qu’ils se l’approprient et expriment leur contentement, ou non. En cas de déception voire de problème grave, l’outil devra être utilisé malgré tout par l’ensemble des utilisateurs visés à moins de recourir à de nouveaux jours*hommes encore plus coûteux. En effet, il peut être nécessaire de remonter loin dans le processus de développement pour changer ce qui ne correspond pas au vécu des utilisateurs. C’est la raison pour laquelle, de nouvelles méthodes sont apparues, plus souples et plus « participatives », notamment la méthode dite agile. Cette méthode consiste à découper le « pro-jet » en petites unités cohérentes, les « deliverable units ». Chacune de ces petites briques fait alors l’objet d’une recette auprès d’utilisateurs clés, qui peuvent au fil de l’eau confirmer ou infirmer l’avancée du projet dans le bon sens. Le développement fonctionne alors par itération, avec un enchaînement de recettes successives. Les retards vont être ici dus au degré d’exigence des utilisateurs clés et à la bonne volonté (y compris budgétaire) de l’équipe projet quant à la réponse à ces exigences ainsi qu’à la pression quant à la nécessité de passer à la brique suivante.La méthode agile n’est toutefois pas sans inconvénient. En la matière, la constitution du groupe de testeurs et de testeuses constitue un enjeu majeur, difficile à prévoir. Par exemple, si vous souhaitez réunir régulièrement un groupe représentatif, il faut que ces derniers soient mobiles et puissent quitter leurs métiers régulièrement. Si vous travaillez dans une organisation économe du temps de ses membres, ils n’auront pas toujours l’autorisation de se joindre au groupe. Bien plus si vous travaillez dans une organisation de très grande taille, installée dans toute l’Europe ou toute la France, vous avez tout intérêt à prendre des testeurs et des testeuses qui sont le plus éloignés du siège, afin de développer un outil ajusté aux spécificités du terrain. Cela devient vite complexe dans certaines organisations où par construction, le terrain est loin du siège. Mettons que vous soyez inspecteur sanitaire des exploitations agricoles. Le siège est pour des raisons historiques à Paris et l’agriculture… ailleurs. L’éloignement fragilise la participation assidue de tels profils sur longue période. Et c’est là un troisième risque de ces méthodes, la « solidité » du groupe test, c’est-à-dire sa capacité à se maintenir sur un temps long. Il pourrait être plus facile de reconstituer un groupe test différent à chaque recette. Mais c’est alors prendre le temps de réexpliquer l’ensemble du processus à chaque fois et le risque de voir se multiplier les incohérences entre les différents retours des différents groupes tests. Des fonctionnalités demandées initialement peuvent apparaître inutiles ou au contraire des fonctionnalités abandonnées redevenir incontournables. Être pragmatique en la matière conduit ainsi bien souvent à privilégier des testeurs intervenant à proximité du siège et pouvant s’absenter régulièrement. Au risque de constituer un groupe très peu représentatif et amenant le développement de l’outil vers des formes qui s’éloignent du commun du travail du reste des membres de l’organisation. Il est par exemple dangereux de réunir dans une salle ceux et celles qu’on appelle communément les « geeks », particulièrement inspiré.e.s par la technique. Ils pourraient conduire l’application ou le logiciel vers des fonctionnalités expertes très peu utiles au jour-le-jour, tout en étant coûteuses à produire.Au sein d’un même niveau hiérarchique, il y a en effet des appropriations tout à fait différentes des outils informatiques.&#160;Cinquième choix : l’enrôlement.&#160;&#160;Pour terminer, une fois l’outil livré il faut bien qu’il serve à quelque chose. Ne serait-ce que par respect pour les sommes dépensées jusque-là ! Sauf qu’on fait ici face à un atavisme difficilement contournable : il est bien souvent plus rapide d’utiliser un vieil outil que l’on connait bien plutôt qu’un nouveau qu’il faut apprendre à utiliser. Cette tendance est d’autant plus forte que l’outil porte en lui des transformations du métier que l’on réprouve à titre personnel ou collectif. Les consultants en organisation parlent assez régulièrement de « résistance au changement » pour évoquer ces processus. Ils passent alors à côté d’un élément central de ces situations où les changements de logiciel impliquent une transformation du travail : de nouvelles procédures ou technologies peuvent démonétiser certains savoirs et, partant, dévaluer certaines positions qu’occupent les travailleurs. Dès lors, ce n’est pas à une résistance au changement à laquelle ils sont confrontés ; au contraire, les « résistants » portent toutes et tous des propositions de changement pour être en mesure de faire leur métier de la meilleure des façons. En revanche, ils font bien face à des luttes vouées à préserver une façon de faire le métier, des savoirs et une position légitime dans l’organisation. C’est la raison pour laquelle la vie du développement d’un outil ne s’arrête pas au moment de la livraison, lorsque les développeurs rentrent dans leur SSII. Différents choix peuvent être effectués : de la complète autonomie en laissant les utilisateurs et les utilisatrices tâtonner, au risque de perdre un temps fou. Vous pouvez aussi former tout le monde, dans des centres de formations centralisés ou non. Là encore les alternatives ne sont pas sans enjeu en matière de consommation de ressources humaines. La morale de cette histoire, c’est que l’on finit toujours par arriver à bosser. Et c’est même un petit miracle qu’on y parvienne quand on voit l’ensemble des embûches auxquelles chaque petite application a dû faire face. Toutefois ce n’est pas parce qu’elle fonctionne bien que vous ferez mieux votre travail et inversement. Ce qui est en jeu, c’est bien qui définit ce que bien travailler veut dire.Crédits des illustrations :Image de couverture : Niriel Halloween desktopImages d'illustration :Vector Hugo command / Kraftwerk - Computer LoveOnionandres felipeRichard CliffordDonkeyHotey . The source image for this illustration is from a World War II poster titled "I want you for U.S. Army," designed by James Montgomery Flagg for the U.S. Army and available via the Library of Congress