Pourquoi la méthode ?

Il fut un temps où aucun décideur n’aurait supporté l’idée qu’un projet, dans son entreprise, soit mené sans appliquer une certaine méthode. C’était une époque où des méthodes de référence s’imposaient sur le marché, et recevaient l’onction de décideurs soucieux de maîtriser le détail. Aujourd’hui, la situation a bien changé. La culture ambiante a balayé notre patrimoine méthodologique ; le mot « méthode » même est devenu suspect ; les termes « pragmatisme », « agilité », « architecture »… sont détournés de leur vrai sens pour servir d’alibi à l’amateurisme. Les pratiques de modélisation, si elles n’ont pas totalement disparu, ont subi de profondes régressions. On leur préfère le bricolage.

Pourtant, quand une entreprise se trouve en situation de crise, ou mise en demeure de prendre à bras le corps ses problèmes, surgit la question du « comment faire ? ». Cette question attend des réponses en termes de méthodes. Qu’est-ce qu’une méthode ? Une façon de faire, maîtrisée, documentée, souvent appuyée sur une réflexion, disons même sur une théorie.

Il n’y a rien de plus pratique qu’une bonne théorie.

Mieux vaut une méthode efficace que des pratiques hasardeuses.

 Si, à l’action, vous retirez la réflexion, il ne reste que l’agitation.

 

Alors que, dans l’usage, disparaissaient les termes de « méthode », « modélisation », « concepteur », « forme normale », etc. le terme « architecture » jouissait d’un prestige croissant. Mais de quoi parle-t-on ? Encore une fois, il s’agit d’une métaphore, celle de l’architecte qui, avant de guider la construction de l’ouvrage, établit scrupuleusement les plans, choisit son style, imprime sa marque, vérifie les usages et les circulations. L’architecte passe la plus grande partie de son temps sur la planche à dessin. Il a l’autorité sur les corps de métier, et peut arrêter le chantier si celui-ci ne se conforme pas aux plans.

La métaphore s’applique-t-elle aux pratiques d’architecture métier, d’architecture fonctionnelle, d’architecture d’entreprise et de toutes les variantes que l’on peut imaginer ? Quelle part de leur temps nos architectes passent sur la planche à dessin, à supposer qu’ils produisent autre chose que des Powerpoint ? Où sont les plans de l’entreprise ? ceux du système informatique ? Une carte des processus existe sans doute, mais à quel moment s’est-on posé la question du bon découpage, de la validité du critère de décomposition, de l’articulation des fonctions entre elles ? Quand sait-on qu’une architecture technique est complète ? Est-on certain que la carte des applications reflète la réalité du couplage ?

Nos systèmes sont complexes, dit-on. Alors, où sont les plans détaillés qui permettent d’en maîtriser la construction et l’évolution ? Un décideur peut-il, en conscience, engager des millions d’investissement sur la base d’une simple diapositive ou d’une présentation à peine commentée ? Ne doit-on lui apporter la preuve que, derrière la maquette en carton-pâte, la conception a bien appliqué les règles de l’art, et produit les représentations et les calculs qui garantiront le résultat ? C’est du moins ce qui est fait quand on construit une maison. Ne faudrait-il pas le faire aussi quand il s’agit de systèmes et d’entreprises dont la valeur atteint plusieurs ordres de grandeur par rapport à celle d’un immeuble ?

Arrêtons de dire que ces sujets – la conception d’entreprise, l’organisation, l’informatique – sont trop récents pour que nous ayons pu capitaliser sur leur connaissance ! Nous pouvons, en ces matières, nous appuyer sur une longue tradition. La première méthode d’architecture logique, par exemple, la méthode TACT, remonte aux années 1980. Les réflexions sur la structuration des systèmes sont antérieures, et leurs découvertes restent valides. Cependant, cet héritage est recouvert et enfoui sous les termes à la mode, tous tirés du domaine technique. Dans notre culture, seule la technologie semble valorisée, d’ailleurs pas en tant que telle, mais en tant que nouveauté. Ceci entretient un état d’esprit qui n’est pas le plus propice à la pensée juste et à l’action efficace.

En outre, décideurs, architectes, concepteurs doivent absolument prendre conscience des schémas de pensée qui déterminent leurs décisions (ce n’est pas pour rien que le « prix Nobel d’économie » revient, pour la deuxième fois, à un spécialiste de l’économie comportementale – après Daniel Kahneman, Richard Thaler). Une écrasante majorité des décisions – et des non-décisions – se prennent sur la base de préjugés, d’idées préconçues, d’habitudes renforcées par un fort mimétisme. C’est ainsi que les systèmes se piègent eux-mêmes dans des fonctionnements sous-optimaux, des logiques létales, et se montrent incapables de s’en extraire.

La réflexion méthodologique est là pour mettre en lumière ces dérives, et pour proposer des remèdes.

SOA en quatre messages

1. SOA est un style d’architecture de système informatique

Pour élaborer la structure d’un système informatique, nous recourons toujours à une métaphore : fonction, machine, ville, service, événement, agent… La plus traditionnelle et encore la plus ancrée dans les esprits est celle de l’architecture fonctionnelle, par laquelle nous percevons le système comme un ensemble de fonctions. Elle a montré ses limites puisqu’elle est associée à la décomposition hiérarchique et entraîne un fort taux de redondance. La métaphore la plus actuelle est celle du service, caractéristique de l’approche SOA (service oriented architecture). Elle agrège de nombreuses notions connexes telles que le contrat et l’encapsulation.

Aborder un système par le truchement d’une métaphore est un acte propre à l’architecture logique : la conception d’un système artificiel, dans une relative indépendance par rapport aux choix techniques.

Le premier message de Praxeme pour SOA est l’importance des disciplines d’architecture logique et de conception logique pour tirer parti de l’approche SOA.

Styles

2. Les promesses de SOA ne se concrétisent que quand on consent un effort de restructuration du système

On oppose ainsi :

  • SOA de surface, qui consiste à brancher quelques services sur un système auquel on ne touche pas ;
  • SOA de refonte, qui généralise la métaphore à l’ensemble du système et, progressivement, transforme celui-ci significativement.

Évidemment, si on applique la première approche (on pourrait dire : FOA, la fausse SOA), il ne faudra pas s’étonner que les retombées promises (réutilisation, simplification, interopérabilité, agilité…) n’auront pas été tenues.

FOA versus SOA

3. La mise en place d’une SOA prend son sens dans une stratégie d’urbanisation du système informatique

Cette conclusion découle de la précédente : la conversion d’un système en architecture de services est un processus patient, qui exige une continuité de vision et une grande constance sur le long terme. Tout à fait les caractéristiques de l’urbanisation.

Il convient donc d’articuler soigneusement les deux disciplines de l’urbanisation de SI et de l’architecture logique. Ceci réclame des dispositions pratiques, notamment en ce qui concerne les représentations du système mais aussi en termes d’organisation et de gouvernance SI.

POS versus Graphe d'architecture logique

4. La bonne volonté et l’intuition sont insuffisantes pour mener à bien la transformation d’un système informatique

Il y faut de la rigueur et des techniques précises, conçues pour affronter la complexité propre aux systèmes d’information. Se lancer dans de tels travaux sans méthode serait naïf et suicidaire. On observe encore trop souvent des équipes qui s’écharpent sur la notion de service, qui s’épuisent en vaines considérations sur la granularité ou la typologie des services, ou qui bricolent de prétendus méta-modèles. Aurait-on accepté un tel gaspillage dans les années 80 ? Non, pas au moment où les managers savaient imposer les méthodes à leurs équipes. Certes, cette attitude était facilitée par l’existence de méthodes de référence largement répandues et appuyées par la Puissance publique. Autre temps, autre mœurs !

Il existe néanmoins une réponse toute prête : Praxeme pour SOA, c’est-à-dire, dans la méthodologie de transformation des entreprises, la partie  dévolue à la conception des systèmes informatiques. Élaborée à partir de 2003 et mise au point sur de grands projets, elle a été appliquée de nombreuses fois et a été consolidée. Sa version 2 est diffusée à travers la formation « SOA, conception d’une architecture de services« . Elle sera publiée en fonction des opportunités (guide « Approche de l’aspect logique » et fiches de procédés).

Postionnement de l'aspect logique

Pour aller plus loin…

Ces quatre messages sont développés dans l’article « Quatre idées fortes de Praxeme pour SOA« .

Méthodologie d’entreprise

Tout le monde en convient : l’entreprise est un objet complexe, tissé de multiples déterminations, obligé sans cesse de s’adapter à un monde changeant. Comment penser cette complexité ? Comment tout dire de l’entreprise sans risquer d’omettre un facteur décisif ? Comment trouver les bonnes idées qui vont assurer l’avenir ?

Il serait illusoire de croire qu’une formule unique, tel un charme magique, suffirait à appréhender cette réalité complexe. Nous devons convoquer de nombreuses disciplines et articuler des expertises variées. Pour les mettre en synergie, nous devons les couler dans un cadre interdisciplinaire, cohérent et capable de tirer parti de tous les apports. Cette exigence définit la méthodologie d’entreprise.

Praxeme est la méthodologie d’entreprise, issue de l’initiative pour une méthode publique. Elle repose sur une analyse du Système Entreprise et de sa logique interne. Les procédés qu’elle propose couvrent tous les aspects de l’entreprise, de l’éthique à l’infrastructure, de la connaissance à la logistique, en passant par les processus et l’organisation.
C’est une chose de disposer des méthodes pour chaque aspect de l’entreprise (les méthodes pour les stratèges, celles pour les organisateurs, celles pour les informaticiens ou les comptables, etc.) ; c’en est une autre de les articuler soigneusement afin d’obtenir une chaîne de transformation harmonieuse. Le souci originel de Praxeme est justement de répondre à ce besoin de coordonner des spécialités disparates, également légitimes et nécessaires, mais qui communiquent difficilement.

Ce besoin, le dirigeant d’entreprise ou d’administration le ressent en premier lieu, d’autant plus fortement que son organisation est confrontée au changement. Face à l’hétérogénéité des propositions, le décideur recherche un cadre général qui optimise l’investissement : s’il porte l’effort sur un point de la chaîne de transformation, s’il sacrifie aux sirènes du moment, il lui faut la garantie que cette action s’inscrive dans un plan plus vaste, déployé dans toutes les dimensions de l’entreprise. Il cherche également les moyens de stimuler l’innovation, non seulement en reprenant les recettes de ses concurrents ou en adoptant les dernières technologies, mais aussi en revisitant le métier, en se décentrant, en se réinventant. Or, la psychologie humaine, les forces de conservation, les jeux d’acteurs… tout conspire pour empêcher cette transformation.

Aussi est-il d’une absolue nécessité de disposer d’une méthode qui révèle les phénomènes à l’œuvre et qui offre les moyens concrets de les dépasser. Le premier apport de Praxeme consiste en la prise de conscience de la complexité et la reconnaissance des univers cognitifs qu’il faut relier et mettre à contribution. Éthique, terminologie, métrologie, modélisation, sociologie, architecture de systèmes sont quelques-unes des disciplines qui permettent d’approcher la réalité de l’entreprise. Elles produisent des représentations que la méthode aide à formaliser et à relier. Par exemple, la conception des processus s’inspire des exigences éthiques, c’est-à-dire des valeurs déclarées par l’entreprise. Ou encore, le système informatique découle des modèles métier, selon des règles de dérivation qui garantissent son alignement et son agilité.

Praxeme a été appliquée à des échelles variables et dans tous les secteurs d’activité. Les applications incluent la refonte des systèmes d’information, l’innovation dans les systèmes d’armement, la modélisation des systèmes de transport, l’évolution des pratiques, la convergence entre systèmes ou métiers d’une fédération d’entreprises, l’interopérabilité. L’administration française, pour mener ses grands programmes de modernisation de l’action publique, recommande l’usage de cette méthode.

Étant donnée son ambition, Praxeme est un chantier permanent. L’initiative se veut ouverte, au double sens où elle accueille les contributions et où elle met à disposition ses résultats, libres de droits. Une première version est disponible sous la forme de guides méthodologiques qui posent les fondements. La version 2 est en cours de rédaction et complète le corpus par des fiches de procédés destinées aux différents acteurs des transformations.

Le Praxeme Institute, association sans but lucratif et reconnue d’utilité publique, coordonne les travaux et veille au respect de l’esprit d’ouverture.
Pour plus d’information :

Dominique Vauquier

Praxeme, la méthode publique

Praxeme est une méthodologie de transformation d’entreprise issue de l’initiative pour une méthode publique.

 

L’initiative a été lancée en 2004  et portée par l’association à but non lucratif, le Praxeme Institute.

Dominique Vauquier et Fabien Villard animent cette initiative, depuis son origine.

Le Praxeme Institute accorde, à la SAS Praxademia, la qualité de contributeur, conformément aux statuts de l’association. Au fil des ans, la contribution est une des plus importantes qui ont alimenté le fonds public. Elle comprend  :

  • de nombreux composants de la méthode (guides méthodologiques écrits par Dominique Vauquier, fiches de procédés…) ;
  • la promotion de la méthode à travers des articles, des conférences ainsi que des interventions dans l’enseignement supérieur ;
  • le développement et l’entretien des dispositifs de communication par Fabien Villard (site web de l’association, wiki, blogs) ;
  • récemment, le développement de la qualification Praxeme.

Pour plus de détail, voir une introduction à la méthodologie d’entreprise.