#Sommaire-
Hostilité efficiente
En quarante ans de métier, je n'ai cessé d'observer l'hostilité universelle dont font l'objet les informaticiens, au sein de l'entreprise, de la part de leurs collègues et des dirigeants, et ce même s'ils se déguisent en spécialistes du système d'information ou du réseau de communication voix-données.
Cette hostilité n'est pas sans effets : périodiquement les entreprises se débarrassent de leurs informaticiens, par externalisation, par délégation des fonctions informatiques à des utilisateurs supposés éclairés, par fermeture des départements informatiques (ou du système d'information) et répartition de leurs anciennes équipes entre les directions utilisatrices, par filialisation, par délocalisation.
Illusions et apories de l'externalisation
Naturellement rien n'y fait : les fabuleux contrats d'externalisation auprès de prestataires prestigieux, annoncés par de grands articles dans la presse, se terminent, cinq ans plus tard, par une réintégration piteuse de l'informatique dans l'entreprise, après évaporation de dizaines ou de centaines de millions d'Euros. Et il ne pouvait en être autrement : puisqu'aujourd'hui l'entreprise est organisée autour de son système d'information, de son réseau et de ses accès à l'Internet, il est très pénalisant d'avoir à administrer ce système nerveux au travers de relations contractuelles que le prestataire prudent aura voulu précises, c'est-à-dire telles que chaque action imprévue demande des avenants au contrat, payés bien sûr au prix fort. Et la vie d'un système d'information est faite d'imprévus, que ceux-ci résultent d'évolutions de la législation, de changements du périmètre de l'entreprise (par fusion, acquisition, filialisation, reconfiguration du capital, etc.), de réorientations stratégiques, etc. Plus généralement, pour citer Philippe Zarifian [1], « travailler, c'est s'affronter à des situations qui comportent du surprenant, de l'inédit, de l'imprévu ».
Il y a d'autres raisons aux échecs de l'externalisation : confier à une entreprise extérieure le nettoyage des locaux est relativement aisé, parce que la nature des tâches à accomplir est assez simple à décrire, peu sujette à variation, facile à vérifier : bref, il est assez difficile d'échouer dans cette entreprise, sauf à être une administration publique empêtrée dans des règlements d'un autre âge (cf. ici même l'article sur les Marchés publics). Mais pour le système d'information il en va autrement : comme son nom l'indique, il concerne de l'information, matière extrêmement fluide et changeante, et le transfert de son administration à des tiers demande de ce fait des échanges d'information beaucoup plus importants en volume et beaucoup plus difficiles à circonscrire que pour le nettoyage des locaux. Non seulement ce n'est pas du même ordre de grandeur, mais ce n'est pas de même nature, les échanges d'information devront se poursuivre pendant toute la durée du contrat d'externalisation, il est même probable qu'ils seront le poste de dépense le plus important de l'opération, si l'on y compte les activités d'avant-vente, de support, d'assistance technique, de maintenance applicative, curative ou évolutive, la définition des cahiers des charges pour les avenants nécessaires aux évolutions, etc. On estime en général que confier à un tiers la réalisation d'un segment du système d'information multiplie par quatre le coût de l'opération, par rapport à une réalisation au plus près du demandeur, conformément par exemple aux méthodes dites Extreme programming.
Bref, l'externalisation sera coûteuse, de plus en plus coûteuse au fur et à mesure que le système d'information devra dériver par rapport au périmètre défini initialement, et même si les difficultés purement techniques s'amenuisent avec le temps et l'accroissement de l'expérience du prestataire, l'écart par rapport aux espérances fonctionnelles ne pourra que croître et engendrer des coûts proportionnels à l'écart. C'est pourquoi, au bout de cinq ans en général, le système externalisé est réintégré : ceux qui ont décidé l'externalisation ne sont plus là, appelés aux hautes fonctions méritées par leur succès, et les nouveaux responsables vont pouvoir remporter des succès encore plus grands à l'occasion de la réintégration.
Mais pourquoi l'hostilité ?
Revenons au sujet : les lignes ci-dessus exposent pourquoi il est vain d'espérer se débarrasser totalement et définitivement des informaticiens. Un autre article de ce site explique Comment travailler avec des informaticiens, pourquoi c'est difficile, et comment essayer d'éviter cette situation. Mais ceci n'explique pas l'abîme d'incompréhension qui, dans une proportion considérable de situations en entreprise, se creuse entre les informaticiens et leurs collègues.
Motifs anciens et banals
Parmi les expressions les plus répandues de l'animosité envers les informaticiens, beaucoup relèvent d'un sentiment banal : la jalousie. L'informatique est une science ainsi qu'une technologie, les deux neuves et au développement rapide, souvent aux dépens des positions acquises et des hiérarchies en place. Le marché de l'emploi a toujours été favorable aux informaticiens, plus recherchés et donc mieux payés que les membres des professions traditionnelles saturées ou en déclin, qui cherchent à préserver leur situation, et dont l'acrimonie s'augmente de voir les informaticiens résister d'autant mieux à leur hostilité que les progrès de leur discipline ridiculisent les contempteurs.
Conjuguée à la jalousie vient souvent l'annonce de la fin de l'informatique ; je l'ai entendue fréquemment, sous forme affirmative, par exemple en 1981 de la bouche de M. Piganiol, sociologue et expert auprès du ministère du travail : « cette exception informatique va bientôt finir », ou sous forme interrogative, en 1993, de la bouche d'une directrice de recherche à l'Institut Pasteur : « quand cela va-t-il finir, cette histoire d'informatique ? ». Pas de sitôt, bien sûr. La fin de la soit-disant « bulle Internet » en 2001 a ravivé toutes ces espérances eschatologiques de délivrance du mal informatique.
Mes observations, empiriques mais sur une période maintenant assez longue, suggèrent un cycle quinquennal : à l'année n l'hostilité est au paroxysme, l'espoir de délivrance itou, on vire l'informatique de la boîte. En n+5, si la boîte en question existe encore (situation dont la possibilité est maximale si l'on a affaire à une administration, peu sujette à la faillite), on recrée l'informatique, bon gré mal gré.
Une autre observation personnelle : dans une structure petite ou moyenne, moins de 2 000 personnes, si ce n'est pas toute l'équipe informatique qui a disparu, mais seulement un personnage clé, le responsable, ou l'ingénieur système et réseau, la situation restera en apparence supportable pendant deux ans, à l'issue desquels les catastrophes vont survenir. J'ai retrouvé plusieurs fois ce délai de deux ans, dans des circonstances similaires qu'il m'est impossible de dévoiler sans nuire aux survivants. À titre personnel, j'ai à trois reprises remplacé un responsable informatique parti depuis deux ans : à l'INED, au CNAM, à l'Institut Pasteur. Ce qu'il y avait de bien pour moi, c'est que dans deux de ces trois cas, rien n'était à garder des décombres de l'étape précédente.
Des rythmes de travail différents
Une piste qui pourrait mener à une réponse plus originale m'a été fournie récemment par un chef d'entreprise que je connais ; l'activité de son entreprise, jeune, moderne, en plein expansion, repose entièrement sur l'informatique : en tout cas, il en a conscience, parce que toutes les entreprises reposent aujourd'hui entièrement sur l'informatique, seulement leurs dirigeants ne s'en sont pas toujours rendu compte. Sans préciser plus, disons que son activité est la fourniture de services aux entreprises, dans un domaine lié à l'Internet.
Je rencontre assez régulièrement ce dirigeant depuis la création de son entreprise, et chaque fois il me parle des problèmes qu'il a avec ses informaticiens, bien réels et assez classiques, mais dont l'origine ne semblait pas facile à trouver, jusqu'à notre dernière conversation d'où surgit un indice : « ils sont à part dans l'entreprise, ce sont les seuls à ne pas être au même rythme que les autres ».
Cette idée de différence de rythme me sembla prometteuse ; en effet, dans une entreprise de 250 salariés, il n'y a guère de place pour des emplois dont personne ne sait à quoi ils servent, et chacun a un travail en phase avec des événements extérieurs : le service comptable vit au rythme des bons de commande, des signatures de contrats, des factures reçues ou à émettre ; l'activité des commerciaux est cadencée par les rendez-vous avec les clients et les prospects ; la DRH et la direction financière administrent des dossiers dont beaucoup répondent à des sollicitations extérieures. Le marketing et la communication sont dans des rôles un peu différents, mais pour eux le rythme est souvent imposé par la direction de l'entreprise, dont ils sont très proches.
L'indice de Buxton
Pour se faire une idée plus précise du rythme de travail de chaque entité au sein de l'entreprise, on peut s'inspirer d'un article d'Edsger Dijkstra et réfléchir aux idées suggérées par ce qu'il y dit de l'indice de Buxton : cet indicateur, qui porte le nom de son inventeur, professeur à l'université de Warwick en Angleterre, est défini comme la durée en années de la période pour laquelle une personne ou une équipe établit des plans d'action. L'indice de Buxton d'un commerce de détail pourra être estimé à 1/2, celui d'un député qui souhaite être réélu à 5 (dans un pays comme la France où les élections législatives ont lieu tous les cinq ans), par exemple.
Ce que révèle une observation des activités humaines à la lumière de l'indice de Buxton, c'est qu'une coopération étroite entre des personnes ou des équipes qui ont des indices de Buxton trop différents est vouée à l'échec. Le groupe doté du plus faible indice de Buxton sera soupçonné de manquer de vision à long terme, celui qui a l'indice de valeur la plus élevée sera taxé d'irresponsabilité et accusé de se laisser vivre sans se soucier des clients. L'avantage de l'indice de Buxton est d'être une simple valeur numérique, sans connotation morale.
Nous sentons bien que cette vision des choses n'est pas sans rapport avec notre affaire d'incompréhension entre d'une part le commercial, qui envisage le délai entre la commande de son client et la livraison du service en termes de jours ou à la rigueur de semaines, et qui pour l'installation de la nouvelle version du logiciel de CRM sur son portable raisonne plutôt en minutes, et d'autre part l'informaticien qui sait qu'il n'y a pas de développement en moins de six mois, que pour la migration vers une nouvelle infrastructure de messagerie c'est aussi six mois, et vers un nouveau système financier et comptable au moins un an (s'il y a plusieurs sites et plus de mille personnes concernées, il faut multiplier coûts et délais par deux, si l'on est soumis à la réglementation des Marchés publics et que l'on fait appel à des prestataires extérieurs, multiplier au moins par trois). Mon expérience d'informaticien me confirme que ces délais sont les bons, mais c'est très difficile de le faire comprendre à des gens dont ce n'est pas le métier.
Problèmes de Workflow
L'informaticien n'a pas seulement un horizon temporel différent de celui de ses collègues : il n'est pas inséré de la même façon dans les processus de l'entreprise. Nous avons vu ci-dessus que les actions des comptables, des commerciaux ou des financiers étaient le plus souvent cadencées par des interactions avec le monde extérieur ; ces actions ont aussi très souvent une durée prévisible. Elles se prêtent donc bien à être insérées dans ce qu'il est convenu d'appeler un workflow, c'est-à-dire, nous apprend Wikipédia, « la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus opérationnel ».
Bien sûr, si un informaticien est cantonné à des tâches bureaucratiques, telles que rédaction de cahiers des charges et de contrats, élaboration et contrôle de plannings ou suivi de budgets, ses activités pourront entrer dans un workflow, il sera bien vu de ses chefs, il ressemblera à ses collègues, il remplira bien ses fiches d'activité, bref tout ira bien, si ce n'est qu'il ne fera pas d'informatique.
Par contre dès que l'informaticien s'adonne à ce qui constitue le cœur de son métier, c'est-à-dire le développement de systèmes informatiques, et il faut entendre par là aussi bien la création d'un logiciel que le paramétrage et l'organisation d'un système complexe, tel qu'une infrastructure de messagerie, son activité ne se prête plus au lit de Procuste d'un workflow. Non seulement les délais se comptent en mois, mais ils cessent d'être vraiment prévisibles, parce que le développeur est devant sa feuille blanche et que des problèmes parfaitement imprévisibles peuvent surgir.
Aléas du développement : un exemple
Je donnerai juste un exemple minuscule : j'ai eu l'occasion de m'occuper de la mise en œuvre d'un prototype d'annuaire électronique et d'infrastructure de gestion de clés (il s'agit d'un système destiné à délivrer des certificats électroniques, comme celui que vous utilisez peut-être pour payer vos impôts par Internet). L'ensemble reposait sur des logiciels libres (OpenLDAP et OpenTrust-Pki), paramétrés pour une certaine configuration de système avec l'aide d'une prestation de service fournie par l'auteur d'OpenTrust-Pki.
Le prototype fonctionnait, il fallait mettre en service sur le site de production. Nous avons rempli pour ce faire un épais document destiné à fournir aux exploitants tous les détails techniques nécessaires à la mise en production ; tout était censé être prévu, mais... les nouveaux serveurs achetés pour le déploiement comportaient des dispositifs matériels non supportés par la version de système utilisée par l'intégrateur (des contrôleurs RAID, pour assouvir la curiosité des connaisseurs). La nouvelle version du système, compatible avec nos serveurs, comportait une version du serveur Web incompatible avec l'application.
Bref, tout avait été prévu, sauf le fait que les ordinateurs et les logiciels évoluent dans le temps, et que l'innovation technique, par nature, n'est pas planifiable. Une fois que quelque-chose fonctionne, on aimerait que plus rien ne change, mais c'est impossible. Le problème a été résolu, mais avec trois jours de développement supplémentaires, qui ont causé deux mois de retard, parce que les gens compétents ne sont pas disponibles au coup de sifflet quand on a besoin d'eux à l'improviste : nous pouvons considérer que nous nous en étions bien tirés.
Disjonction du développement et de la gestion
Bref, une fois lancés dans une activité de développement, sans même parler de R&D, les informaticiens entrent dans un calendrier qui n'a plus grand-chose de commun avec celui de leurs collègues. Les contraintes techniques qui s'appliquent à leur travail sont aussi d'un autre ordre que celles de l'activité propre de l'entreprise, ce qui les conduit à respecter d'autres valeurs, d'autres sources d'autorité, qui sont celles de leur corporation.
Cette disjonction entre les activités de développement informatique et les activités de gestion de l'entreprise n'est pas franchement inédite : du temps de l'ancienne économie, il y avait le siège et les usines, et les gens du siège savaient bien que ce qui se passait à l'usine obéissait à des règles spéciales. Mais cette différence était mieux comprise, parce qu'elle était matérialisée par un éloignement topographique et sociologique, tandis que les informaticiens vivent dans les mêmes bureaux que les gestionnaires et sont habillés de la même façon. Enfin, presque.
Cette analogie entre développement informatique et usine ne doit pas être poussée trop loin : il y a des différences importantes. Ce qui est fabriqué dans une usine a fait l'objet de prototypes, le processus de fabrication a été expérimenté et codifié, le temps de fabrication de chaque objet est connu. Cette situation peut se retrouver en informatique si l'on vend un progiciel, ou un modèle de site Web réalisé selon un patron standard : on pourra parler alors d'industrialisation, mais la recopie du produit standard n'est pas à proprement parler un développement. Par définition, les développements informatiques sont à chaque fois des prototypes. Quand j'entends des managers dire que leurs équipes de développement ou leurs centres d'exploitation doivent fonctionner comme des usines, je sais que l'échec est pour bientôt. Il est par contre possible d'industrialiser des déploiements de systèmes standard.
Comment créer la compréhension réciproque ?
Après avoir décrit quelques causes d'incompréhension entre informaticiens et civils (il ne serait sans doute pas difficile d'en trouver d'autres), il convient de souligner que ce problème n'est pas bénin, mais grave. Il est vraissemblable que les entreprises qui arriveront à le surmonter, au moins en partie, en tireront un avantage compétitif significatif. Voici quelques pistes que je suggère ici :
[1] Philippe Zarifian. À quoi sert le travail ? La Dispute/Snédit, Paris, 2003.
Jeu de briques
Snake
Pacman
Bubble