1L'objet de cette contribution est d'apporter un éclairage et un retour d'expérience sur les méthodes de développement logiciel dites agiles, un ensemble de pratiques managériales destinées à organiser le développement applicatif d’une façon plus pragmatique, plus efficace et plus réactive aux besoins des utilisateurs que les méthodes antérieures. Si différentes méthodes agiles coexistent sur le marché des services informatiques, une « doctrine » énonçant leurs objectifs et leurs principes communs a été formalisée en 2001 et publiée sous la forme d’un manifeste. Depuis quelques années, ces méthodes gagnent le monde des bibliothèques, dans des contextes et pour des produits logiciels variés. L’agilité est à la mode dans notre communauté professionnelle. Elle y est souvent présentée comme un accélérateur de l’innovation documentaire. On en parle beaucoup, mais pas toujours à bon escient, ou sans toujours bien évaluer son potentiel ni ses limites dans le contexte particulier des missions et des organisations propres aux bibliothèques.

2Mon témoignage ne prétend pas épuiser la littérature professionnelle sur le sujet, ni généraliser abusivement des observations personnelles réalisées sur un terrain atypique dans le paysage des bibliothèques, celui de la BnF. Si des équipes et des fonctions dédiées à l’informatique documentaire ou intrinsèquement liées à son administration se sont fortement développées dans les organigrammes de la plupart des services documentaires ces dernières années, la majorité d’entre eux doivent néanmoins composer avec les services informatiques et les marchés publics de leur université ou de leur collectivité territoriale. Ils abordent d’abord le développement informatique comme l’achat d’un produit ou d’une prestation de développement auprès d’une société de services. La BnF dispose, quant à elle, d'un département d’une centaine d’informaticiens entièrement dédiés aux besoins de la bibliothèque. Elle s'appuie en outre sur des marchés de prestations informatiques conséquents pour lesquels elle est en mesure de porter auprès des prestataires des exigences méthodologiques qu’il serait peut-être plus difficile de défendre depuis un établissement plus modeste. Ces ressources et ce positionnement lui confèrent une capacité d’organisation du développement importante et relativement autonome, à la mesure des missions nationales qu’elle assume, que l’on pense à la bibliothèque numérique Gallica, au système de préservation numérique, Système de préservation et d'archivage réparti (SPAR), ou au dépôt légal du Web.

3Mon regard sur la méthode agile à la mode de la BnF est forcément biaisé ou situé. C’est celui d'un directeur de département « métier » (le département de l’Information bibliographique et numérique, en charge de la coordination des catalogues et des métadonnées). J’ai vu cette méthode se développer dans la BnF à une certaine distance, presque macroéconomique, et en résonance avec mes propres préoccupations managériales, centrées sur la construction d’organisations de travail apprenantes, capables de gérer des cycles complets d’innovation numérique, depuis l’invention de fonctions nouvelles jusqu’à leur mise en exploitation courante dans des circuits souvent lourds et complexes. Mon expérience de l’agilité s’est ainsi faite dans des domaines très innovants, souvent pionniers : l'archivage du Web et l’introduction des technologies du Web sémantique dans la gestion des catalogues (projet data.bnf.fr) pour ne citer que ces deux exemples. Le témoignage d’un acteur de première main, au sein du département des systèmes d’information (DSI) de la BnF, ou qui aurait fait l’expérience de cette méthode pour des réalisations logicielles plus classiques, serait sans doute différent.

Une méthode pour le développement logiciel en bibliothèque : pour quoi faire ?

4Il n'est plus guère de projet ou d'activité documentaire qui puisse se dispenser, en son centre ou dans les périphéries de son outillage, d'une réflexion globale sur l'organisation du développement logiciel. Depuis le début de l'informatisation des SIGB dans les années 1980, toutes les activités, même celles qui semblaient les plus à même de s'affranchir encore un peu de la technique, ont désormais besoin de logiciels, ou l'opportunité d'en tirer des bénéfices, qu'il s'agisse de gains de productivité ou de qualité de service. Les SID de nouvelle génération, qui prolongent et étendent le rôle historique, quasiment matriciel, des SIGB dans l'organisation du travail (acquisitions, signalement et diffusion des ressources au premier chef) sont bien sûr le cœur de réacteur de la bibliothèque et son principal point d'attention en matière de développement. Mais il faut aussi des logiciels et des applications pour gérer, le cas échéant, les processus de magasinage, de gestion électronique de documents (GED) ou de numérisation, les plannings des agents, les ressources budgétaires et humaines, les communications internes et externes, l'évaluation de la fréquentation et des usages, la médiation en ligne, la formation, les services aux chercheurs… Bref, dans une bibliothèque moderne, il y a ou il faut une application pour (presque) tout.

5Si la tendance est clairement à l'externalisation d'un nombre croissant de fonctions et de services d'informatique documentaire (utilisation de logiciels non spécifiques aux bibliothèques et disponibles en ligne, stockage et administration dans le nuage plutôt que sur des serveurs locaux, notamment), il n'en reste pas moins que les personnels manient et doivent faire évoluer un nombre croissant d’outils ou de produits logiciels. Ces derniers jouent un rôle crucial aussi bien dans la gestion des collections et des équipements que dans la relation aux usagers. Faire fonctionner mais surtout faire évoluer ce qu’on pourrait qualifier de parc ou de suite logicielle de la bibliothèque constitue désormais un enjeu d'organisation et de management à part entière : l’attractivité et la compétitivité de la bibliothèque dans un environnement devenu extrêmement concurrentiel en dépendent.

6Quels types de problèmes faut-il résoudre ? Nombreux sont les établissements qui se retrouvent périodiquement dans des situations ubuesques et coûteuses parce qu'ils se sont rendus tributaires d'un outil, d'un processus ou d'un prestataire qui leur coûte plus qu'il ne leur rapporte, qui ne répond pas ou plus aux besoins pour lesquels on l'avait initialement désiré. Nous disposons désormais d'assez de recul et d'expérience (pas toujours très heureuse) pour penser l'outil informatique au-delà de son acquisition initiale, et dans sa relation avec d’autres outils. Nous connaissons les problématiques de maintenance, de dépendance, d'évolution et de renouvellement des logiciels. Nous savons que dans ce domaine, plus encore que dans d'autres, anticiper le fonctionnement, l'amortissement et l'obsolescence dès l'investissement est primordial. Nous savons enfin que ceux qui conçoivent ou introduisent un nouveau produit sont rarement ceux qui l'utiliseront et le feront fonctionner sur la durée, que toute innovation (conçue généralement en mode projet) précède une phase d'exploitation (en mode production ou administration) sur une durée normalement plus longue.

7D'une part, les applications ont pris une telle importance dans notre quotidien et la réalisation de nos missions qu'elles méritent qu'on investisse du temps et de la réflexion dans la problématique générale qu'elles soulèvent du point de vue du management et de l'organisation du travail, plutôt que de traiter le problème au cas par cas et à la petite semaine. D'autre part, et puisqu'il y a des applications pour (presque) tout, mais qu'elles ont rarement le même cycle de vie, il est clair qu'un établissement doit désormais penser le développement logiciel non plus comme un besoin périodique ou ponctuel, mais comme une fonction permanente qui doit pouvoir être administrée structurellement, sinon culturellement, dans l'organisation même de la bibliothèque.

8Mais comment inscrire le développement applicatif de manière pérenne dans l’organisation du travail des bibliothèques, qui, historiquement, n’ont pas du tout été conçues ni organisées pour cela ? Cela soulève notamment des questions de métier et de statut : est-ce seulement l’affaire d’informaticiens recrutés par la bibliothèque ? Comment les bibliothécaires peuvent-ils intervenir dans les processus de conception et de réalisation ? Avec quelles compétences et selon quelles responsabilités ? Quelles interactions faut-il mettre en place entre les métiers qui concourent au développement, et avec quels – outils de management ? Pour le manager – directeur d'établissement, encadrant intermédiaire ou tout autre cadre sur qui porte la responsabilité des outils, la question principale soulevée ici est donc : quelle organisation est la plus à même de gérer les risques et réduire les coûts informatiques et humains du développement applicatif tout en répondant au mieux aux attentes des utilisateurs ?

Principes et engagements de la méthode agile

9Comment la BnF, connue pour ses pesanteurs, en est-elle arrivée à s’intéresser à la méthode agile ? Ce choix résulte de la convergence de plusieurs facteurs qui se sont accentués ces dernières années. La BnF, comme d’autres établissements, a connu dans son histoire, et à grande échelle, les limites et les lourdeurs des cycles de développement logiciels incrémentaux dits « en cascade »1 ou « cycle en V »2. Elle a donc cherché à pallier ces difficultés en travaillant autrement. Cette réflexion n’était pas neuve mais le besoin de nouvelles approches s’est fait sentir de façon plus pressante au milieu des années 2000 sous la pression d’une réalité de plus en plus difficile. La demande métier de développement au sein de la Bnf a connu de tels pics, et suscité des compétitions et des arbitrages si tendus qu’elle est progressivement apparue comme un enjeu totalement stratégique pour le pilotage de l’établissement. Cette prise de conscience est devenue encore plus forte dans le contexte concomitant de forte croissance de la bibliothèque numérique et de réduction des budgets et des ressources humaines. Le nombre et la diversité d'acteurs internes et externes intervenant dans le développement logiciel de l’établissement sont aussi devenus beaucoup plus importants, impliquant finalement d’envisager, sinon une remise à plat complète, au moins une réflexion méthodologique sur la répartition des rôles et sur les interactions entre bibliothécaires et informaticiens.

10Ce sont les réflexions engagées à ce sujet par le DSI de la BnF qui l'ont conduit à proposer l’adoption de la méthode agile pour encadrer ses développements, d'abord à titre expérimental, sur quelques projets pilotes, puis, à la lumière des progrès constatés, de manière quasiment systématique. La démarche a nécessité d’importants efforts de formation initiale mais, en assez peu de temps finalement, les équipes ont intégré le changement car les bénéfices en sont très vite apparus à tous les acteurs. Dans le prolongement de ces formations, un accompagnement régulier a été assuré afin que les personnels s’approprient les principes agiles sur la durée. La méthode agile retenue par la BnF s'appelle Scrum. Cette méthode vise fondamentalement à optimiser l'organisation du développement au regard d’un besoin désormais permanent et multiforme : placer la technique au service des utilisateurs, et non l'inverse.

11Ces valeurs sont déclinées dans le Manifeste agile en douze principes qui vont façonner la conduite du développement au quotidien et sur la durée. C’est le respect de l’ensemble de ces principes dans l’organisation du travail qui conduit à qualifier ou homologuer une méthode comme « agile ».

La méthode agile au quotidien : acteurs, instances, outils

Les acteurs du projet

12Dans les méthodes de développement traditionnelles, on distingue généralement le profil de l’expert fonctionnel ou de l’analyste (chargé de traduire en besoins et spécifications intelligibles par le programmeur les demandes exprimées par les utilisateurs métier) du profil du programmeur (chargé de la rédaction du code logiciel). En méthode agile, si ces dominantes demeurent (le premier audite et définit le besoin, le « quoi ? », le second établit la solution, le « comment ? »), la communication entre les deux est renforcée. Ce rapprochement vise à impliquer davantage le programmeur dans la finalité métier du produit qu’il développe et à faire en sorte que l’analyste soit de son côté au plus près des implications techniques de réalisation du développement, notamment en termes d’évaluation des coûts. Le nombre d’analystes et de développeurs varie avec l’importance et les moyens du projet. À la BnF, ce principe se traduit surtout par une plus grande participation des développeurs aux échanges avec les utilisateurs alors qu’ils avaient jusque-là tendance à être cantonnés dans une place plus solitaire du back office.

13Au côté de cette équipe issue des métiers de l’informatique, la méthode agile préconise la présence quasiment permanente d’un ou plusieurs représentants des utilisateurs – en l’occurrence, un ou plusieurs bibliothécaires. L’un d’eux a la responsabilité et la légitimité officielle (il est désigné formellement dans cette fonction par son encadrement) de représenter les intérêts des utilisateurs (professionnels ou finaux) de l’application à développer. Cette fonction de « chef de produit »* (product owner) est différente de ce qu’on entend habituellement par « chef de projet ». En effet, tout projet a un début et une fin, tandis qu’une application doit continuer de vivre, d’être maintenue et d’évoluer après la phase initiale de conception et la mise en production des premières versions. Un chef de produit a donc une « durée de vie » plus longue qu’un chef de projet, et dans tous les cas, sa fonction doit perdurer. Compte tenu de la forte implication requise pour ce chef de produit au sein de l’équipe de développement, il importe de ne pas sous-estimer la quotité de travail requise pour le bibliothécaire désigné pour jouer ce rôle. Pour de grosses applications, c’est quasiment un temps plein qu’il faut pouvoir consacrer à cette tâche. À la BnF, on peut considérer que le rôle de chef de produit, généralement occupé par un conservateur, est en passe de devenir un profil de poste à part entière. Cela soulève des questions intéressantes de reformulation des fiches de poste, de positionnement dans l’organigramme, mais aussi de reconnaissance. En effet, cette responsabilité est au croisement des fonctions scientifiques et d’encadrement des conservateurs, mais conduit à les exercer dans un cadre beaucoup plus transverse et évolutif. Le chef de produit porte une lourde responsabilité que l’établissement doit apprendre à reconnaître formellement.

14Au sein de l’équipe projet, une personne (qui peut être issue aussi bien de la communauté informatique que de la communauté bibliothèque) joue enfin le rôle de pilote ou d’animateur du projet. Sa fonction est de faire respecter les règles du jeu, de s’assurer que les modalités de travail sont conformes au cadre de collaboration défini au lancement du projet : instances, rôles, respect du calendrier, etc. Il est, en quelque sorte, le garant du respect de la méthode.

15Les méthodes agiles accordent enfin une place particulière aux « commanditaires » de l’application, c’est-à-dire aux personnes qui exercent des responsabilités hiérarchiques vis-à-vis de l’équipe opérationnelle chargée de la réalisation du produit. Si l’équipe est encouragée, on l’a vu, à développer sa propre organisation et à fonctionner de manière aussi autonome que possible, le management n’est pas pour autant exclu de la vie du projet. Les encadrants sont sollicités périodiquement pour résoudre des problèmes de ressources, d’éventuels conflits ou différences d’appréciation quant à la trajectoire et la prise de risques. De ce fait, ils interviennent avant tout en soutien et en impulsion de l’équipe, davantage que comme un vecteur de contrôle. À la BnF, j’y reviendrai, cette démarche a eu pour effet d’impliquer et de sensibiliser davantage l’encadrement supérieur à l’organisation informatique et à la vie des produits applicatifs et à lui faire prendre davantage conscience des dimensions stratégiques et managériales de projets en apparence techniques et donc hors de son champ de vision ou de responsabilité habituel.

La valeur des histoires

16En méthode agile, l’unité de mesure du travail de développement s’appelle « l’histoire utilisateur »* (user story). C’est en effet un principe fort de la méthode que de centrer la réalisation des tâches toujours à partir de l'expérience utilisateur, que ce soit l'usager final (examen d’une fonctionnalité sur une interface destinée au public, sur le front office) ou professionnel (examen d’une fonctionnalité destinée à l’administration du produit, dans le back office). Les fonctionnalités destinées à être traduites en spécifications et en programme ou code informatique sont ainsi scénarisées et « incarnées ». Cette approche garantit la permanence du souci de l’utilisateur dans la conduite du projet. Parce qu’elle favorise l’utilisation d’un langage qui parle directement à des cas d’utilisation concrets et quasiment vécus ou à vivre à travers des exemples et des démonstrations, elle facilite l'échange et la compréhension réciproque entre informaticiens et bibliothécaires, mais aussi avec le management comme avec les communicants qui seront amenés à défendre ou valoriser le projet auprès d’autres instances et d’autres publics. À la BnF, cette approche rend le travail extrêmement tangible. Elle permet aussi de voir les difficultés très vite : une fonctionnalité qu’on n’est pas capable de résumer en histoire est une fonctionnalité mal définie ou dispensable.

17Le travail s’organise en itération, des cycles de développement de quelques semaines relativement courts (deux à quatre à la BnF). Au début de chaque itération, l’équipe dresse la liste des histoires à réaliser (le back log*) et répartit les tâches. À la fin de chaque itération, on évalue le réalisé et le reste à faire (et éventuellement les « bonus », conçus en plus) et on prend le temps d’analyser les raisons pour lesquelles les objectifs n’ont pu être atteints. Ce temps permet à l’équipe de réévaluer certaines options, ou de réfléchir aux forces et aux faiblesses de son organisation de travail. La fixation des objectifs comme la réalisation du bilan donnent lieu à une discussion entre informaticiens et bibliothécaires relative au coût et à la valeur de chaque histoire. Chaque histoire projetée se voit ainsi assigner un certain nombre de « points » de valeur, qui servent à apprécier, d’une part, l’importance accordée à sa réalisation d’un point de vue métier, et d'autre part, le coût de cette réalisation. On reviendra plus loin sur cet aspect particulièrement intéressant dans la méthode agile – la discussion de la valeur – qui favorise à la fois la fixation des priorités et la responsabilisation de chacun.

Les temps et les instances de travail

18La méthode agile s’appliquant à elle-même, il ne faut pas considérer ses règles comme fixes, mais adaptables au contexte, au calendrier et aux ressources de chaque projet. S’agissant des temps et des instances d’interaction entre les acteurs du projet, l’idée principale est qu’il faut qu’ils se rencontrent souvent, à des périodicités régulières, mais pas trop longtemps. Il faut aussi que ces réunions intègrent des temps spécifiques où l’on prend de la distance avec l’objet du projet pour discuter de sa méthode, dans un souci d’amélioration continue et collective. À la BnF, où les temps de réunion sont souvent trop longs notamment du fait du nombre de participants, cette légèreté dans le format des réunions et cette prise de recul sur le cadre même des interactions professionnelles est très appréciée. Elle encourage l’assiduité et permet de dépassionner les relations en cas de tension.

19Les rencontres quotidiennes entre les acteurs-clés du projet au niveau opérationnel sont comparables aux points de presse au sein de la rédaction d’un journal. Ils se font souvent debout et durent une dizaine de minutes. Qu'as-tu fait hier, que vas-tu faire aujourd’hui, quels sont les problèmes à résoudre, quelle actualité faut-il partager ? Voilà à grands traits la trame des échanges qui se tissent autour de ce moment de rencontre quotidien qui est aussi un moment de convivialité favorisant la cohésion d’équipe.

20Celle-ci se réunit plus longuement (une à deux heures) sur un rythme hebdomadaire pour faire le point sur le travail en cours et à réaliser. Des temps d’instruction spécifiques entre acteurs du projet, dans des configurations qui varient selon les expertises, les rôles, les tâches et les histoires qui ont été réparties entre chacun, s’organisent par ailleurs au cours de la semaine.

21Toutes les trois à quatre semaines, une réunion plus conséquente, dite revue d’itération, réunit l’ensemble de l’équipe projet élargie à d’autres acteurs. La revue d’itération s’organise autour d’une démonstration de l’équipe (présentation du produit en cours de développement et des réalisations des dernières semaines), qui induit en retour une validation du chef de produit ou de sa hiérarchie. Si le projet présente des risques ou des enjeux forts (politiques ou budgétaires), ces réunions constituent des points d’avancement et éventuellement d’alerte d’abord tournés vers l’encadrement, à qui il est alors demandé de trancher et d’arbitrer des options. La réunion peut aussi être élargie à des utilisateurs qui n’appartiennent pas au premier cercle des bibliothécaires mobilisés sur le projet. En ce cas, elle a à la fois un but d’information (partager avec un plus large public les avancées du projet) et de consultation (intégrer les attentes et suggestions des professionnels dans la définition de la trajectoire du projet et des itérations suivantes).

22Du point de vue de l’agilité, la réunion la plus importante est celle dite « rétrospective » qui a lieu généralement au sein de l’équipe projet à la suite de la revue d’itération. Lors de cette réunion, l’équipe échange en effet sur sa propre méthode et se demande « Qu’est-ce qui a bien ou mal fonctionné lors de l’itération passée ? » ; « Quels sont les points que nous devons améliorer à l’avenir ? » ; « Les points d’amélioration que nous avions identifiés la fois précédente ont-ils été efficaces et est-il pertinent de les reconduire (ou non) la fois suivante ? ». Pour que la démarche reste réaliste et les objectifs atteignables, le nombre de points d’amélioration en discussion doit rester limité (à deux ou trois, maximum). L’encadrement n’est pas censé participer à cette discussion, en revanche, il doit être informé de ses conclusions. Ce temps de bilan interne est extrêmement utile car il est l’occasion de formaliser les principes et les actions concrètes d’une amélioration collective et constante dans les interactions professionnelles et, plus largement, dans l’organisation du travail.

23À la BnF, l’organisation de ces réunions varie beaucoup selon les projets. Aux réunions d’itération à proprement parler, orchestrées par le DSI, peuvent s’ajouter des réunions dites de « groupes de suivi métier » animées par le chef de produit, dont c’est la mission de solliciter et de représenter l’ensemble des utilisateurs métiers. Ce sont souvent dans ces réunions qu’émergent des histoires que l’équipe projet s’appliquera ensuite à affiner et évaluer pour les intégrer éventuellement à sa feuille de route. Le projet data.bnf.fr, par exemple, dispose à la fois d’un groupe de suivi métier « technique » et d’un groupe de suivi « collections ». Le premier, élargi à des experts du domaine bibliographique et des traitements catalographiques, se concentre sur les processus de transformation et de diffusion des données, les enjeux d’interopérabilité entre formats de données ou de référencement par les moteurs de recherche, par exemple. Le second groupe, qui accueille des collègues davantage impliqués dans les acquisitions documentaires, leur valorisation et la médiation auprès du public, se concentre au contraire sur le choix des corpus et contenus diffusés et valorisés par data.bnf.fr et des services rendus à l’usager final. Les réunions de ces groupes servent avant tout à faire émerger des idées et à identifier des opportunités de développement. Elles sont une vraie source d’inspiration et de créativité pour le projet.

24Dans un contexte très différent, les réunions d’itération qui encadrent le projet Registre des livres indisponibles en réédition électronique (ReLIRE)3 mobilisent davantage la hiérarchie des équipes que les acteurs métiers. En effet, si la commande fonctionnelle pour ce projet est, dans ses grandes lignes, dictée par des textes législatifs et réglementaires, les risques en termes de délais, de communication et de ressources, requièrent une attention et une concertation régulières pour l’encadrement. L’agilité se décline ainsi, en termes d’organisation, en fonction du contexte, des risques et des objectifs de chaque projet. Au lancement d’un projet, il est donc essentiel d’imaginer le type d’organisation du travail (plutôt horizontale, dans l’exemple de data.bnf.fr, ou davantage verticale, dans l’exemple de ReLIRE), qui correspondra le mieux à l’enjeu qu’il représente dans la stratégie et le fonctionnement global de la bibliothèque.

25Dans les temps du projet, ce ne serait pas faire justice à la réalité qu’il m’a été donné de partager sur le terrain que d’occulter le rituel que constituent les fêtes et les pots organisés à chaque étape clé du projet. Lors d’une mise en production particulièrement importante et à la clôture des projets, rassembler tous les acteurs et contributeurs pour un moment de convivialité s’est imposé comme un rite festif particulièrement attendu et apprécié dans la vie des équipes. On éprouve dans ces moments un mélange de fierté, de convivialité et de partage qui étaient jusque-là surtout réservés aux pots de départs. Je ne sais pas si la méthode agile émet des recommandations particulières à ce sujet, mais c’est en tout cas une des interprétations les plus joyeuses qu’en ont faites les agents de la BnF.

Bilan critique et prolongements

26En conclusion de ce tour d’horizon de l’agilité vue depuis l’une des nombreuses lucarnes de la BnF, je voudrais partager quelques réflexions personnelles qui mettent en perspective cet outil de travail particulier que sont les méthodes agiles avec des considérations plus générales sur le management.

27Parmi les limites de la méthode, et pour temporiser certains enthousiasmes, il faut d’abord dire que la méthode agile ne rend pas miraculeusement compétent et motivé quelqu'un qui ne l'est pas. Quelle que soit la méthode, les projets qui réussissent sont portés par des agents de qualité et la méthode agile est, de ce point de vue, sans effet sur un mauvais recrutement. Toutefois, l’important dispositif de communication interpersonnelle sur lequel repose la méthode, et la production régulière de livrables visibles et testables, permet de repérer rapidement les difficultés relationnelles ou les problèmes de compétence ou de motivation. De ce point de vue, on peut dire que la méthode permet de recadrer un projet plus rapidement. Par ailleurs, pour peu que les pilotes et animateurs du projet jouent pleinement leur rôle, on constate que c’est un type d’organisation qui favorise réellement la montée en compétence individuelle par le collectif. L’esprit d’équipe favorise les progrès de chacun tant que l’équipe reste cohérente et mobilisée.

28Une autre limite de la méthode concerne son application dans un cadre contractuel, classiquement, celui d’un marché public. Un nombre croissant de sociétés propose la méthode agile dans leur offre de prestations de développement, mais c’est une évolution encore récente et diversement appliquée. Dans la rédaction du cahier des clauses techniques particulières (CCTP) et la négociation contractuelle, il est donc important que la bibliothèque exprime clairement ses exigences du point de vue des méthodes de collaboration entre client et prestataire. Un temps de calage et de formation réciproque est à prévoir au début de la prestation afin de confronter les interprétations que le commanditaire et le prestataire peuvent avoir de la méthode agile. Cela représente un investissement significatif au démarrage du projet : ce temps est nécessaire et renforce les chances de succès. Pour autant, des livrables mouvants ne sont pas toujours faciles à intégrer au cadre contractuel. La flexibilité requise par la méthode doit rester compatible avec le formalisme et les obligations du marché. Un marché à bons de commande est, de ce point de vue, le dispositif le plus « soluble » avec la méthode agile, dans la mesure où il permet de contractualiser les engagements au fil des itérations. La méthode agile reste plus simple à appliquer entre les équipes permanentes d'une même organisation. C’est dans ce cadre, en outre, qu’on peut durablement capitaliser des compétences mais aussi du lien social entre agents : une équipe qui a réussi sur un projet pourra se voir confier un tout autre projet mais la qualité de la relation de travail bâtie collectivement permettra d’attaquer le nouveau développement avec beaucoup d’atouts et d’assurance.

29Un aspect qui peut paraître autant une difficulté qu’une force de la méthode concerne le rapprochement des métiers. L’agilité rapproche en effet considérablement bibliothécaires et informaticiens. Elle génère de l'acculturation, de la porosité entre ces communautés métiers, elle conforte des polyvalences. Cela rejoint des phénomènes plus profonds et souvent discutés à propos de l’évolution du métier et de l’identité professionnelle des bibliothécaires, appelés à intervenir de plus en plus directement dans la conception voire la réalisation d’outils et de processus informatiques. Au quotidien, on apprécie les vertus de ce rapprochement : l’agilité contribue à créer des bassins de compétence qui rendent l’organisation collective beaucoup plus performante car les agents communiquent mieux et se comprennent plus vite. Les risques de perte de compétences (au départ d’un agent expert, par exemple) s’en trouvent également limités parce que le savoir est davantage partagé. Mais cette porosité peut aussi complexifier la répartition des rôles, l’exercice des responsabilités entre métiers et éventuellement générer des écarts problématiques entre statuts et fonctions. C’est pourquoi la méthode agile insiste beaucoup, dans ses principes, sur la désignation et le respect des rôles de chacun. Il faut rester vigilant sur les périmètres de responsabilité dans le déroulement du projet, a fortiori parce qu’on encourage l’équipe à s’auto-organiser : il est important de veiller au respect de certaines limites formelles dans la pratique afin, d’une part, que les activités exercées restent conformes à la fiche de poste et au statut d’emploi de chacun (et à la rémunération qui y est associée) et, d’autre part, qu’il n’y ait pas confusion des genres dans l’exercice des responsabilités entre services informatiques et services documentaires. C’est un point d’attention particulier pour l’encadrement dans la supervision du développement agile.

30Je trouve particulièrement intéressante et saine la discussion permanente sur la valeur que favorise la méthode agile lors de l’examen des histoires et la définition du périmètre et des charges de chaque itération. La confrontation, la négociation et l’objectivation de la valeur métier et de l’estimation des coûts de développement (qui, dans certaines méthodes, est scénarisée comme une partie de poker entre les agents) sont des leviers de management très efficaces pour faciliter à la fois la prise en compte de la finalité de la technique et la responsabilisation des utilisateurs. Échanger régulièrement sur ce que « valent » les choses qu’on souhaite construire et confronter ces estimations au moyen d’unités objectives et vérifiables (hommes-jours, histoires) est un très bon exercice. Sur la durée, on observe que cela conduit les développeurs à mieux appréhender, de l'intérieur, les valeurs métiers des utilisateurs, et aux bibliothécaires à comprendre tout aussi intimement le coût du développement informatique. Pour dire les choses crûment, on pourrait dire que l’agilité prémunit l’informaticien d’un certain autisme tandis qu’elle limite la propension des bibliothécaires à écrire des lettres au Père Noël lorsqu’ils font la liste de leurs besoins.

31Pour les encadrants, enfin, les méthodes agiles constituent à mon sens un terrain d’expérience à la fois intéressant et gratifiant. Le mode d'implication des décideurs est assez différent de ce que l’on peut observer traditionnellement dans une grande organisation très verticale comme la BnF. La méthode positionne d’entrée de jeu le manager comme un appui et un arbitre pour une équipe par ailleurs structurée pour s’organiser par elle-même. Les méthodes agiles incitent les encadrants à intervenir là où leur valeur ajoutée fonctionnelle est véritablement attendue : assumer pleinement la responsabilité des ressources, des risques et des personnes plutôt qu’empiéter sur les dimensions fonctionnelles ou créatives qui appartiennent à l’équipe. En bref, ce qu’on attend d’un manager c’est davantage d’arbitrer un budget ou de fixer une échéance plutôt que choisir la couleur d'un bouton ou d’un logo sur une interface. L’agilité pousse à un exercice plus positif de la responsabilité. Cela requiert néanmoins de la part des intéressés un minimum de disponibilité et d'assiduité aux réunions prévues pour les moments décisifs dans la vie du projet.

32Une conclusion, partagée par beaucoup de commentateurs et d’acteurs de la méthode agile, est que ses principes et ses modalités conçus initialement pour le développement logiciel peuvent en réalité inspirer la pratique managériale dans son ensemble. L’agilité peut aider au développement de toute la bibliothèque. Ce que j’en retiens concrètement à mon niveau ? Organiser plus de réunions mais plus courtes, dans des configurations dont la périodicité régulière permet à chacun de mieux identifier et asseoir son propre rôle mais aussi celui des autres. Utiliser ces cadres pour favoriser la communication interpersonnelle, plus efficace et moins anxiogène que le courriel. Garder en tête que le travail du manager est aussi d’aider ses agents à trouver du sens et du plaisir dans leur travail, ce qui passe par le sentiment d’appartenir à un collectif et d’y avoir une utilité, un rôle, une place. Utiliser des mots et des dispositifs qui obligent à placer en permanence l’humain – qu’il s’agisse de l’équipe ou de l’usager final – au centre du travail. Responsabiliser chacun, dans son quotidien, face à l’appréciation du coût et de la valeur de ce que la puissance publique nous autorise à dépenser. Encourager le pragmatisme par l’examen de résultats et de preuves de concepts tangibles plutôt que de se disputer sur des principes ou des spéculations. Éviter enfin le tunnel et l'irréalisme en assumant pleinement un cadre de travail qui donne le droit à l’erreur, permet de changer d'avis, de douter, de confronter l'ambition à la réalité, de s’adapter. Bref, accepter de se remettre collectivement en cause sans que cela soit perçu comme un échec personnel ni comme une défaillance de l’organisation4. Ce sont des idées simples et de bon sens, mais qu’il peut être utile d’encadrer pour faciliter leur mise en œuvre. Les méthodes agiles peuvent y contribuer.