Quelques éclaircissements sur le chantier Praxeme

Méthodologie d’entreprise

Dès l’origine, Praxeme s’est voulue comme une méthodologie d’entreprise, c’est-à-dire une réponse au besoin patent que rencontrent les entreprises et que perçoivent les dirigeants : articuler les expertises, les mettre en synergie. Conséquence : l’expression “Enterprise Architecture” (EA) a été prise au pied de la lettre, comme désignant une discipline qui pense l’entreprise comme un tout, dans toutes ses dimensions. Dès lors, Praxeme se sépare des méthodes proposées sous l’étiquette EA et qui sont toutes dans la sphère de l’informatique. Zachman, avec son questionnaire du Quintilien et son approche matricielle, aurait pu couvrir l’entreprise, mais sa façon de répondre (What = Data) lui a fait manquer la cible. On ne peut pas lui en vouloir : les déterminations historiques et culturelles ne pouvaient pas produire, à l’époque, un autre résultat.

Par rapport à l’architecture d’entreprise

Donc, Praxeme n’est pas une méthode d’architecture, fût-elle d’entreprise. Si nous disons “méthodologie d’entreprise” ou “méthodologie de transformation d’entreprise”, c’est pour affirmer l’ambition de créer le creuset dans lequel toutes les approches de l’entreprise viendront converger et se fondre en un nouvel alliage. Le sujet est donc, en premier lieu, d’identifier les multiples rationalités qui traversent l’entreprise et de les amener à se reconnaître et à mieux cohabiter. Pour cela, il est besoin d’adopter une posture de méta-rationalité (non d’hyper-rationalité, car elle a bien conscience de la rationalité limitée, ce qui la teinte de modestie). Bien sûr, une méthodologie d’entreprise ménage sa place à l’architecture d’entreprise, discipline clef dans la transformation de l’entreprise (au même titre que la conception stratégique, l’organisation et bien d’autres disciplines).

Ces deux points, combinés, obligent à repenser les fondations et même à rechercher un autre sol pour fonder le nouvel édifice. Certes, la tradition informatique joue un rôle non négligeable dans cette perspective, non seulement du fait de nos trajectoires individuelles (ce serait un peu mesquin) mais surtout par la nature même de l’informatique, intermédiaire obligé entre le réel et l’idéel. (Je ne m’étends pas ; je me contenterai de renvoyer au maître ouvrage de Pierre Lévy, La machine univers.)

C’est ainsi qu’il est apparu nécessaire d’identifier les règles pour construire le cadre de référence, la grille de lecture à appliquer à l’entreprise. De là, la nouvelle version de la Topologie du Système Entreprise. Un chiffre pour juger de notre recherche : la version 1 de la TSE comptait 8 aspects dont 4 liés à l’informatique ; la version 2 n’en compte plus que 7, l’informatique étant une des composantes de deux des aspects. Le document PxPRD-01, inscrit au catalogue de la version 2, présentera ces règles et le résultat de leur application. Ce sujet a été présenté dans la formation exceptionnelle “Business Architecture & Transformation“.

Rapprochement entre référentiels de pratiques

Mieux intégrer l’EA avec des référentiels de pratiques comme ITIL ou COBIT va évidemment dans le bon sens, d’autant que ces référentiels ont tendance eux-mêmes à élargir leur domaine et à élever leurs aspirations. Mais pourquoi se limiter aux pratiques informatiques ? N’est-il pas aussi important, pour réussir son architecture d’entreprise, de la coupler à la conception des processus, donc à l’organisation, ou à la modélisation éthique et à la stratégie comme discipline ? Ces domaines s’appuient aussi sur des référentiels ou, du moins, sur une littérature abondante et une tradition riche. Il faudra bien réussir la connexion, sauf à rester confiner dans le champ de l’IT et à amputer notre capacité d’innover.

A propos d’agilité

En ce qui concerne l’agilité, nous sommes face à une contradiction. C’est surtout la contradiction d’essence entre le mode projet (portée locale et à court terme) et la portée système (vision long terme et globalisante de l’architecture). La nécessité de concilier stabilité et agilité de l’entreprise amène à penser le rapport entre :

  • agilité des activités de transformation, d’une part,
  • qualité de l’architecture, d’autre part.

La proposition de Praxeme pour résoudre l’équation consiste à réorganiser les activités de transformation, architecture et projet compris, autour du Référentiel de description de l’entreprise. Ce pot commun n’est, certes, pas facile à construire et il y faut une gouvernance subtile et décidée. Mais, quand il existe, c’est le moyen de gagner sur les deux tableaux : préserver la puissance et l’ambition de la vision architecturale, d’un côté, et accélérer les projets en les guidant vers l’intérêt commun, de l’autre. Ici nous touchons à la complexité de l’entreprise, complexité qui tient, en grande partie, à sa substance mélangée. C’est justement le rôle de la méthode d’analyser la nature de ce matériau, d’en séparer les éléments pour créer les conditions opératoires. La propagande sur les projets agiles, seule, ne peut pas suffire ; le platonisme de l’architecture idéale (top-down…), seul, ne mène nulle part. Il faut combiner les deux.

En résumé

“Refonder l’architecture d’entreprise” : c’est, je crois, ce que nous avons fait ou plutôt, c’est la conséquence presque involontaire de notre approche holistique de l’entreprise : voulant embrasser toute la réalité de l’entreprise et ordonner toutes les informations et les décisions qui la concernent, nous rencontrons, sur notre chemin, les disciplines et nous leurs assignons des responsabilités dans la perspective plus vaste de la transformation.
“Assembler les pratique” : Praxeme s’est toujours présentée comme une approche interdisciplinaire, un cadre pour coordonner les différentes pratiques et un vecteur pour amener les apports scientifiques et les mettre au service de l’entreprise.
Sur l’agilité : le grand sujet n’est pas l’agilité des projets. Au début de années 80, James Martin avait déjà dit l’essentiel avec sa méthode RAD trop rapidement interprétée comme l’autorisation de jeter les modèles par dessus bord. Il faudrait un jour qu’un économiste chiffre le désastre économique qui s’en est suivi. Le grand sujet est l’agilité de l’entreprise, laquelle réclame justement un gros effort d’architecture et une approche rigoureuse.