Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Comment travailler avec des informaticiens ?
Article mis en ligne le 4 avril 2006
dernière modification le 11 août 2014

par Laurent Bloch
logo imprimer
Licence : CC by-nd

Ce texte est extrait de mon livre Systèmes d’information, obstacles et succès, paru en mars 2005 aux Éditions Vuibert. Cf. la page d’accueil de ce livre

Si nous essayons de résumer ce que nous avons écrit au fil des quatre premiers chapitres de ce livre, le bilan ne semble pas très encourageant pour un maître d’ouvrage qui voudrait lancer un projet
d’informatisation en faisant appel à des informaticiens, que ce soit
ceux d’une équipe interne ou d’une société extérieure :

  1. définir le travail à faire, c’est-à-dire rédiger un cahier des charges et des spécifications détaillées, est très difficile, sinon impossible ;
  2. la plupart des méthodes mises au point à cet usage sont lourdes, onéreuses et inefficaces, sinon contre-productives ;
  3. les informaticiens ont une tournure d’esprit et une psychologie assez particulières qui rendent le travail avec eux très difficile et incertain ;
  4. la complexité du travail des informaticiens en rend l’encadrement et le contrôle également difficiles et incertains ;
  5. les seules méthodes qui semblent prometteuses demandent un investissement personnel très important de la maîtrise d’ouvrage, et ce tout au long du projet ;
  6. ces méthodes prometteuses sont pour la plupart de surcroît itératives, car l’objectif se définit progressivement au cours de la réalisation, avec la conséquence souvent perçue comme déplaisante que l’on ne sait en commençant ni combien de temps cela va durer ni combien cela va coûter (la réponse à cette dernière objection, c’est qu’avec une méthode classique et un cahier des charges, on ne sait pas non plus combien de temps cela va durer ni combien cela va coûter, mais que l’on en a l’illusion).

Bref, il faut être inconscient pour se lancer dans une telle aventure. Que faire alors si on a vraiment besoin d’un système informatique ?

 Échapper au développement

 Un logiciel existe déjà

La première question à se poser est : n’existe-t-il pas un système déjà réalisé qui pourrait convenir ? Si la réponse est oui, et si le logiciel est disponible, il faut l’adopter sans hésiter : quel qu’en soit le prix ce sera moins cher, moins long et moins douloureux que de se lancer dans un développement de novo.

Bien sûr, pour déterminer la réponse à la question ci-dessus il ne faut pas oublier la proposition « qui pourrait convenir ». Cela doit être examiné avec soin. Le logiciel correspondant peut être un progiciel du commerce ou un logiciel libre. S’il ne convient qu’à 90%, il est presque certainement préférable de s’adapter soi-même au
logiciel que l’inverse : il faut en effet renoncer à la tentation d’adapter le logiciel à ses besoins, parce qu’une adaptation c’est un développement, et donc plonger à nouveau dans la situation horrible décrite au début de ce chapitre. Un ego sur-dimensionné, ou le respect inopportun de procédures issues du passé, ou l’obéissance aux caprices de certains responsables conduisent certains maîtres d’ouvrage à demander de multiples adaptations aux progiciels qu’ils achètent ; ce sont autant de développements spécifiques qui vont grever le budget jusqu’à atteindre le coût d’un développement entièrement nouveau, tout en détruisant la cohérence initiale du logiciel ; il convient donc de les limiter au strict nécessaire, et plutôt profiter de l’adoption du nouveau système informatique pour réformer les procédures de gestion.

Une variante de cette solution pourrait être qu’il n’y ait pas un logiciel existant qui réalise la fonction voulue, mais plusieurs logiciels qui en réalisent des parties. L’assemblage de plusieurs logiciels pour en faire un plus gros, c’est un développement, et ce développement ne sera un projet réaliste que si les caractéristiques techniques des logiciels envisagés s’y prêtent. Les logiciels libres, de par l’ouverture de leur code source et leurs méthodes particulières de développement exposées dans un chapitre ultérieur, se prêtent en général particulièrement bien à cet exercice, d’autant mieux qu’il existe pour ce faire des outils libres très bien adaptés comme les langages de script Perl,
Python ou Ruby. Le développement envisagé ici sera sans doute peu volumineux, ce qui le rendra plus raisonnable.

 Travailler sur deux plans orthogonaux

Des épisodes précédents de ce récit se dégage l’idée que ce qui rend si difficile et si hasardeux le développement d’un logiciel, ce sont les relations de l’équipe de développement avec le maître d’ouvrage, que nous pouvons assimiler de façon générique à un client : dès lors qu’un client veut donner des consignes à des développeurs, c’est compliqué et potentiellement conflictuel. Nous avons expliqué pourquoi la rédaction de cahiers des charges ne résolvait rien, et nous pouvons même dire que plus le cahier des charges sera précis et détaillé, plus le développement sera long, onéreux, conflictuel et au bout du compte décevant, tout
simplement parce que le cahier des charges sera de toute façon non pertinent, et qu’une erreur détaillée et circonstanciée est plus difficile à corriger qu’une erreur brève et imprécise.

Nous avons évoqué ci-dessus une façon de résoudre ce problème : l’eXtreme Programming organise le développement autour d’une équipe qui associe maîtrise d’ouvrage et maîtrise d’œuvre de façon pratiquement fusionnelle. Le cahier des charges s’élabore de façon incrémentale au cours même de la réalisation, et au vu de ses résultats intermédiaires. Cette solution paraît très séduisante, et nous
décrirons ci-dessous une expérience, assez différente mais fondée sur un principe voisin, qui fut couronnée de succès. Lorsque c’est possible nous pensons qu’il faut au moins s’inspirer de cette méthode, sinon en appliquer tous les détails. Mais
nous avons aussi souligné que la sociologie particulière des milieux de direction des entreprises et les rapports de pouvoir qui s’y nouent rendaient sans doute une telle démarche souvent impraticable.

Si la fusion entre l’équipe de maîtrise d’ouvrage et celle de maîtrise d’œuvre n’est pas possible, on peut essayer une méthode qui en soit exactement le contraire : leur séparation totale. Observons d’ailleurs que c’est ce qui se passe si l’on a recours à un progiciel ou à toute autre forme de logiciel « tout fait », au paramétrage près, auquel de toutes les façons on n’échappera pas. Pendant les vingt ans durant lesquels j’ai dirigé des équipes d’informatique scientifique, c’est ainsi que j’ai procédé. Nous mettions en place des infrastructures (ordinateurs, systèmes,
réseaux) que nous nous efforcions de rendre le plus accessibles et le plus disponibles possible, sur ces infrastructures nous installions les logiciels et les bases de données qui nous semblaient les plus appropriés aux usages des chercheurs, qui d’ailleurs ne se privaient pas de nous faire des suggestions. Nous organisions des formations à l’usage de ces systèmes, et de la sorte nous répondions à la plupart des demandes exprimées ou potentielles. De ces interactions
avec les chercheurs naissaient des idées de logiciels, que nous développions de notre propre initiative, non sans bien sûr soumettre nos prototypes à la critique éclairée des utilisateurs. Les résultats n’ont pas été mauvais, comme en témoignent quelques documents [1].

Est-il possible d’obtenir par ce procédé un système de contrôle du trafic aérien ? un système de gestion financière et comptable ? Il n’y a pas de réponse générale à cette question, et cela dépend pour une grande part de l’équipe de développeurs, qui
peut avoir en son sein des compétences financières et comptables, ou en contrôle de trafic aérien : j’ai connu un responsable informatique qui lisait quotidiennement le Journal Officiel pour adapter son logiciel à la réglementation, qu’il connaissait bien mieux que le directeur financier et le chef comptable. Signalons que beaucoup de logiciels de pointe sont constitués au moins en partie de travaux effectués à l’occasion d’une thèse universitaire ou d’un diplôme d’ingénieur, et ce dans les domaines les plus variés, y compris le contrôle du trafic aérien. On peut imaginer aussi que les chances de succès seront meilleures si les développements sont constitués, plutôt que d’un seul logiciel monolithique, de plusieurs logiciels de taille
moyenne et fonctionnellement relativement autonomes : trésorerie, comptabilité, budget, commandes, gestion des antennes régionales, etc. Cela est possible sans pour autant renoncer à la cohérence des données. J’ai rencontré un dirigeant qui se plaignait de ne connaître la situation comptable de son entreprise (un établissement public) qu’avec un retard d’un mois : la cause de ce dysfonctionnement n’était
sûrement pas technique, même si la technique y contribuait. Ce qui a été dit plus haut sur les règles de la comptabilité publique et sur l’organisation sociale des gens chargés de les appliquer me semble une meilleure piste pour en trouver les raisons.

 Des logiciels moyens pour des systèmes sobres

De façon générale, tout plaide, lorsque c’est possible, pour le logiciel de taille moyenne. Le plus souvent un logiciel devient gros non pas par l’effet du volume et de la complexité des tâches qu’il doit accomplir, mais à cause de la lourdeur de l’organisation sociale du maître d’ouvrage, de la difficulté à résoudre les conflits entre les différents groupes concernés, et de la difficulté à comprendre le cahier des charges. L’intervention de prestataires extérieurs n’est finalement sollicitée que pour résoudre des conflits internes autrement insolubles, et elle contribue rarement à rendre le projet plus sobre. Si l’on peut s’affranchir de cette organisation en supprimant toute la démarche de cycle en V, de cahier des charges et de groupe projet, tout deviendra plus simple et le logiciel pourra maigrir pour devenir moyen.

J’entends par moyen un logiciel dont la version initiale pourra être développée en moins de deux ans par une équipe de moins de huit personnes, maître d’ouvrage délégué et responsable de l’équipe compris. On note que cette taille d’équipe est compatible avec la méthode eXtreme Programming.

En fait, pour développer un tel logiciel, le mieux sera sans doute de commencer par un prototype développé en six mois par deux ou trois personnes. Ce prototype fera sans doute apparaître une structuration du logiciel telle que des grandes parties pourront être considérées comme relativement indépendantes, ce qui permettra une division du travail plus facile et donc un accroissement de la taille de l’équipe.

Supposons que nous soyons dans un cas où un développement de logiciel n’a pas pu être évité. Si le logiciel est moyen, c’est-à-dire sobre, et que le périmètre qu’il englobe est limité, le risque en laissant un peu la bride sur le cou à l’équipe de développement redevient raisonnable. Si cette équipe, au lieu d’être exclusivement constituée d’employés d’un prestataire extérieur, comporte des développeurs de l’entreprise maître d’ouvrage, le client pourra assurer la maintenance de l’application et organiser des itérations du cycle de développement pour converger vers ce que souhaite l’utilisateur, sans encourir pour autant des coûts faramineux de « tierce maintenance applicative ». Mais une telle démarche n’est généralement pas populaire parce qu’elle n’engendre pas les projets pharaoniques et les budgets colossaux qui en propulsent les responsables à la une de la presse professionnelle ; elle ne permet pas non plus de se débarrasser complètement de ses
informaticiens. Il serait intéressant d’étudier comment les entreprises de type SSII (aujourd’hui on dirait plutôt ESN) ont inventé les « concepts » de la conduite de projet, de la tierce maintenance applicative, de la réingénierie de processus, de l’externalisation et quelques autres, comment la presse spécialisée a propagé la bonne nouvelle, et comment les maîtres d’ouvrage incompétents gobent toutes les modes qui passent, pour le plus grand bénéfice des SSII et des consultants divers et variés.

Bref, il n’y a pas de recette miraculeuse, mais des moyens pragmatiques d’échapper à l’échec promis à coup sûr par le cycle de développement en V.

 Le modèle de l’équipe de tournage

Le développement de jeux vidéo est aujourd’hui un secteur moteur de l’industrie informatique, tant pour le matériel que pour le logiciel. Il a suscité les avancées les plus récentes dans des domaines aussi variés que les micro-processeurs pour micro-ordinateur, les processeurs spécialisés pour les cartes graphiques, le traitement du signal, le traitement du son, et les algorithmes les plus efficaces pour tirer parti de tous ces dispositifs.

S’il y a encore dans ce domaine quelques réalisations artisanales, le développement de jeux engage le plus souvent des investissements très importants. Le cycle de développement en V avec cahier des charges n’y est pas de mise, le processus ressemble plutôt à celui de la réalisation d’un film : il y a un scénariste, le réalisateur part du scénario, mais il arrive qu’il modifie celui-ci au cours du travail ; il est assisté de graphistes, d’ingénieurs du son, d’assistants chargés de la continuité, du montage, des effets spéciaux, etc.

Ce type d’organisation me semble mieux correspondre à la nature intellectuelle d’un développement informatique que le modèle taylorien et le cycle en V.

 Le logiciel libre, phénomène technique, social et culturel

Le recours au logiciel libre, dont nous avons déjà abondamment parlé, pourrait n’être qu’un cas particulier de la section ci-dessus, « un logiciel existe déjà », mais en fait la nature particulière des logiciels conçus selon la méthodologie du libre induit en général des usages spécifiques. Le monde du logiciel libre, comme le monde Unix dont il est pour l’essentiel issu, se caractérise par sa sociologie et par ses traits culturels presque autant que par une technologie originale. Pour réussir une informatisation fondée sur des logiciels libres il convient de se familiariser avec tous ces aspects. Lire les revues, fréquenter les associations et les conférences qui s’y consacrent peuvent constituer une bonne initiation, ainsi que le moyen de rencontrer des spécialistes dont certains pourront peut-être rejoindre votre projet, ou en tout cas vous mettre sur la piste de solutions qui vous conviennent. Hormis ces aspects socio-culturels dont il faut avoir conscience pour ne pas échouer, le logiciel libre est un moyen parmi d’autres pour éviter d’entreprendre le développement d’un logiciel.

 Le modèle Java, et autres types de composants

La caractéristique la plus novatrice et la plus intéressante du
langage Java réside dans son immersion au sein de l’Internet : un
client WWW (comme un navigateur, Internet Explorer ou
Mozilla) peut interroger un serveur qui va lui envoyer en
réponse un programme Java appelé applet [2] qui s’exécutera sur la machine du client, dans le contexte du navigateur. À l’inverse, un programme Java peut utiliser un objet ou
une classe qui se trouve sur un serveur à l’autre bout de la planète.
C’est possible parce qu’un programme source écrit en Java est traduit
(compilé) vers un langage intermédiaire indépendant du processeur sur
lequel il sera exécuté, et il sera exécuté par une machine virtuelle
Java (JVM). Il suffit donc de disposer d’une JVM (il y
en a une dans chaque navigateur WWW, sur la plupart des postes de
travail usuels, dans les téléphones portables et les assistants
personnels récents, etc.) pour utiliser à loisir des programmes
Java obtenus par le réseau. Cela s’appelle du code mobile, et c’est révolutionnaire.

Cette technique révolutionnaire a suscité des pratiques nouvelles. On
y a vu un moyen d’atteindre l’objectif tant désiré et si peu atteint du
génie logiciel : la réutilisation de composants logiciels. Et
effectivement sont apparues des bibliothèques publiques de classes
Java, comme les EJB[] (Enterprise JavaBeans) créées
et diffusées par l’inventeur du langage, Sun
Microsystems
. Le propos de telles
bibliothèques est de fournir des fonctions élémentaires prêtes à
l’emploi pour servir à la construction de programmes plus vastes dans
un domaine particulier, que ce soit la cryptographie ou la gestion de
commandes. L’auteur du programme final n’a plus qu’à assembler selon
les règles fixées des classes testées et documentées.

Le succès de cette entreprise a été non négligeable, mais inférieur
cependant aux espérances. Les raisons de cette déception relative
nous semblent être les suivantes :

- Le langage Java a soulevé un grand enthousiasme lors de son
lancement, mais il est vite apparu qu’il était plus complexe et plus
difficile à utiliser que ce que l’on avait cru. Il a subi la
concurrence de langages moins puissants mais plus faciles à
utiliser, comme Perl et PHP pour la programmation « côté serveur » et
Javascript (qui malgré son nom n’a rien à
voir avec Java) pour la programmation « côté client », c’est-à-dire
dans le navigateur. Pour ces langages se sont créées et développées
des bibliothèques de composants (CPAN pour Perl, Pear pour PHP).
Perl et PHP peuvent facilement être incorporés au logiciel serveur
WWW le plus répandu, Apache, ce qui les rend
très pratiques à mettre en œuvre pour la programmation WWW.
Perl, PHP et Apache sont de surcroît des logiciels libres, ce qui a
favorisé leur dissémination.

- L’inventeur du langage a voulu en garder le contrôle, notamment
en modifiant les spécifications d’une version à la suivante, en
poursuivant devant les tribunaux les producteurs de versions
hétérodoxes et en pratiquant (au moins dans les premières années)
une politique de disponibilité de machines virtuelles qui négligeait
certaines architectures matérielles. Ces pratiques ont
détourné de Java certains développeurs.

- Il est apparu que développer un logiciel en utilisant à tout
crin des classes obtenues par le réseau, mais d’origines parfois
incertaines, pouvait conduire à une perte de maîtrise du
développement, le programmeur ne sachant plus très bien qui fait
quoi dans son programme. Assez vite il n’est plus possible de
garantir la qualité du code produit, non plus que son homogénéité.
Ces inconvénients existent aussi bien entendu pour les bibliothèques
de composants destinés à Perl, PHP ou Javascript. Il s’agit donc
d’une leçon de prudence retirée des premières expériences de
réutilisation à grande échelle de composants logiciels.

Malgré les réserves énoncées ci-dessus, le recours à des bibliothèques
publiques de composants logiciels est une technique à suivre.

La construction de logiciels selon les principes de la programmation
par objets, en Java ou en C++, a fait l’objet d’une élaboration
méthodologique intéressante qui n’est pas sans parenté avec le recours
aux composants logiciels (et qui ne l’exclut pas) : les modèles de
conception réutilisables (« Design Patterns », ou patrons de
codage
)[] ; au lieu d’importer un composant, on
programme en suivant un patron, au sens que ce mot a pour les
couturières, et qui est la traduction exacte de pattern.

 Et s’il faut malgré tout développer ?

 Conditions initiales indispensables

Si aucun des recours énumérés ci-dessus n’a permis d’échapper à la
perspective effrayante de devoir développer un logiciel de novo,
comment s’y prendre pour éviter la catastrophe ? Les conseils suivants
me semblent s’imposer :

  1. Il faut avoir au sein de l’entreprise de vraies compétences informatiques, c’est-à-dire des ingénieurs capables de comprendre et de critiquer tous les aspects du développement même s’ils ne le font pas eux-mêmes. Ce qui signifie bien entendu que leur activité n’est pas limitée à la rédaction de cahiers des charges et à l’administration de contrats, mais qu’il leur arrive de développer réellement, et pas tous les dix ans. Incidemment, et contrairement à la doxa répandue par les SSII et la presse spécialisée, il n’y a pas de honte à entreprendre des développements avec ses propres personnels.
  2. Un bon équilibre doit être trouvé entre les compétences internes et externes. Si les effectifs de développeurs internes descendent en dessous d’un seuil de 40% sur l’ensemble des projets, la situation devient dangereuse. Il s’agit bien sûr ici de vraies compétences en informatique, pas en chefferie de projet ou en comptabilité. Ce ratio de 40% doit être adapté aux circonstances : en situation de croissance d’activité il convient d’augmenter la part des effectifs internes pour ne pas être pris de court devant des besoins nouveaux, par exemple jusqu’à 60%, alors que si l’on prévoit une baisse d’activité il peut être judicieux d’accroître le recours à l’externalisation pour éviter d’avoir plus tard à organiser des plans sociaux. Mais l’idée est de maintenir une situation où l’entreprise garde le contrôle de son SI [3].
  3. Il faut aussi trouver un bon équilibre entre maîtrise d’ouvrage et maîtrise d’œuvre : ce point sera développé à la section suivante.
  4. Il faut lire le livre de Brooks [4] et un livre sur l’eXtreme Programming [5] : même si on ne retient pas
    toutes leurs idées, il faut les connaître parce qu’elles sont bien
    meilleures que celles des autres.

  5. Après avoir lu les livres conseillés au point 4, il faut mettre en pratique au moins une idée : la spécification du logiciel évoluera et s’affinera au fur et à
    mesure du développement, il est inutile, voire nuisible, de fixer
    trop de choses au départ. La rédaction de l’appel à concurrence et
    le choix d’un éventuel prestataire dépendent fortement de ce
    principe. Dans un service public français il est très difficile de
    suivre ce conseil, sauf à faire le développement avec des personnels
    du service.
  6. Le client réel, celui qui sera le bénéficiaire du système à
    réaliser, doit s’impliquer fortement et concrètement dans le projet.
    S’il ne le fait pas, il doit renoncer à son droit de parole au profit
    d’une maîtrise d’ouvrage déléguée qui, elle, devra prendre part
    activement au développement. Si ni l’une ni l’autre de ces conditions
    ne peut être remplie, le projet sera un échec, inéluctablement.

 Équilibre entre maîtrise d’ouvrage et maîtrise d’œuvre

Parmi les conditions récurrentes d’échec de projets informatiques
figurent les dysfonctionnements de la maîtrise d’ouvrage, de la
maîtrise d’œuvre, des deux, de leurs relations mutuelles, ou
la conjonction de plusieurs de ces conditions. Comme énoncé à
l’alinéa précédent, le maître d’ouvrage, c’est-à-dire le client réel,
doit assumer pleinement ses responsabilités et jouer son rôle, y
compris sur le plan technique.

Pendant toute une époque la maîtrise d’ouvrage est restée dans l’ombre
parce que l’informatique interne des entreprises, qui jouait le rôle
de maître d’œuvre, campait sur une position de pouvoir
inexpugnable, fortifiée par le coût considérable des investissements
informatiques. C’était le maître d’œuvre qui décidait de tout
dans les projets de gestion, situation de l’ordre de la catastrophe,
parce qu’elle engendrait la frustration des utilisateurs, la rigidité de
l’organisation, l’incapacité à conduire des évolutions fonctionnelles
ou techniques.

Cette position de force des informaticiens internes a été peu à peu
érodée puis finalement ruinée par plusieurs mutations importantes
auxquelles ils n’ont en général pas su s’adapter : l’essor de la
micro-informatique et de l’informatique des utilisateurs, le
développement des progiciels de gestion intégrée, l’externalisation
des développements décidée par des directions générales excédées par
l’arrogance des informaticiens. Les services informatiques internes
ont aussi eu du mal à comprendre l’importance de phénomènes émergents
comme l’Internet, les logiciels libres, et les évolutions techniques
de manière générale, parce que leur culture informatique était souvent
défaillante et leur mobilité intellectuelle limitée.

C’est ainsi que certaines entreprises ont connu une véritable Bérézina
de l’informatique interne, qui a ouvert la voie à l’inversion de la
situation décrite ci-dessus, au profit de deux autres catastrophes au
choix : l’informatique pilotée directement par les utilisateurs, ou
l’absorption de la maîtrise d’œuvre par la maîtrise d’ouvrage. La
différence entre les deux cas est que l’informatique abandonnée aux
utilisateurs débouche sur l’anarchie et la pagaille totales, alors
que, s’il reste une maîtrise d’ouvrage centrale, il est possible de
conserver une certaine cohérence au système d’information de
l’entreprise. Mais dans les deux cas les développements sont
entièrement concédés à des prestataires qui, face à des clients
dépourvus de toute compétence technique, ne résistent pas longtemps à
la tentation d’en profiter, et il serait difficile de le leur
reprocher, dans un monde où chaque entreprise lutte pour sa survie.
Les résultats peuvent être mirifiques en termes de budgets. Un
consultant indépendant qui préfère rester anonyme m’a confié que les
entreprises et les services publics, en France, étaient les
principales victimes de ce genre de situation, et que les montants des
contrats qui leur étaient proposés étaient souvent triples de ce qui
était demandé à un client sérieux pour un travail comparable.

En bref, il faut pour réussir un projet une maîtrise d’ouvrage
consistante et décidée à faire son travail, c’est-à-dire à énoncer
l’objectif et à l’assumer. Énoncer l’objectif, c’est notamment rédiger
des documents « de vision », notes de trois pages au moins et dix
pages au plus qui expliquent en langage humain et sans détails
superflus ce que l’on veut. Ensuite il faut rédiger les scénarios qui
correspondent aux visions, et les jeux de tests qui permettront de les
valider. Puis il faut jouer les scénarios avec les équipes de
développement, les modifier et recommencer. Pour un gros projet c’est
un travail à plein temps, il va sans dire, et qui n’a rien à voir avec
des situations que j’ai observées, où le client vient en réunion de
projet proférer quelques caprices, de préférence incompatibles avec
ceux de la réunion précédente, et retourne à ses occupations
extérieures au projet.

Il faut aussi une maîtrise d’œuvre consistante, c’est-à-dire
suffisamment compétente sur le plan technique pour être un
interlocuteur critique des prestataires éventuels, et de la maîtrise
d’ouvrage. Un informaticien, m’a appris un jour un collègue, c’est
quelqu’un qui dit non. Cela ne rend pas forcément populaire, mais nous
retrouvons ici la notion de « fonctionnaire wéberien » mentionnée par
Cornelius Castoriadis ; il serait
également possible de remonter plus loin dans le temps, jusqu’à
Confucius, qui exigeait du conseiller qu’il donne
toujours au roi son meilleur conseil, fût-il désagréable au point de
déclencher la colère du souverain et la mise à mort du conseiller.

 Relations de travail informatiques

Une fois ces conseils approuvés, il reste à faire le travail. Tout ce que
nous avons écrit jusqu’ici concourt à établir l’idée que le travail de
développement ne peut être ni spécifié à l’avance avec une précision
suffisante, ni encadré par des méthodes tayloriennes. La conséquence
qui en découle est que, pour atteindre l’objectif, on ne pourra
compter que sur la motivation et la bonne volonté de l’équipe de
développement ! Cette conclusion pourra apparaître accablante aux
adeptes de la démarche qualité et de la conduite de projet, qui vont
m’en vouloir d’avoir au fil des pages critiqué leurs méthodes
favorites qui étaient censées éviter une telle extrémité. Mais est-il
choquant qu’un employeur ait à compter sur la motivation et la
bonne volonté de son personnel ?

Ce que je crois avoir établi au fil de ce livre, c’est que de toute
façon la démarche qualité ISO 9000 et la conduite de projet au sens
dur échouent à contrôler et à canaliser complètement le travail
de développement, parce qu’il est dans sa nature d’échapper au
contrôle et à la canalisation. Et tous les développements réussis que
j’ai connus l’ont été parce que les développeurs étaient motivés et de
bonne volonté.

Cela dit, tous ceux qui ont essayé de travailler avec des
informaticiens savent qu’obtenir ces conditions n’est pas facile, et
les maintenir dans le temps, encore moins.

Les informaticiens forment une corporation au sein de laquelle les
critères de reconnaissance mutuelle et de hiérarchie reposent sur la
compétence [6]. La corporation est subdivisée en obédiences identifiées par la technique de
référence, qui détermine l’axe selon lequel se mesure la compétence :
pour les experts de tel langage de programmation, ce sera la
virtuosité dans l’écriture de programmes complexes, pour les experts
de tel système d’exploitation ce sera la connaissance détaillée du
fonctionnement interne de ses parties les plus absconses, etc. Mais
tous ont tendance à faire front contre les managers dépourvus de
compétence particulière en informatique qui auraient la velléité de
les diriger. Et plus ils sont compétents plus ils adoptent cette
position frondeuse : à la limite, il faut se méfier des conciliants,
ils risquent d’être incompétents.

Face à des représentants de cette corporation informatique, comment
faire pour diriger leur activité spontanée vers le but fixé par leur
employeur ? Autant dire que le problème n’est pas
simple. Nous nous placerons dans le cas d’un travail salarié : le
développement de logiciel libre dans un contexte de volontariat et de
bénévolat est assez différent.

Pour qu’une équipe constituée de salariés du maître d’ouvrage ou d’un
sous-traitant produise un travail orienté vers un objectif cohérent,
nous admettrons qu’il faut un responsable de cet objectif. Le
problème à résoudre est celui de la façon dont le responsable va
conduire l’équipe vers l’objectif, et donc acquérir une certaine
autorité pour ce faire. On sait combien l’autorité est devenue
problématique dans notre société : elle l’est encore plus dans le
microcosme des informaticiens, qui se voient volontiers comme de
petits démiurges face à leur ordinateur et sont très ignorants des
conditions sociales et économiques de leur activité — ce pourquoi
nous avons schématiquement rappelées celles-ci lors d’un chapitre précédent.

Une première position envisageable est celle du responsable sorti des
rangs de la corporation, où il jouissait d’une position élevée sur
l’échelle de compétence. Il peut être tenté de rester le plus fort
dans son domaine pour asseoir son autorité sur sa compétence. C’est un
piège : diriger une équipe prend du temps qui n’est plus consacré à
l’activité technique. Les jeunes recrues ont appris en deux ans à
l’école ce que les plus vieux ont appris sur le tas, moins bien, en
dix ans. L’expérience a des avantages, mais pas pour tous les
problèmes, et lutter sur tous les fronts pour être meilleur que chacun
de ses collaborateurs dans tous les domaines est impossible. Bref,
très vite, pour rester le plus fort le manager va être amené à chasser
les bons éléments et à recruter des médiocres ou des pusillanimes.
Même ainsi, cette démarche le conduira à l’impasse, parce que pendant
qu’il s’épuisera en vain à courir une dizaine de lièvres techniques
à la fois, il ne fera pas sérieusement son travail de direction de
l’équipe et offrira bientôt l’image désolante du gourou vieillissant.

Cette critique du responsable qui veut rester supérieur à chaque
membre de son équipe dans chaque domaine technique ne doit surtout pas
être prise pour une approbation de la seconde position possible :
celle du responsable totalement incompétent sur le plan technique.
Disons le tout net, un responsable dépourvu de toute compétence et de
toute curiosité relatives au métier des membres d’une équipe de
développeurs de logiciel ne doit nourrir aucun espoir de la diriger un
jour. La position du responsable incompétent est possible au niveau
n+2, parce que là il a à superviser plusieurs équipes dans des
domaines variés et on ne peut pas humainement exiger de lui qu’il soit
un spécialiste de chacun, mais au niveau n+1 ce n’est pas
envisageable.

La bonne position sera donc entre ces deux extrêmes. Je serais tenté
de dire que le responsable d’une équipe technique doit être capable
d’être au moins un bon second pour chacun des membres de son équipe
dans un des domaines de spécialisation de celui-ci : disons que c’est
l’idée générale, pas une règle absolue. D’expérience, la plupart des
spécialistes ressentent positivement une situation où ils jouent le
rôle de mentor vis-à-vis de leur responsable, et où celui-ci reçoit
d’eux des compétences qu’il utilisera par la suite.

Le manager doit donc accepter de se présenter face à son équipe en
position d’infériorité du point de vue de la compétence technique, au
moins sur certains points : chaque membre de l’équipe connaît au moins
le domaine dont il s’occupe personnellement mieux que son chef, sinon
cela voudrait dire que chaque membre d’une équipe de n personnes ne
posséderait qu’une compétence moyenne égale à
1/n×(compétence du chef), ce qui serait
désolant (certains chefs constituent leur équipe ainsi, c’est bon pour
leur tranquillité personnelle mais pas pour la qualité de l’équipe).
Être le chef de gens plus compétents que vous sur certains points
demande un mélange savamment dosé d’humilité et
d’autorité et suppose qu’on leur apporte autre chose
que de la compétence technique : définition d’objectifs mobilisateurs,
capacité à défendre les projets de l’équipe devant les clients, la
direction et les autres départements, aptitude à obtenir des
financements et à remporter des appels d’offres, création de bonnes
conditions de travail pour les membres de l’équipe, talent pour
réaliser la synthèse des travaux du groupe. Comme le sait quiconque a
essayé, obtenir et conserver l’autorité nécessaire à
la direction d’un groupe est le résultat d’une transaction permanente,
surtout mais pas uniquement dans les conditions idéologiques
contemporaines (on pourra pour s’en convaincre consulter
l’autobiographie de Gengis Khan ou les ouvrages qui s’en sont
inspirés), et nul dans cet exercice n’est à l’abri de l’usure du
temps. Pour mieux comprendre ce sujet délicat on pourra lire avec
profit un texte bref mais incisif d’Hannah Arendt
 [7], où elle explique notamment que l’autorité
est un moyen d’obtenir l’obéissance qui se distingue à la fois du
recours à la contrainte, à la coercition, et de la persuasion par des
arguments.

Dans son essai de sociologie de ce milieu un peu
particulier [8], Philippe Breton a observé des équipes plus ou moins formellement dévolues à
l’assistance informatique aux utilisateurs, et il s’est intéressé à
l’attitude de ces informaticiens à l’égard de leurs « clients ». La
situation semble de prime abord assez différente de celle du
responsable d’équipe qui négocie l’établissement de son
autorité, mais l’observation de nombreuses occurrences
de ces deux types de relations tendrait à suggérer que les leçons de
l’une peuvent s’appliquer à l’autre ; après tout il s’agit dans les
deux cas d’obtenir qu’un expert veuille bien mettre à votre
disposition sa précieuse compétence, dans un rapport de force tel que
le recours à la contrainte aboutirait exactement à l’inverse du but
poursuivi.

Le résultat obtenu par les observations et analyses de Philippe Breton
consiste en ceci que les profanes en quête de conseil et d’assistance
auprès des informaticiens se répartissent de façon tranchée en deux
catégories : le type A et le type B. Appartiennent au type A les
personnes pour les problèmes desquels les informaticiens sont toujours
prêts à se mettre en quatre, à passer la nuit s’il le faut, à
contacter des collègues à l’autre bout de la planète pour obtenir la
variante rare de tel logiciel qui pourrait répondre à une question
délicate. Les personnes affublées du type B sont moins bien traitées :
leurs appels à l’aide sont toujours mis sous la pile des travaux en
attente, leurs problèmes se voient souvent gratifiés, après une longue
attente justifiée par une « étude technique » plus ou moins réelle, du
diagnostic « incurable », on n’hésite pas à les engager dans de
fausses pistes, leurs mésaventures informatiques déclenchent la joie
et la bonne humeur des informaticiens, les remarques narquoises ou
sarcastiques ne leur sont guère épargnées. Ma longue expérience
empirique corrobore tout à fait l’analyse de Philippe Breton. Bref, il
vaut mieux se débrouiller pour être du type A si on ne veut pas
endurer des moments très désagréables, d’autant plus que
l’appartenance à un type semble très stable et durable, très difficile
à inverser, et qu’il n’y a pratiquement pas de situation
intermédiaire. On imagine comment cette situation peut se transposer
aux relations entre un groupe d’experts et leur supérieur hiérarchique
(appelé également n+1 selon la nouvelle terminologie politiquement
correcte).

Quels sont les facteurs qui déterminent l’appartenance à un des
types ? Étant donnée la masculinité prononcée des équipes
informatiques, on pourrait penser qu’être une femme sachant jouer de
son charme suffit à conférer le type A : sans nier l’influence
fréquente de ce facteur, cela ne suffit pas à tout coup. Traiter les
gens comme des domestiques, les convoquer de façon impérieuse dans
votre bureau à l’heure qui vous arrange vous, leur rappeler à haute et
forte voix qu’ils sont payés pour vous rendre service, menacer de se
plaindre à leur chef ou à la direction et autres comportements du même
genre assurent par contre une inscription garantie au type B, et je
dois dire que c’est très fréquent. Mais restent beaucoup d’autres
exemples plus difficiles à analyser, et pour lesquels Philippe
Breton dit qu’il n’existe pas d’explication
simple, mais une nébuleuse de facteurs objectifs et subjectifs.

Une fois écartées les questions de courtoisie élémentaire, qui
condamnent d’emblée une population importante au type B, il semble que
les conditions d’accès au type A tournent autour de deux attitudes :

  1. manifester le plus clairement possible que l’on respecte le
    travail des informaticiens et que l’on ne sous-estime pas ses
    difficultés ;
  2. prouver qu’avant de demander de l’aide on a fait des efforts,
    dans les limites de ses propres compétences, pour trouver soi-même
    la réponse à la question par la lecture des documentations et par
    des essais menés de façon assez systématique.

D’après mes observations personnelles, les attitudes décrites
ci-dessus, et notamment l’ampleur des punitions infligées au type B,
sont modulées selon que les informaticiens de l’équipe d’assistance
ont des emplois de statut stable ou précaire, sont soumis à une
domination plus ou moins facile à esquiver. Si l’assistance technique
est assurée par une entreprise extérieure qui facture ses
interventions, le niveau de courtoisie des demandes qui lui sont
adressées est bien meilleur que dans le cas d’une équipe interne, et
la satisfaction de toutes les parties est supérieure. Il semble que ce
type d’activité soit tout désigné pour l’externalisation : la demande
potentielle d’assistance est infinie, si la prestation est gratuite
elle ne sera jamais jugée satisfaisante, lui conférer un coût assainit
la situation.

Philippe Breton n’a à ma connaissance pas
consacré d’analyse aussi systématique aux relations entre les équipes
informatiques et leurs chefs, mais son livre contient beaucoup de
notations éclairantes sur ce sujet, et je crois que sa typologie des
utilisateurs est pertinente là aussi, moyennant quelques adaptations.
Si l’équipe informatique est interne à l’entreprise, le chef de type B
aura tout le mal du monde à obtenir quelque résultat, et passer son
temps à licencier les gens qui ne font pas leur travail ne fait pas
avancer la réalisation. Si l’équipe est externe, toutes les demandes
seront bien sûr acceptées avec le sourire et facturées au prix fort,
sans que ce soit une garantie de bonne fin, du fait des procédures
d’esquive que nous avons déjà évoquées.

 À quoi les informaticiens passent-ils leur temps ?

Nous l’avons déjà souligné, les informaticiens ont souvent de
meilleures relations avec les ordinateurs qu’avec les humains,
spécialement lorsque les humains en question sont leurs collègues de
travail, et plus particulièrement s’ils sont à quelque titre ceux qui
leur demandent un travail. Essayer de combler ce fossé
d’incompréhension est une tâche immense à laquelle ce livre s’efforce
de contribuer. Nous avons déjà insisté sur l’importance qu’il y avait
à reconnaître la difficulté et la complexité du travail informatique,
et pour ce faire l’interlocuteur régulier d’informaticiens ne perdra
pas son temps en se documentant sur la question par la lecture
d’ouvrages tels que celui-ci ou ceux qui figurent dans la bibliographie,
ou, mieux encore, en pratiquant lui-même la programmation en amateur,
exercice qui lui procurera, outre un certain plaisir, une compréhension
accrue de toutes sortes de questions qui surgissent dans les conversations
avec ses interlocuteurs techniques.

Un trait de comportement des informaticiens qui suscite souvent
l’incompréhension de leurs interlocuteurs, c’est leur emploi du temps.
Il est généralement impossible à un profane d’estimer la complexité
d’un travail informatique quelconque, qu’il s’agisse de maintenance,
de paramétrage ou surtout de développement, et partant le temps
nécessaire à son accomplissement. La règle est que le profane
sous-estime les délais, et ne comprend pas que le travail demandé ne
soit pas réalisé immédiatement. À une certaine époque l’informatique a
fait irruption dans la recherche en biologie moléculaire sous la forme
de l’analyse de séquences [9], une activité
au demeurant mal définie, mais ce qui est sûr c’est qu’au début des
années 1990 le chercheur moyen pensait qu’il lui suffisait de donner
la disquette où était enregistrée sa séquence à un bioinformaticien
pour avoir le résultat vingt minutes plus tard, alors que le travail
réel demandait plutôt trois semaines, et surtout une discussion
approfondie sur le type d’analyse attendue. Cette divergence de vue
conduisait droit au malentendu. Nul doute que si le chercheur s’était
un peu donné la peine de voir lui-même de quoi il retournait, il
aurait mieux compris pourquoi une telle attitude le condamnait à un
classement direct en type B, et comment l’éviter.

Une autre chose semble difficile à comprendre : la maîtrise d’outils
complexes, tels que système d’exploitation, environnement de
développement, langage, compilateur, éditeur, compte pour beaucoup
dans la compétence d’un informaticien. Il est donc légitime qu’il
consacre beaucoup de temps à se perfectionner dans leur usage, à se
tenir au courant de leur évolution et de l’apparition de nouveautés,
à en parler avec des collègues. D’où la question que l’on devine souvent
au bord des lèvres de certains interlocuteurs : « Mais qu’est-ce qu’il
fabrique au lieu de s’occuper de mon problème ? ». De même que pour
construire un mur il faut d’abord construire un bon échafaudage, la
construction d’un système informatique demande la préparation d’outils
adéquats, et éventuellement leur apprentissage, ce qui prend du temps.
Le travail du développeur consiste pour une part à être à l’aise en
permanence au milieu de ses outils.

 Laconiques leçons de l’expérience

J’ai posé à un certain nombre de responsables d’équipes de
développeurs, certaines de grande dimension, la question suivante :
comment obtient-on que les gens travaillent, et non seulement qu’ils
travaillent, mais que le résultat soit ce qui leur était demandé au
départ ? Les réponses, dont nous donnerons le résumé ci-dessous, sont
assez convergentes.

  1. Avant toute chose, il faut être très attentif lors du
    recrutement. Le candidat doit rencontrer au moins une personne très
    compétente et expérimentée dans son domaine technique, qui saura
    détecter s’il possède réellement les compétences qu’il prétend avoir
    et s’il est capable de les mettre en œuvre : l’informatique est
    en effet un domaine où l’exhibition d’un vocabulaire à la mode fait
    souvent illusion. Il faut aussi évaluer la personnalité du candidat,
    et vérifier pendant la période d’essai son aptitude à travailler
    avec l’équipe à laquelle il est destiné. Les gourous géniaux
    mais irréductiblement individualistes ne sont pas forcément à leur
    place dans une équipe en entreprise. Curieusement, beaucoup de
    candidats à un recrutement avouent finalement assez ouvertement leur
    peu de goût pour le travail : autant amener ce sujet dans la
    conversation et écouter les réactions.

    Pour cette question du recrutement, on consultera avec profit le site de Joel Spolsky, et plus précisément son article Finding Great Developpers.

  2. Pour recruter des spécialistes techniquement compétents,
    tels que développeurs ou ingénieurs systèmes et réseau, il
    faut éviter de diluer le message et de se tromper de cible. Il faut
    d’abord écarter tout risque de confusion avec les populations
    des pseudo-experts en génie logiciel déjà signalés plus haut et des aspirants chefs de projet : sachez que
    si les deux premières lignes de votre annonce comportent des
    locutions telles que « schéma directeur », « conduite de projet »,
    « démarche qualité », tous les vrais experts techniques seront
    déjà passés à l’annonce suivante, parce qu’ils savent que dans
    un tel contexte ils vont passer leurs journées en réunions
    mortelles au lieu de faire ce qui les intéresse : construire
    des systèmes informatiques. La mention d’une compétence
    relative à un logiciel d’application tel que SAP pourra attirer
    des candidats versés dans les systèmes financiers, mais écartera
    à coup sûr les vrais développeurs. Pour attirer un vrai développeur,
    il faut être un tant soit peu de la partie, parler son langage.
  3. Une fois l’équipe constituée, il faut entretenir son élan et sa
    motivation. Tous les avis convergent pour dire qu’un rôle très
    important est joué par la conscience d’une communauté de destin
    entre chaque membre de l’équipe et l’entreprise : si le projet
    échoue l’entreprise peut disparaître, ou du moins l’équipe. Cette
    conscience est évidemment plus facile à susciter dans une petite
    entreprise que dans la fonction publique. Le rôle d’entraînement des
    responsables et la confiance qu’ils inspirent sont aussi très
    importants.

Voilà, il n’y a pas de recette miraculeuse, uniquement des
connaissances que les meneurs des groupes de chasseurs du
paléolithique supérieur possédaient déjà. Ce qui ne veut
pas dire que tout le monde les possède, ni que ce soit facile
de les mettre en application.

© copyright Éditions Vuibert & Laurent Bloch 2004, 2005

Page d’accueil de ce livre

Notes :

[1Laurent Bloch et alii. Rapport d’activité du Service d’Informatique Scientifique. Institut Pasteur, 17 novembre 1998. http://www.pasteur.fr/recherche/uni....

[2Je propose la traduction appliquette, ou applète.

[3Résumé d’une communication de Jean-Marie Faure au Club des Maîtres d’Ouvrage.

[4Frederick P. Brooks, Jr. The Mythical Man-Month (traduction : Le mythe de l’homme-mois). Addison-Wesley (Vuibert pour la traduction), Reading, Massachusetts (Paris), 1975-1995.

[5Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams. L’eXtreme Programming. Eyrolles, Paris, 2002.

[6Il faudrait mentionner ici le clivage, typiquement franco-français, entre le milieu des chercheurs patentés et celui des ingénieurs et techniciens, qui communiquent peu entre eux et se vouent une certaine méfiance mutuelle d’où le mépris n’est pas toujours absent, mais nous parlerons peu ici des chercheurs.

[7Hannah Arendt, La crise de la culture, huit exercices de pensée politique, chapitre Qu’est-ce que l’autorité ? Gallimard, Paris, [1972] 1989.

[8Philippe Breton, La tribu informatique — Enquête sur une passion moderne, Métailié, Paris, 1991.

[9Les séquences biologiques décrivent des macro-molécules de trois sortes, les protéines, les molécules d’ADN et les molécules d’ARN. Chacune de ces molécules est constituée par l’assemblage en séquence d’éléments de base pris parmi les acides aminés, au nombre de 20, pour les protéines, ou parmi les acides nucléiques, au nombre de 4, pour l’ADN et l’ARN. La succession de ces éléments, considérés comme les caractères d’un alphabet, peut être vue comme un texte, étonnamment bien conservé par l’évolution, dont l’analyse est au cœur de la biologie moléculaire contemporaine.

Forum
Répondre à cet article
Comment travailler avec des informaticiens ? De l’externalisation des équipes de maintenance
Marc - le 21 février 2008

Bonjour,

J’ ai lu avec intéret votre article, dans lequel vous exprimez certains points tres pertinents sur les équipes de maintenance. Informaticiens cloisonnés, demandes infinies, tout cela peut plaider pour une externalisation de ce service maintenance considéré comme ingrat. Sauf si ...
Sauf si on le valorise, tant aux yeux de ceux qui le font (les techniciens) que dans son rôle vis à vis des personnels. Voici quelques leçons positives que j’ ai pu tirer de la coordination de l’ équipe de maintenance , équipe qui fait partie du service informatique de mon établissement.

1 - Les techniciens informatiques(comme tous) sont plus motivés lorsqu’ on les responsabilise. Nous leur avons affecté à chacun des services dont ils deviennent les interlocuteurs techniques privilégiés. Sorte de "référents", ils "gèrent leur petite entreprise", en intervenant à la fois sur des problèmes techniques, mais aussi sur la pertinence des demandes de matériel. Des liens très bons se sont tissés entre ces "techniciens référents" et leur service. Les problèmes résiduels peuvent être résolus par le responsable de l’ équipe.

2 - Ces "techniciens référents" sont aussi des liens entre les ingénieurs du service informatique et les personnels des services dans lesquels ils interviennent. En permettant aux deux bouts de la chaine de communiquer sur des problemes réseau, applicatifs,messagerie, spam et autre, ils jouent un peu le rôle pivot que peut avoir le "médecin généraliste" dans le parcours de santé, face aux spécialistes . Ils facilitent grandement la communication entre les ingénieurs du service informatique et les personnels et "déminent" parfois les conflits qui peuvent survenir.

3 - Ils savent évaluer les besoins en formation des personnels chez qui ils interviennent et peuvent ainsi participer à apporter certaines réponses. Des membres de l’ équipe maintenance ont organisé certaines formations - bien perçues -(et vont encore le faire) . Il est vraiment intéressant que les personnels voient aussi les membres de leur équipe maintenance de ce côté-là.

4 - Pour éviter une hausse infinie de la demande, risque réel de notre métier dont vous parliez, nous mettons en place un système de "régulation interne" dont les premiers résultats bien que partiels sont encourageants.Face à notre technicien, dans chaque service on [l’ administration et nous] a mis en place un correspondant informatique. Il s’ agit parfois du chef de service lui-même, parfois d’ une autre personne DU SERVICE à qui il délègue cette mission : suivre côté service les demandes de maintenance, les commandes de matériels , évaluer ce qui est prioritaire par rapport à ce qui l’est moins en termes de besoins. Il a un rôle de relance et de suivi vis à vis de nous, mais aussi d’ arbitrage en interne, ce qui permet de déporter une partie des conflits dont vous parliez vers l’ INTERIEUR du service : "Ta demande d’ écran 21 pouces n’est pas raisonnable", "telle demande d’ intervention est plus prioritaire pour notre service que telle autre."

Bien souvent les demandes extremes qui engendrent les réactions "de type B" sont le fait de QUELQUES personnes dont les comportements se retrouvent dans des domaines autres que l’ informatique... Il faut mettre en évidence ces comportements et les "canaliser" en amont - pour les faire traiter autant que possible par leur service d’ origine.

DE LA MAINTENANCE A l’ INFORMATIQUE DE PROXIMITE

Je pense qu’ il faut repenser le terme de "maintenance" ou de "support" et lui substituer le terme d’ "informatique de proximité". Les techniciens "interlocuteurs" de chaque service doivent avoir à mon sens plusieurs cordes : être de bons spécialistes techniques de la maintenance et de la gestion du parc, mais aussi de "bons généralistes" de tout le reste de l’ informatique. Ils doivent aussi être à même de former , de conseiller, de communiquer.
En prenant en charge de bout en bout ce qui concerne l’ informatique utilisateur (de la gestion de parc à l’ assistance et à la formation), on forme un vrai corps de métier avec des compétences professionnelles propres.

UN PERSONNEL SELECTIONNE

Comment sélectionner les membres d’ une telle équipe ? Seraient-ce des moutons à 5 pattes ? Non. Cependant le choix ne doit pas être fait n’ importe comment.
Il s’ articule autour de certains critères :
- Compétences techniques dans la maintenance et la gestion de parc et capacité à les faire évoluer
- Ouverture d’esprit (Beaucoup de nos techniciens sont d’ anciens personnels:secrétaires, techniques) qui se sont passionnés pour l’ informatique et ont pu acquérir un niveau et une culture informatique solides Leur "double casquette" est une vraie force dans notre perception des besoins utilisateurs. Elle permet de parler les 2 langages. D’ autres membres de l’ équipe sont des informaticiens de formation mais la sensibilité aux besoins utilisateurs est la règle... Ici on doit pouvoir dialoguer avec des personnes autant qu’ avec sa machine, pour reprendre votre expression.
- Bonne capacité de travail,
- sens des priorités pour évaluer ce qui est essentiel de ce qui peut attendre un peu (pas trop)
- Esprit d’ équipe car des échanges de compétences se font en permanence entre les techniciens, qui n’ hésitent pas à s’ entraider.

Il faut donc des personnes motivées, curieuses et qui veulent progresser. En clair, cette équipe ne doit pas être la décharge ou l’ on cantonne les "canards boiteux" du service, en se disant qu’ "ils ne peuvent pas faire autre chose". C’est une vraie spécialisation, comme l’est la "médecine d’ urgence" et devrait l’ être la médecine générale. C’est alors qu’ elle trouvera sa valeur auprès des utilisateurs, et qu’ elle attirera des vocations. Notre expérience , dans notre université, a été très positive. Nos personnels sont tellement appréciés que l’ équipe réseau et l’ équipe gestion leur a délégué des tâches supplémentaires, en restant dans la logique du "poste client" qui est la nôtre.

CONCLUSION
Il y a bien sur des choses a améliorer, mais les choses vont dans le bon sens notamment la diminution des problèmes dont vous parliez. Nous avons quelques idées pour rendre l’ assistance aux utilisateurs - aide à l’ utilisation de l’ outil informatique - plus efficace. Nous mettons en place de nouveaux outils pour améliorer notre gestion de parc informatique.

Je pense que le fait de centrer une des équipes du service informatique autour de l’ utilisateur au sens large (maintenance de son poste, d’ assistance, de formation) peut constituer une alternative rationnelle et efficace à une externalisation de la maintenance. Cela améliore la perception de l’ informatique en interne. Le tout est de veiller sur la qualité de ses membres et de lui donner les moyens de fonctionner efficacement.
La "maintenance" ainsi requalifiée passera du statut de parent pauvre à celui d’ une spécialité comme les autres .



pucePlan du site puceContact puceMentions légales puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.86.44