DVau

La semaine dernière, le président d’une grande entreprise demandait à ses employés de renoncer à une partie de leur salaire, pour améliorer la santé de l’entreprise. Lui-même annonçait qu’il renoncerait à un mois de salaire.
Evidemment, l’annonce a soulevé la polémique : renoncer à une partie de son salaire est plus facile pour un grand patron dont les revenus annuels se chiffrent en millions, que pour un ouvrier payé au salaire minimum…
Je ne veux pas, ici, poser ce problème sur le registre de la lutte des classes - encore que ce ne soit pas forcément la plus mauvaise façon d’aborder la question. Ce qui m’intéresse et qui rentre dans la réflexion méthodologique, c’est l’impact du statut des dirigeants sur le fonctionnement de l’entreprise et de la société.

Cette affaire m’a remémoré une anecdote similaire, vécue dans un autre contexte. Peu de temps après la catastrophe du tsunami, le PDG d’une entreprise fit diffuser à ses employés un e-mail dans lequel il annonçait qu’une fraction de leurs intéressements serait prélevée et versée en faveur des victimes. La contestation de cette décision fut instantanée, non par manque de charité (beaucoup avaient déjà donné), mais en réaction au mode de décision unilatéral. Après quelques jours, un nouveau message du président parvint aux employés. Il y expliquait, sur un ton amer, qu’il avait consulté avant de prendre cette décision. A n’en pas douter, cette consultation n’avait pas dépassé le premier cercle du pouvoir, cercle composé d’individus sélectionnés en partie pour leur docilité et qui n’ont aucune notion du rôle de représentation qu’un manager devrait assumer vis-à-vis de ses collaborateurs. Le message se terminait par une phrase désabusée : “Cet épisode m’aura appris beaucoup sur l’humanité”. Si seulement cela lui avait appris quelque chose sur lui-même et sur son mode de management !

Le point commun entre ces deux exemples réside dans la position du dirigeant, manifestement coupé de sa base. Cette situation est commune dès que l’entreprise dépasse la taille d’une PME (parfois même avant). La taille seule n’explique pas le phénomène. Plusieurs facteurs contribuent à faire du manager un être isolé dans une espèce d’Olympe, à commencer par le niveau de rémunération. Comment peut-on se sentir l’égal des autres et leur représentant quand on gagne plusieurs centaines de fois plus qu’eux ? La sacralisation du pouvoir renforce cet isolement : signes matériels, privilèges, mise en scène des apparitions, culte du chef orchestré par la direction de la communication, etc.

La conséquence la plus grave, outre un sentiment d’injustice sociale, est que le mode de communication et la prise de décision sont perturbés. Puisque le chef est au-dessus de tous, si loin, si haut et si compétent, la vérité ne saurait être qu’au sommet. Dès lors, la relation hiérarchique se révèle dissymétrique, pas seulement pour la décision mais aussi pour l’analyse. L’écoute ne fonctionne plus : seul parle le supérieur ; lui-même se tait en présence de son n+1 et ainsi de suite tout au long de la ligne hiérarchique.

C’est ainsi que le dirigeant devient un être à part. Dans les bons moments, il jouit de l’admiration ou, au moins, d’un respect sacré. Cependant, quand les temps sont durs et qu’il faut faire appel à la conscience collective, ce demi-dieu est plus perçu comme un profiteur, coupé de la base. C’est lui et eux, et bientôt lui contre eux. La coupure est nette. Les appels à la moralité et à l’intérêt général sonnent faux et perdent en efficacité.

Au bout de cette logique qui conduit à séparer nettement le dirigeant, l’entreprise devient comme un corps dont la tête a été détachée. Dans cette entreprise décapitée, la communication perturbée ne permet plus d’irriguer le corps social.

La crise nous donne l’occasion de reprendre ces réflexions sur des sujets refoulés sous la chape de plomb de la censure et de l’auto-censure, dans l’entreprise. Cependant, les mauvais effets dans l’entreprise décapitée ne se limitent pas aux temps de crise ; ils sont quotidiens et s’observent en tout temps.

Dans la conférence S-IT-A (voir note précédente), j’évoquais rapidement le philosophe Francis Fukuyama. Je dois avouer avoir été injuste à l’égard de ce penseur, auteur de La Fin de l’histoire et le dernier homme.

Sans partager sa thèse, il faut reconnaître qu’elle est moins naïve que le rapide résumé que l’on peut en faire. Au moins, cet ouvrage a eu le mérite de remettre en scène un de nos plus grands philosophes, Hegel.

Les vidéos des Assises 2009 de la communauté Sustainable IT Architecture :

• résumé disponible sur TV4IT ;
• toutes les présentations sur le site de S-IT-A ;
• conférence de Dominique Vauquier sur le thème “Méthodologie d’entreprise et transformation du SI en crise“.

A noter : une version commentée de cette présentation a été déposée sur ce blog (3 mars 2009).

Quelques rapides éléments de réflexion sur ce thème.

Style des spécifications fonctionnelles

Aujourd’hui coexistent deux grands types d’expression de besoin :

1. classique, essentiellement spécifications textuelles en langage naturel, éventuellement « rigidifiée » par des structures de tableaux ou de renvois (si possible appareils de lecture automatiques) ;
2. avancé, avec tentative de formalisation pour assurer une meilleure qualité de spécification (réduction du volume, élimination des ambiguïtés, preuve de couverture…).

Ce deuxième style tire profit de la notation UML. Dans ce cas, la spécification se centre sur la notion de cas d’utilisation, qui reste marquée par l’approche fonctionnelle.
Certains dossiers d’expression de besoins se situent à cheval entre ces deux styles : ils adoptent une partie du vocabulaire UML (use-case) mais délaissent la notation et trahissent l’inspiration.

Les pratiques avancées structurent les dossiers d’expression de besoin, du moins la partie « fonctionnelle », en termes de cas d’utilisation, détaillés en scénarios et structurés par un vrai diagramme des cas d’utilisation.

Posture

Ce dernier point soulève une difficulté : dès que l’on introduit une technique de modélisation (ici, le seul diagramme des cas d’utilisation) pour relayer ou structurer l’expression textuelle, le rédacteur se trouve mis en demeure d’opter pour une des postures d’analyse ou de conception.

Traditionnellement, l’expression de besoins ressortit à l’analyse, uniquement : le rédacteur a pour tâche de décrire une réalité ainsi que des attentes. Mais, s’il se met en tête d’utiliser son outil de modélisation pour bien structurer son dossier, il commence à changer la structure du problème posé, en vue d’évacuer la redondance, d’augmenter l’agilité, etc. Ce travail l’amène à entrer dans la conception et donc, à s’écarter de la fidélité aux acteurs « métier ».
Cette frontière est déjà franchie quand on introduit, dans le dossier, des maquettes d’écrans – fussent-elles serviles et collées à l’existant.

Cette hésitation entre analyse et conception doit faire l’objet de toutes les attentions car la posture adoptée détermine le rôle du livrable dans la chaîne de transformation.

Place dans la chaîne de transformation

Ainsi, on ne peut pas élaborer le procédé d’expression des besoins en faisant abstraction de la chaîne de transformation dans laquelle il s’insère.
Le template même de Business Requirement dépend de ce qui se passe en amont et en aval.
Par exemple, un dossier peut mentionner les données (ce qui est un peu réducteur, soit dit au passage). Si la rédaction des exigences est précédée d’un effort de modélisation des objets « métier » (objets auxquels sont reportés les règles de gestion, les cycles de vie, etc.), le contenu du dossier de spécification s’en trouvera allégé.
De même, si le dossier est clairement perçu comme une expression d’analyse, le diagramme des cas d’utilisation qui s’y trouve sera considéré comme tel, ni plus ni moins. On prendra soin de ne pas considérer ce diagramme comme la structure de la solution. Il faudra, avant la réalisation, prévoir l’effort de conception, lequel produira un nouveau dossier des cas d’utilisation. Dans ce dossier de conception, on verra apparaître sur le diagramme des cas d’utilisation les relations qui permettront une bien meilleure structure.

Pour y voir clair dans la définition des livrables, le mieux est de croiser les deux critères :

1. Visibilité : externe (ce qui est perçu par les « utilisateurs » du système) versus interne (la solution, derrière la vitrine) ;
2. Posture : analyse (description du réel, sans intervention ; le rédacteur est à l’écoute des acteurs du système et en retranscrit les pratiques et les attentes) versus conception (imagination, invention d’une solution, y compris sur les aspects « métier »).

Quelles sont les conséquences de l’approche SOA sur l’organisation ?
Elles sont réelles et nous les avons expérimentées sur les projets. Il faut d’abord dire qu’il y a une ambiguïté fondamentale dans l’expression “projet SOA”. SOA est une approche d’architecture ; elle considère donc l’ensemble du système d’information. A l’opposé, un projet a toujours une portée limitée : il livre une application, répond à un besoin, est financé ou sponsorisé par une direction… Cette différence de portée entre l’approche SOA, d’un côté, et le mode de production par projets, de l’autre, appelle des dispositions particulières.
Ce thème a fait l’objet d’un chapitre du livre “Le système d’information durable”, chapitre qui n’a finalement pas été publié. Il vous est livré, ici : L’organisation de la DSI.

Sur la notion de portée, voir le Livre blanc (”SLB-02″) disponible sur le site www.praxeme.org.

Vous le savez, Praxeme ambitionne d’être une méthodologie d’entreprise, c’est-à-dire qu’elle prétend couvrir tous les aspects de l’entreprise, y compris sa réalité humaine et sociale.
Nous avons l’intime conviction que les sciences sociales peuvent nous aider à mieux penser nos solutions, tout particulièrement quand nous abordons l’aspect “pragmatique”, l’organisation et les processus.
L’apport ne se limite pas à cela : certains champs d’investigation de la sociologie portent sur les processus de décision ou les informaticiens eux-mêmes et la façon de construire les systèmes.

Pierre-Henry GOMONT termine une thèse de sociologie après une année d’observation du “terrain” AXA Group Information System. Il a accepté d’animer un atelier, selon notre formule “Praxeme et…”.

Ordre du jour indicatif :

• Introduction rapide pour situer la sociologie par rapport à Praxeme (DVAU)
• Introduction à la sociologie des organisations
• Point sur la sociologie des systèmes d’information

L’atelier se tiendra le 26 juin, de 14h30 à 17h30,

avec le soutien du groupe AXA.

Exceptionnellement, le Praxeme Institute ouvre cet événement au public.

Inscription obligatoire par ce lien : mailto:info@praxeme.org?subject=PxATL2B
Date de clôture des inscriptions : 19 juin.

Le lieu (Paris intra muros) sera communiqué aux inscrits une semaine avant l’événement.

Pour guider les travaux au sein de nos Collèges :

Besoin de distinguer trois types de documents, correspondant à trois niveaux de lecture :

1. le guide méthodologique - sur les justifications de la méthode, les principes sous-jacents, l’effort de rationalité… bref, de la philosophie (mais philosophie de l’action) ;
2. le document méthode ou la fiche méthode - qui, sur la base des principes, fournit la check-list que cherchent les opérationnels ;
3. la fiche outil - mode d’emploi qui traduit le document méthode (souvent, procédé) dans les termes d’un outil donné.

Il est essentiel de respecter cette typologie pour une bonne gestion du corpus documentaire. Chaque type de document intéresse des profils différents. Le style de rédaction diffère selon les types : du plus rédigé et argumenté au plus “pratique”. Les compétences des rédacteurs, également, changent d’un type à l’autre, associées respectivement aux métiers de méthodologue, d’ingénieur méthodes et d’outilleur.

Les documents méthodes ne doivent pas être marqués par un éditeur. Ils peuvent, en revanche, se référer à des standards (comme UML ou BPMN).

Passé le moment fugace de l’exaltation, nous sommes, assez naturellement et en vertu de la loi du moindre effort, enclins à éviter l’action. Comme à chaque fois que l’imaginaire populaire se trouve saturé par l’image de la crise, le prétexte est tout trouvé. Dans nos métiers, en tout cas, c’est une réponse facile et imparable pour éloigner les importuns :

• Monsieur, nous n’avons pas besoin de vos services, avec la crise les budgets ont été revus !
• Refondre le SI, vous n’y pensez pas ! Nous avons d’autres urgences.
• En pleine récession, pas question de perdre du temps à repenser l’organisation. On ne change pas l’équipage pendant la tempête…

Notez que, quand ce n’est pas la crise, d’autres arguments sont toujours à portée : le poids de l’existant, la stratégie d’outsourcing, l’orientation ERP, etc. Tout pourvu que l’on échappe à l’angoisse de la page blanche (sur la planche à dessin de l’architecte).
Cette remarque ouvrait la conférence “Méthode d’entreprise et transformation du système d’information en crise”, donnée le 30 avril à l’occasion des Assisses de la communauté Sustainable IT Architecture. Cela a été l’occasion d’aborder le thème :

Méthodologie et politique

La méthodologie d’entreprise doit-elle traiter de politique ?
Il ne s’agit pas de renoncer à l’exigence de rationalité qui caractérise la méthodologie. Au contraire, il est possible et souhaitable de transporter cette rationalité dans la cité et de l’exercer sur les problèmes du monde. Une partie des facteurs qui ont conduit à cette crise se trouve dans l’entreprise et les comportements que l’on y observe. Il est temps de s’y attaquer autrement qu’avec des discours moralisateurs et sans lendemain. Si nous voulons agir, la méthode nous y aidera.
La présentation commentée : Méthode d’entreprise et transformation du SI en crise

Politique et architecture d’entreprise partagent une même capacité à penser contre l’évidence massive et démoralisante.
Voilà un bon remède à la crise !

Je réponds, ci-dessous, à quelques questions qui nous ont été adressées suite à la parution de l’ouvrage “Sustainable IT Architecture”.

a) Pourriez vous nous donner votre perspective sur l’etat d’avancement de Praxeme (lien avec Togaf, Traduction, Adoption, support éditeurs/outils…)

L’initiative pour une méthode publique se fonde sur les guides méthodologiques publiés sur le site www.praxeme.org. Ce socle est solide et s’appuie lui-même sur un méta-modèle qui clarifie les notions. Il nous reste à :

1. compléter cette base théorique en formalisant ce que nous nommons le cadrage (scoping) ;
2. élaborer le détail de la méthode (modes opératoires) à destination des opérationnels.

Le “cadrage” - que nous présentons maintenant comme l’aspect “politique” - se définit comme l’ensemble coordonné des expressions qui circulent dans l’entreprise sans pouvoir faire l’objet d’une formalisation complète. Il s’agit d’abord des objectifs (stratégie, vision, opérations) mais aussi des valeurs et, bien sûr, des vocabulaires et exigences, tout ce qui va être ensuite repris et tracé à travers les modèles jusqu’au déploiement.
Au sein du Praxeme Institute, c’est le Collège des médiateurs qui prend en charge cet aspect. Il s’intéresse également à la “maîtrise d’ouvrage”. Ce travail est important pour corriger l’image de Praxeme réduite à une méthode pour la conception des systèmes d’information. Notre ambition est bel et bien d’élaborer une méthodologie d’entreprise qui réponde au besoin essentiel des entreprises aujourd’hui : articuler les expertises. A cette fin, il nous faut un cadre complet, qui couvre tous les aspects du “Système Entreprise”, à commencer par la perception qu’en ont ses dirigeants.

L’élaboration des méthodes et procédés se fait au fil des opportunités, dans les sociétés contributrices. Par exemple, des travaux se poursuivent sur la modélisation sémantique, la modélisation des données et la conception des services. AXA Group démarre, ce mois-ci, une initiative sur ces sujets, ce qui permettra de reprendre différents documents et de les publier (par exemple, la dérivation du modèle sémantique en modèle logique des données).

En ce qui concerne TOGAF, l’articulation est claire et a été plusieurs fois exposée (cf. SLB-23, support d’une conférence pour l’association des DSI de Singapour, accueillie par Sun Microsystems). Il nous faudrait maintenant, au-delà des contacts personnels, établir la connexion officielle avec l’Open Group.
La traduction se poursuit sur une base de bénévolat, notamment en collaboration avec l’INSA de Rouen. Nous allons lui dédier un budget, en vue surtout d’accélérer l’évolution du site.

L’adoption progresse de façon évidente mais aussi de façon souterraine :

• adoption visible : le succès de la formation condensée “Praxeme en deux jours” en témoigne (certaines sociétés ou organisations ont envoyé plusieurs personnes en vue de préparer des projets) ; autre indice, Praxeme est introduit dans la formation des architectes du groupe AXA (cible : quelque 200 architectes répartis dans la cinquantaine de compagnies que compte le groupe) ;
• moins visible : les idées de Praxeme sont reprises dans d’autres travaux ou des formations publiques, sans que l’origine en soit toujours mentionnée - au mépris de la protection creative commons ; des cabinets de conseil répondent à des appels d’offres avec Praxeme, sans que leur engagement dans l’initiative ait jamais été formalisé.

Enfin, en ce qui concerne le support des éditeurs et vendeurs, outre les soutiens fidèles comme Softeam, Orchestra Networks, Ilog, Prima Solutions, Sun Microsystems… on peut noter la récente création d’une librairie Praxeme dans l’outil d’architecture Abacus.

b) Même question sur ACMS. Comment l’idée est elle perçue dans les départements informatiques? Quelles sont les difficultés rencontrées? Quels sont les problèmes qui sont de bons candidats pour introduire les concepts d’ACMS?

Une question pour Pierre Bonnet, notre vibrionnant chargé de la communication et spécialiste incontesté du MDM.
Personnellement, je pense que l’ACMS est une puissante idée - pas seulement marketing - et que nous devrions travailler sur sa base théorique. Celle-ci pourrait avoir des conséquences sur les méthodes. Par exemple, on ne peut pas modéliser de la même façon, sachant que nous avons la possibilité recourir à ces dispositifs d’agilité.
Praxeme contient une “théorie de la convergence” (pour la fédération des entreprises) où l’ACMS intervient.

c) Quelle est votre perspective sur l’évolution des concepts informatiques tels que SOA? ainsi que de l’évolution de l’industrie elle-même (consolidation autour d’Oracle, IBM, Microsoft)

Je me contrefiche des mouvements du marché et des manipulations capitalistiques. Ce n’est pas là que se joue la grandeur de notre métier. Au contraire, c’est contre ces empires et contre leur influence patente dans le processus de décision des entreprises que nous devons penser et imaginer les systèmes futurs. La mainmise d’une poignée d’acteurs surpuissants sur les moyens de communication dans notre corporation entraîne de graves distorsions dans notre manière même d’envisager les systèmes.

Pour SOA, je pense qu’il n’y a plus de débat : ce style d’architecture apporte de la valeur, quand il est correctement appliqué ; Praxeme fournit la méthode rigoureuse pour en tirer parti ; la seule question, maintenant, est : a-t-on la volonté d’y aller ? Juste un point : les DSI, même quand elles ont adopté ce style pour leur SI, n’en ont pas encore tiré toutes les conséquences organisationnelles.
Nous avons toujours défini SOA comme un style d’architecture (plus précisément : un style d’architecture logique, une certaine façon de structurer les systèmes informatiques). Le Guide de l’aspect logique propose les règles pour SOA. Maintenant, il nous faut nous intéresser à d’autres styles : EDA, conception par agents… C’est un service à rendre à la communauté qui risque, une nouvelle fois, de sombrer dans la plus grande confusion. Le mélange des styles - qui débouche sur le baroque - sera très difficile à maîtriser, sur le terrain. Mélanger plusieurs styles d’architecture logique, c’est mettre le concepteur face à plusieurs choix possibles pour une même question. D’où, perte de temps et risque d’hétérogénéité.

d) Fait-on des progrès sur la modélisation des systèmes?

La question est sensible. La formation des compétences dans ce domaine n’a pas recouvré le niveau qu’elle avait il y a deux ou trois décennies. De plus, elle se heurte à différents phénomènes propres à notre civilisation. En revanche, parmi les signes positifs, nous pouvons observer un net regain d’intérêt pour la modélisation. L’approche MDM, d’ailleurs, démontre assez clairement le besoin de “bons” modèles. L’approche des processus est en train de s’essouffler ; elle retrouvera une nouvelle jeunesse en réactivant son inspiration originelle et en se mariant à d’autres approches, comme la modélisation sémantique. Sa capacité d’innovation est à ce prix.

On peut évoquer aussi, l’intégration possible dans la méthodologie de savoirs tels que :

• terminologie et ontologie (travaux en cours avec des professeurs-chercheurs : Christophe Roche, Université de Savoie, équipe Condillac, Porphyre ; Loïc Depecker, Sorbonne, Société française de terminologie) ;
• sociologie (des organisations, des techniques - thèse en cours, associée à Praxeme - et de l’innovation : Laboratoire Techniques, Territoires et Sociétés, École des Ponts et Chaussées, Université Marne-la-Vallée).

slb25-eameth Présentation (référence SLB-25) pour une conférence sur le thème “Enterprise Architecture: a method - How a comprehensive approach of the enterprise can really change our systems“.

Introduction de la conférence

Je commencerai par des évidences :

• principe d’abstraction (separation of concerns) ;
• nécessité d’un frameworkpour identifier les niveaux de préoccupation ;
• enchaînement des modèles.

Évidences ? Si on observe les pratiques, force est de constater qu’il n’y a pas toujours recouvrement entre les évidences du génie logiciel et les habitudes de travail !

Questionnement :

Quel framework utiliser ? Le fameux framework de Zachman que tout le monde cite et que personne n’applique ? Les quatre plans de représentation mis en avant par la plupart des courants de l’Enterprise Architecture ?

Le premier modèle prescrit est, dans presque toutes les méthodes, le modèle des processus “métier”. Très bien. Nous avons besoin de cette représentation de l’activité de l’entreprise. Une remarque toutefois : cette représentation était rangée, dans les méthodes traditionnelles, au niveau “organisationnel”. Effectivement, les acteurs y interviennent. On transporte dans les modèles de processus de nombreux présupposés organisationnels. Or, ces mêmes méthodes identifiaient un niveau plus abstrait : le niveau conceptuel. Il semble avoir disparu de nos pratiques et même de nos méthodes. Curieux, non ?

Vous devinez la suite. Le framework mis au point dans Praxeme :

• prend en charge le patrimoine méthodologique et en tire le meilleur, en l’actualisant ;
• tient le milieu entre les 30 cases du frameworkde Zachman et les 4 plans de l’Enterprise Architecture ;
• met en œuvre le standard MDA, jusqu’au détail des règles de dérivation permettant de passer d’un modèle à l’autre ;
• positionne précisément SOA et propose les procédés nécessaires à sa mise en œuvre ;
• ajoute la pré-modélisation (scopingou cadrage), de façon à couvrir toute la chaîne de transformation, de la stratégie au déploiement.

Évidemment, une présentation d’une demi-heure embrassant un domaine si vaste donne toujours une impression de théorie (et vous connaissez la répugnance générale que cela suscite). Pourtant, les Praxemiens savent bien qu’à chaque moment de cette chaîne, la méthode propose des procédés très précis, éprouvés sur plusieurs projets.

On peut se demander si une telle rigueur a encore sa place dans notre milieu professionnel. C’est une question qui sera débatue lors des Assises S-IT-A, le 30 avril 2009, sous le titre : “Méthode d’entreprise et transformation du système d’information en crise - La méthodologie d’entreprise doit-elle traiter de politique ?”.