Voyage au pays des méthodes

Une « méthode », c’est un chemin qu’il convient de suivre : μέθοδος a pour étymologie μετά (selon, suivant) et ὁδός (voie, chemin). La méthode indique l’ordre séquentiel des opérations à réaliser pour atteindre un but que l’on s’est fixé (NB : le club des maîtres d'ouvrage a ainsi défini une méthode de modélisation, voir Modéliser le système d'information).

Les méthodes abondent dans le monde des systèmes d’information où on les nomme souvent, de façon emphatique mais impropre, « méthodologies[1] ». Elles sont nécessaires pour résister au désordre, qui s’installe dans le SI aussi naturellement, aussi vigoureusement que de mauvaises herbes dans un potager (voir Entropie du système d'information). La succession des étapes de la démarche est souvent concrétisée et attestée par la liste des documents qu'il convient de produire.

Les méthodes ont des limites. Aussi nécessaires qu’elles soient, elles ne sont jamais suffisantes. Nous les avons vu souvent servir d’alibi à des maladroits, comme s’il suffisait de dire « j’ai suivi la méthode » pour excuser un échec.

Toutes les méthodes ont été élaborées par des comités. Elles tirent ainsi parti d’une expérience diversifiée et approfondie, mais cela leur confère le caractère d’un compromis entre des orientations diverses. Or la logique qui sous-tend un compromis est toujours moins nette, moins lisible que celle sur laquelle se fonde une orientation particulière.

Ajoutons que ceux qui aiment à se référer aux méthodes en toute occasion ne sont peut-être pas les meilleurs parmi les experts. Il entre souvent, dans l’évocation insistante des méthodes, un peu de cuistrerie : l’érudition ainsi manifestée intimide ceux qui ne l’ont pas acquise et inhibe la communication.

Enfin la lecture des méthodes est, il faut le dire, très ennuyeuse. La plupart d'entre elles sont présentées sous la forme d’une liste de points à accomplir ou à vérifier, sans que leurs auteurs n’aient pris la peine d’expliquer la logique qui a présidé au choix du contenu et de l’ordre de ces listes, ni celle d’aider à distinguer dans ces énumérations l’essentiel de l’accessoire.

Le recours aux méthodes est cependant utile, tout comme les conserves et condiments sont utiles en cuisine (les méthodes sont d’ailleurs très exactement du bon sens en conserve, du savoir-faire surgelé).

Pour se convaincre de leur utilité il suffit de voir ce qui se passe lorsqu’un projet est conduit sans méthode, lorsqu’on laisse évoluer un système d’information « comme le chien crevé au fil de l’eau ». En avons-nous vu, de ces réunions sans ordre du jour, durée limite ni compte rendu ; de ces décisions annoncées à la cantonade sans qu’on ne désigne la personne qui devait les mettre en œuvre, ni que l’on ne s’assure, par la suite, qu’elles ont été suivies d’effet ; de ces travaux successifs qui sont autant d’épisodes d’un mouvement brownien, l’entreprise trépignant sur place ! En avons-nous vu, de ces « bidonvilles de luxe » construits sans méthode, architectures coûteuses et inefficaces où s’expriment à la fois, de façon répugnante, l’arrogance de la richesse et la carence de la pensée !

Mais il n’est pas facile de faire partager à un dirigeant le constat des travers de son entreprise : s’il savait les percevoir, il les aurait déjà corrigés. Il sera tenté de taxer l’expert de perfectionnisme, de maniaquerie, d’esprit de système ; il croira que ses recommandations ne font qu’exprimer une lubie personnelle. Il est alors salubre de placer entre l’expert et le dirigeant la méthode, pierre de touche pour évaluer l’écart entre l’entreprise et l’état de l’art. A plusieurs des méthodes sont d’ailleurs associés un « modèle de maturité » (maturity model) qui permet à l’expert de dire à l’entreprise : « sur tel point, vous êtes au niveau zéro ; sur tel autre, au niveau 2 », alors que l’excellence requiert le niveau 5.

Lorsqu’on dit que la méthode reflète l’état de l’art, il faut s’entendre : l’« état de l’art » dont il s’agit n’est pas celui de la moyenne des entreprises car les méthodes décrivent ce que les entreprises devraient faire, non ce qu’elles font. Si le dirigeant s’inquiète de voir son entreprise en retard il faudra le rassurer en lui disant qu’elle est loin d’être seule dans ce cas.

Pour un bon usage des méthodes

Pour voir comment utiliser les méthodes, rappelons que l’œuvre réussie est celle dont le créateur a su concevoir à la fois un contenu et les règles selon lesquelles celui-ci a été mis en forme. De même, toute ingénierie réussie porte en elle et les exigences auxquelles elle répond, et les méthodes qui auront été suivies pour les satisfaire.

Il ne s’agit donc pas d’« appliquer la méthode », comme on le dit souvent, ni d'ailleurs de réinventer la méthode à chaque occasion, mais de bâtir, à partir des éléments de méthode qu’apportent les méthodes disponibles, la méthode appropriée à l’ingénierie que l’on considère.

Les méthodes standard sont ainsi à l’ingénierie ce qu’est une palette de briques pour un maçon : un ensemble d’éléments nécessaires à la construction d’un mur mais dont l’utilisation requiert que l’on ait décidé auparavant la forme du mur, puis que l’on sache tailler et ajuster des briques. Les auteurs des méthodes le disent d'ailleurs eux-mêmes : la méthode n’est pas faite pour être appliqué telle quelle car, tout comme un vêtement de confection, elle exige des retouches. Parmi les éléments que comporte une méthode standard, certains seront importants en regard du projet considéré, d’autres secondaires. Il convient de les distinguer et ceux qui sont négligeables devront être négligés.

Pour discerner ce que l’on retiendra de la méthode standard, il faut examiner d’abord le problème à traiter. Tout comme il existe une pensée préconceptuelle lors de laquelle l’esprit choisit son orientation, il existe avant la méthode une étape « naïve » qui sert à repérer les articulations et enjeux principaux du projet. Faisant appel au bon sens, elle n’est pas entièrement formalisable.

On bâtira à l’issue de cette première exploration une esquisse de démarche, fût-elle maladroite, et c'est seulement après que l’on se tournera vers les méthodes pour voir si l’on n’a rien oublié d’important et y puiser les compléments nécessaires.

Ces compléments, il faudra parfois encore les compléter. Les méthodes, en effet, signalent des choses à faire mais souvent elles ne disent pas comment les faire. On vous dit par exemple qu’il faut bâtir un plan d’assurance qualité. Mais dans le cas d’espèce, quelle sera la définition de la qualité ? Comment l’observer, la mesurer ? Quelle diffusion donnera-t-on à sa mesure ?

Autre exemple : on vous dit qu’il faut mettre en place une administration des données. Mais il existe plusieurs façons de définir cette tâche et pour le projet que vous considérez une seule sera la meilleure. Comment la choisir ?

Dernier exemple : les méthodes proposent souvent une liste de documents à établir. Mais il ne suffit pas qu’un document existe, il faut encore que ceux qui le consultent puissent l’interpréter sans un trop gros effort de déchiffrement. En avons-nous vu, de ces documentations formellement conformes à la méthode mais pratiquement illisibles ! Comment définirez-vous, vérifierez-vous la lisibilité de la documentation ?

Plan du voyage

La présente fiche est le récit du voyage entrepris avec le club des maîtres d'ouvrage au pays des méthodes pour compléter nos connaissances et mettre notre expérience à l’épreuve.

Nous avons étudié et annoté trois méthodes : CMMI, COBIT et ITIL. Celui qui cherche du plaisir dans la lecture devra choisir d’autres textes ! Le voyage a été austère, espérons que son compte rendu ne le sera pas trop.

Ces trois méthodes sont celles qui sont le plus fréquemment évoquées lorsqu’on parle de la qualité des systèmes d’information. Il en existe d’autres, mais avec ces trois-là on couvre, nous semble-t-il, un bon échantillon de ce qui est nécessaire pour concevoir, organiser, réaliser et exploiter un système d’information.

Le déploiement des acronymes qui les désignent n’apporte qu’une information imprécise : il faut les ouvrir pour savoir ce qu’elles contiennent.

CMMI[2] (Capability Maturity Model Integration) traite de la conduite de projet, sujet rebattu dans les cours d’informatique mais qui, dans la pratique, est rempli de pièges. CMMI n'est pas toutefois une méthode de conduite de projet, mais une méthode pour qualifier l'entreprise en conduite de projet.

Alors que CMMI se concentre sur l’investissement réalisé à l’occasion des projets, ITIL[3] (Information Technology Infrastructure Library) considère la mise en oeuvre du système d’information et la qualité du service rendu à l’utilisateur.

Enfin, COBIT[4] (Control Objectives for Information and related Technology) traite de la « gouvernance » du système d’information, c'est-à-dire des formes d’organisation et des procédés qui permettent à l’entreprise d’assurer la pertinence du SI et son efficacité.

CMMI et COBIT sont produits par des organisations américaines qui publient sur le Web une documentation abondante et gratuite. ITIL est produit par une organisation britannique qui vend la documentation à un prix relativement élevé.

Nous avons entrepris ce voyage avec modestie et son compte rendu est sans prétention. Il contient sans doute des erreurs : nous saurons gré à ceux qui nous les signaleront.

Nous avons confronté les méthodes à ce que nous a enseigné l’expérience, mais comme toute expérience la nôtre est limitée : la validité de nos commentaires l’est donc aussi. Nous espérons toutefois qu’ils inciteront leurs lecteurs à interroger les méthodes à la lumière de leur propre expérience.

[1] « Méthodologie » signifie « discours sur la méthode », tout comme « technologie » signifie « discours sur la technique ». Échanger le terme exact contre un autre, plus abstrait mais que l'on croit plus prestigieux, dégrade le langage tout comme l’inflation dégrade la monnaie.

[2] Voir le site du SEI (Software Engineering Institute), www.sei.cmu.edu, à partir duquel on peut télécharger gratuitement toute la documentation.

[3] Voir le site officiel présenté par l’OGC (Office of Government Commerce), www.itil.co.uk. La documentation est publiée sous la forme de huit livres d’un prix total de 470 £ (688 €), auxquels sont associés sept CD-ROM d’un prix total de 960 £ HT (1 406 € HT).

[4] Voir le site de l’IT Governance Institute, www.itgi.org, à partir duquel on peut télécharger gratuitement toute la documentation.