Skip to content

Support + Projet (= Su-jet ?)

26/02/2013

(le titre ne veut rien dire, je sollicite votre indulgence)

L’équipe technique devant la BU Santé – Photo FlickR de Patrick Briggs – Stormtroopers — CC-BY-2.0

Une discussion début janvier avec Got m’a éclairé sur certaines difficultés que je peux rencontrer régulièrement dans mes activités au SCD de Nice. La société pour laquelle il travaille, Antidot, décompose ses activités auprès des clients en 2 équipes distinctes : Projet et Support — comme toutes les sociétés, je pense.

  • L’équipe Projet est là pour amener le client à l’utilisation courante des outils vendus. Une fois le client en fonctionnement normal, elle passe ensuite complètement la main.
  • L’équipe Support vient alors prendre le relai pour répondre aux sollicitations du client, en cas de difficultés, d’insatisfactions, de bugs, de plantages, etc.

La logique étant que, si ces deux équipes oeuvrent sur les mêmes outils, et doivent donc les connaître parfaitement, leur travail n’est pas du tout le même. Notamment — et je cite Got, merci à lui pour m’avoir ainsi éclairé sur une chose qui paraîtra évidente à beaucoup — la périodicité et les phases de stress n’ont rien à voir.

Pour l’équipe Projet, l’activité annuelle ressemble à ceci :

stress equipe projet

Alors que l’équipe Support vivait plutôt sur ce rythme-là :

stress equipe support

Tous les SCD que je connais ont un service qui s’apparente à un département informatique, avec des compétences plus ou moins étendues : il intègre généralement la docélec (ou pas), la maintenance matérielle du parc, la gestion des logiciels (à commencer par le SIGB) et des serveurs, etc. Bibnum à Angers et Clermont-Ferrand, Cellule informatique à Paris 6, Système d’information documentaire à Caen, Sidoc (qui veut dire la même chose) à Nice.

Et j’ai tendance à croire que tous ces établissements, à l’image du nôtre, gèrent à la fois les projets (quand il y a une part technique, informatique) et le support (tout problème rencontré en section ou par un lecteur relatif aux outils utilisés).

Les dossiers en mode Projet se gèrent en semaines et en mois, avec une planification anticipée (pléonasme ?) de la charge de travail et des périodes d’intensité.

Les tâches en mode Support se gèrent dans la journée ou dans la semaine, en s’appuyant autant que possible sur des procédures déjà en place (donc, logiquement, sans improvisation sauf en cas de difficulté inédite : heureusement ce sont souvent les mêmes problèmes qui reviennent).

Je constate au moins deux conséquences problématiques à cette double fonction :

  • Du côté de l’équipe Support + Projet : une certaine difficulté à gérer les deux casquettes, avec la nécessité de mener des projets sur le long terme et la possibilité statistique d’être interrompu à tout moment pour une urgence (urgence concernant un collègue ou un lecteur, ou tout le réseau)
    Si bien que leur rythme peut ressembler à ça
    stress equipe support projet
    à quoi s’ajoute le sentiment de ne faire bien ni l’un ni l’autre, puisque ne bénéficiant ni de disponibilité complète nécessaire à l’action support, ni de la concentration utile à la gestion des projets.
  • Du côté des collègues en section : la fonction Support les habitue à ce que l’équipe réagisse rapidement avec des solutions immédiates. Donc il peut arriver qu’ils viennent avec un problème qui, pour eux, relève du support — sauf qu’après une analyse plus ou moins longue, l’équipe technique l’identifie comme relevant du projet (nouveau service et/ou nouveau circuit et/ou nouveau problème).
    Donc nécessité de temporisation, de prendre le temps de l’analyse, etc. — ce qui peut ne pas être compris

Par ailleurs, cette organisation où des « techniciens » (quels que soient leurs grades et statuts) traitent l’ensemble de la chaîne, de l’analyse des besoins au fonctionnement courant en passant par la montée en charge, n’est que l’héritage d’une époque pas si lointaine ou les questions informatiques étaient une excroissance des activités de la bibliothèque.

Aujourd’hui, sans être forcément le coeur de ces activités (après tout, on doit rester conscient qu’on ne parle là que d’outils), il y a eu comme la passage à une ère « industrielle » de l’informatique en bibliothèque, avec des cadences et des exigences différentes, qui du coup nécessitent une conception complètement différente de l’organisation — peut-être plus « industrielle » elle aussi.

Avez-vous dans vos établissements la même (con)fusion ? Avez-vous distingué les deux fonctions ? Ou trouvez-vous au contraire que c’est une richesse que d’avoir les deux casquettes (diversité du quotidien) ?

Observez-vous les problèmes que j’évoque (ou d’autres) ? Et coment essayez-vous de les résoudre ?

4 commentaires
  1. Antoine TERTOIS permalink
    28/02/2013 12:25

    Actuellement, je suis en support avec des phases de projet. Dans mon ancien poste, j’étais projet avec des phases de support.
    Support et Projet devraient être distinctd mais les frontières entre les 2 sont toujours un peu flou.
    La partie projet gagne de l’expertise sur certains domaines qui fait d’elle l’interlocuteur privilégié pour résoudre des incident que le support ne sait pas traiter. Et le support, à force de traiter les même incidents ou à gérer les mêmes environnements, sait très bien gérer des bouts de projet quand le temps presse.

  2. 01/03/2013 11:54

    Parmi les bibliothèques qui sont organisées de la sorte (support / projet), et les autres, y en a t il qui utilisent un système de tickets d’incidents (type mantis, helpdesk, etc). Nous non, mais je ne sais pas si cela pourrait nous aider ?

  3. 01/03/2013 12:39

    Nous l’avons mis en place pour certains types de problèmes (liés à la reprographie : suite à des problèmes répétés, le helpdesk était à la fois un outil de suivi et un outil statistique pour ensuite se plaindre au fournisseur).
    L’utilisation d’un helpdesk pose des problèmes à la fois d’utilisation (si on demande à beaucoup de gens de l’utiliser, il faut les accompagner dans la maîtrise de l’outil — et risquer qu’ils ne fassent du coup jamais rien remonter) et de culture (sentiment de « barrière »).
    Mais c’est effectivement une piste.

Trackbacks

  1. Croiser des statistiques : l’enjeu des URI | Bibliothèques [reloaded]

Les commentaires sont fermés.

%d blogueurs aiment cette page :