Disponible sur le site de l’ADELI : https://espaces-numeriques.org/evenement/lundi-11-mars-2019-rencontre-debat-la-transformation-des-si-soa-api-micro-services-comment-sy-prendre/
Le support est disponible sur PraxemeWiki.
Annonce :CONIX lance un nouveau chantier de contribution au fonds Praxeme. Le thème retenu cette année est la conception des indicateurs (KPI).
—Praxeme Institute
Plusieurs apports récents sur ce sujet :
L’ouvrage est paru en 2003 aux éditions AFNOR. Il faisait le point sur les normes et les pratiques de rédaction de plans de projets et de construction des projets. Ces pratiques ne se rencontrent plus, du moins plus avec la même rigueur ou la même systématicité.
La première phrase de la 4e de couverture commençait, sur une note dramatique :
“La qualité est désormais perçue comme une question de survie.”
Les choses ont bien changé, et il y a bien longtemps que je n’ai vu un plan de projet !
On est obligé de penser que la disparition de cette pratique constitue un autre signe du reflux de la rationalité technique, à une époque qui conteste l’acquis des Lumières. Après tout, un texte de 140 caractères fait plus de bruit qu’un rapport de plusieurs centaines de pages.
En tout cas, après avoir vécu quelques rééditions, ce livre est retiré du catalogue, et mis à disposition d’un public irrédentiste.
Voir la page : https://www.praxademia.com/publications/le-plan-qualite-logiciel/
Depuis 2011 (2013 pour la version 2.0.2), nous disposons d’un standard international pour représenter les processus : BPMN (Business Process Model & Notation). C’est une bonne nouvelle… sous quelques conditions.
Contrairement à UML – plutôt moins utilisé aujourd’hui que lors de sa parution en 1997 -, BPMN semble jouir d’une bonne réception sur le marché. C’est toujours une bonne nouvelle quand un standard vient unifier un formalisme et soutenir les pratiques de modélisation. Particulièrement à un moment où les entreprises se préoccupent de leur transformation. Si les principes de l’approche par les processus sont partagés par tous, du haut en bas de la pyramide hiérarchique, cette approche ne peut porter ses fruits que si elle s’appuie sur des représentations précises. BPMN doit nous y aider.
Encore faut-il que le formalisme standard soit utilisé correctement. Or, sa bonne utilisation se heurte à plusieurs obstacles :
Le premier obstacle n’est pas nouveau. Pour le détruire, il suffit de rappeler le niveau de complexité qu’atteignent, aujourd’hui, les chaînes de valeur, et les perspectives de transformations des organisations (notamment, du fait de la technologie). Les améliorations et les changements à venir exigent une maîtrise parfaite de nos processus, pas seulement de leur fonctionnement nominal, mais aussi des circonstances exceptionnelles. Les entreprises doivent donc, au minimum, décrire précisément leurs processus.
Deuxième point, la revendication de simplicité sombre vite dans un simplisme délétère. Elle confond deux moments, que la démarche doit distinguer : le temps de la communication ou de l’exposition ; le temps de la conception (je parle ici de la conception des processus et de l’organisation ; l’élaboration d’un processus exécutable informatiquement est un autre sujet). S’il est légitime de se soucier de la bonne communication vers les acteurs du processus ou les décideurs, il n’en reste pas moins essentiel de disposer d’une bonne description du processus. On ne peut pas sacrifier la qualité de la conception, au souci de la communication. Cette attitude – presque une culture – rend de très mauvais services à l’entreprise. Elle se pare de l’argument de pragmatisme… pour ne pas s’avouer paresse. De plus, un bon usage de la notation permet de concilier les deux aspirations : un modèle de processus peut contenir tous les détails nécessaires, tout en réservant des diagrammes synthétiques qui faciliteront sa communication, l’apprentissage, la prise de décision… BPMN autorise un effet de zoom, fort utile pour concilier ces deux exigences.
Le troisième obstacle résulte d’une réaction bien compréhensible face à la richesse de la notation BPMN : 7 types de branchements, 64 catégories d’événements (sur une matrice de 104), de nombreuses notions dont certaines ne correspondent même pas à des symboles graphiques, etc. Face à cette apparente complexité (le terme “richesse” est préférable), il est tentant de s’épargner l’effort d’apprentissage et d’exclure, a priori, une partie de la notation. Cette tendance est malencontreusement encouragée par la distinction que fait Bruce Silver dans son best-seller, BPMN, Method & Style, entre des palettes de niveaux 1 et 2. Tout à fait justifiée comme progression pédagogique, cette distinction ne vaut rien dans la pratique. Elle se révèle toxique (en ce qu’elle encourage, entre autres, la réduction de l’effort de formation à la palette de niveau 1). Retirer ne serait-ce qu’un type d’événement sur les 64, c’est prendre le risque de se retrouver devant une réalité, sans la bonne solution pour la représenter.
BPMN n’offre pas seulement une réponse unifiée face aux formalismes antérieurs (et aux notations propriétaires). Cette notation comporte aussi des innovations qui vont changer les pratiques de modélisation et la qualité de conception des processus. Ces nouveautés permettent de traiter des situations que les formalismes antérieurs se montraient impuissants à prendre en compte.
Pour illustrer le propos, prenons un exemple utilisé en introduction à mon cours : il s’agit d’une recette de cuisine. Quoi de plus simple, me direz-vous ! Une succession d’actions… Représentons graphiquement ce petit extrait :
Portez à ébullition et laissez bouillir, en ayant soin d’écumer souvent, jusqu’à ce qu’il ne se forme plus d’écume.
(emprunté au site Marmiton) – Voici la représentation à laquelle on arrive spontanément, en général :
L’activité principale, suivie d’un test, puis déclenchement éventuel de “écumer” et retour sur la première activité.
Or, cette représentation ne convient pas du tout. Elle s’interprète comme suit : il faut arrêter la première activité pour évaluer la condition (donc, couper le gaz, puis regarder s’il y a de l’écume) ; le cas échéant, on écume, puis on exécute une nouvelle instance de la première activité (donc, on rallume le gaz). Je ne m’y connais pas beaucoup en cuisine, mais cela me paraît quelque peu aberrant !
BPMN offre un moyen fort simple pour représenter correctement cette situation : l’événement-frontière non interrupteur (de type “condition”, dans notre cas). La notion d’événement-frontière compte parmi les apports de BPMN qui sont méconnus ou sous-exploités – sacrifiées sur l’autel idolâtre du simplisme. C’est fort dommage, car elle fournit le moyen élégant de traiter toutes sortes de situations concrètes, dont les perturbations qui peuvent affecter le déroulement d’un processus.
D’autres notions passent à la trappe, alors qu’elles simplifient le travail du modélisateur, ou même qu’elles rendent possibles la représentation de phénomènes réels. Citons :
Toutefois, si l’objectif est de représenter tout le métier, BPMN révèle vite ses limites. Ce constat soulève un autre point, celui de l’articulation entre BPMN et d’autres notations, pour obtenir un outillage complet de modélisation.
La modélisation des processus a quelque chose de vicieux : elle se prête à toutes les manipulations. Trois symboles sur une diapositive et deux flèches : voilà que le processus existe ! A contrario, un diagramme peut s’étendre sur plusieurs pages, et on s’imagine que la conception est complète… mais on ne peut plus en discuter parce que c’est trop complexe !
Comme nous en avons l’habitude, maintenant, avec les standards de l’OMG, BPMN est un outil puissant, appuyé sur un méta-modèle qui condense le savoir-faire de méthodologues au niveau mondial, mais… ce n’est pas une méthode. Donc, il laisse le praticien démuni, sujet aux sirènes du simplisme, et sous l’influence des marchands d’orviétan. Pour répondre à ses besoins, la meilleure démarche pédagogique consiste à partir du besoin de représentation : que faut-il représenter ? à quel moment ? sous quelle forme ?
Ainsi, le coeur de la formation “BPMN, modéliser les processus” repose sur une logique d’action. Chaque séquence soulève des besoins de représentation, à partir d’une étude de cas qui embrasse de plus en plus large, jusqu’à la dimension “organisation” :
Pour plus d’information sur cette formation : https://www.praxademia.com/formation/modelisation-des-processus/
Prochaine session, du 7 au 9 février 2018 : inscription
Nous sommes heureux d’avoir pu participer, une nouvelle fois, au chantier PxData mené par le cabinet Conix Consulting. Il en résulte un position paper dont les titre et sous-titre exaltent une attitude positive face à la réglementation :
RGPD, une opportunité pour la gouvernance !
La partition Praxeme, un cadre méthodologique pour la direction d’orchestre du DPO
RGPD : règlement général pour la protection des données.
Le message s’appuie sur le cadre de représentation de Praxeme. Le papier illustre l’utilisation du Repère Praxeme pour aborder complètement la problématique de la protection des données et de la réglementation. Il propose, également, le “cockpit du DPO”.
Ce n’est pas la première contribution que l’on doit à Conix Consulting, membre fondateur de l’initiative pour une méthode publique. Nous pouvons lui être reconnaissant pour offrir au public le fruit de son expérience et de sa capitalisation.
Le papier est téléchargeable sur le wiki du Praxeme Institute.
Ci-dessous, un exemple des documents produits par le chantier et expliqués dans le position paper. Les numéros renvoient aux articles du RGPD.
Application du Repère Praxeme à la problématique de la protection des données
Voir le position paper pour des explications. L’analyse y est présentée en deux temps :
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.
Souvenez-vous du scandale qu’a été le “passage à l’An 2000”, et des coûts faramineux pour la société qu’a entraîné la nécessité d’ajouter deux chiffres à une date ! (certes, l’événement était inattendu !)
La communauté informatique a dû, au moins, en tirer la leçon. Quelques doutes nous assaillent, cependant, quand nous entendons que, pour assurer la conformité aux nouvelles réglementations, la première chose à faire est d’inventorier les traitements. Les entreprises s’y mettent dare-dare, mais sans viser l’exhaustivité, car celle-ci paraît hors d’atteinte. (impression de déjà-vu)
…voilà de bons indicateurs des progrès méthodologiques réalisés ces dernières décennies et du niveau de professionnalisme atteint dans la maîtrise des systèmes d’information. Il suffira de faire les comptes. Il suffira de comparer ces sommes aux économies que l’on a cru réaliser en se débarrassant des méthodes et en rognant sur la formation.
Il faudra un peu de rigueur pour assurer la conformité et un peu de créativité pour tirer parti de la pression réglementaire. Les méthodes traditionnelles ou récentes ne suffisent pas, puisque leur horizon est celui du projet et de l’application. Notre sujet réclame une approche globale, celle de l’architecture.
Il s’agit aussi de coordonner différents points de vue :
Cette transformation convoque, donc, toutes les spécialités de l’architecture – métier, organisation, logique, technique, physique -, placées normalement sous l’égide de l’architecture d’entreprise qui doit en assurer la cohérence. L’architecture générale de l’entreprise est, elle-même, dans les mains de la direction générale (si ce n’est pas le cas, autant dire qu’elle ne sert à rien).
La protection des données analysée à travers le Repère Praxeme
Le schéma ci-dessus illustre cette approche. L’analyse intentionnelle révèle des exigences et orientations auxquels doivent répondre des éléments dans les autres aspects de la réalité de l’entreprise. Les flèches pointillées représentent les relations de traçabilité (ou de référence). Par exemple, des paragraphes du RGPD imposent de repérer les informations sensibles. Leur description est formalisée principalement dans l’aspect sémantique de l’entreprise, c’est-à-dire son patrimoine de connaissances. D’autres paragraphes conduisent à mettre en place des rôles et activités particulières, mais aussi à injecter la surveillance dans l’ensemble des processus. Ce travail de conception organisationnelle ressortit à l’aspect pragmatique. Les exigences de la réglementation se projettent ainsi dans tous les aspects de l’entreprise, justifiant les dispositions à mettre en place.
Le schéma ne peut montrer qu’une synthèse de cet effort. Le travail doit être mené de façon plus détaillée, à travers des modèles précis, faute de quoi il est impossible de dominer la complexité de l’exercice. Ici, le dispositif clef est le référentiel de description de l’entreprise.
Cet outillage est bien connu et peut s’appuyer sur des standards internationaux. Quelques compléments sont nécessaires. Les méta-données comme la sensibilité des informations, la finalité de leur collecte et leur durée de conservation s’ajoutent au méta-modèle (= la définition des éléments nécessaires à la description). Ceci peut se mettre en place rapidement. Les fonctions d’historique des données (data lineage) et d’alerte (délai de conservation dépassé) peuvent être traitées une bonne fois pour toutes par la conception logique. Les solutions de sécurité (détection des brèches…) doivent, bien sûr, être systématisées. Le reste est affaire de discipline. En travaillant de la sorte, autour du référentiel de description, l’entreprise dispose d’une description précise de ce qu’elle est et de ce qu’elle veut devenir. En cas d’évolution importante, elle n’aura pas besoin de commencer par un inventaire fastidieux, et pourra aller droit au but.
Recommandations pour les programmes de mise en conformité
Il est, néanmoins, plus probable que les projets de mise en conformité passent par des raccourcis. On dénoncera l’approche présentée ici, comme théorique – c’est le mot généralement utilisé pour exclure tout effort que l’on n’est pas prêt à consentir, effort de compréhension ou de mise en pratique. On préférera court-circuiter les aspects “métier”, “abstraits” : la traçabilité sera établie directement entre les composants logiciels (à grosse maille) et les exigences de la réglementation. On donnera les habituelles justifications économiques, totalement fallacieuses : faire vite, moins cher. Le genre d’argument qui ont conduit au scandale de l’An 2000 et à d’autres gabegies.
Nous saurons bientôt si la communauté a progressé… ou si nous vivons dans un jour sans fin.
Ou : « EBX fait le buzz »
Le cabinet Gartner vient de publier son Magic Quadrant pour les solutions de Master Data Management. L’étude place la solution EBX, d’Orchestra Networks, dans la catégorie des « Leaders » (elles ne sont que deux solutions dans cette catégorie).
On s’étonnera que des noms plus prestigieux soient confinés dans la zone des acteurs de niche. Une raison probable est la spécialisation des solutions par domaine. Pour le vendeur, une telle spécialisation s’est longtemps montrée rentable :
Permettez-moi de vous raconter une anecdote. Il s’agit d’un gros projet de MDM, dans une compagnie d’assurance japonaise. Tout de suite, le projet est scindé en deux sous-projets, chacun sur un domaine précis : l’un sur les données des clients, l’autre sur celles des fournisseurs. Un seul prestataire est retenu, qui propose une solution pour chacun des domaines.
En revue d’architecture, quelqu’un pose la question naïve : au fait, quand on y pense, est-ce qu’un client – individu ou organisation – ne présente pas des points communs avec un fournisseur ?
Il va de soi que, dans une approche de modélisation sémantique, « client » et « fournisseur » sont considérés comme des rôles, et que le modèle place, en son centre, le véritable objet : l’entité. C’est uniquement dans sa relation à un contrat ou à un engagement que l’entité revêt tel ou tel rôle. D’ailleurs, une même entité peut être, pour une entreprise, à la fois un client et un fournisseur, ou un client et un collaborateur, etc.
De là, l’idée toute simple qu’un seul référentiel pourrait couvrir toutes les entités, quels que soient leurs rôles, réduisant ainsi la redondance du système (donc les coûts d’investissement et de fonctionnement, la lourdeur, les risques, etc.).
Pendant cette revue d’architecture, tout le monde tombe d’accord sur cette évidence. Mais trop tard…
Faute d’avoir aperçu cette idée toute simple, on en arrive à ce paradoxe : alors que la démarche MDM a pour but d’augmenter la maîtrise du système, ce qui passe par une réduction de la redondance, le projet n’a fait que l’accroître. Passe encore que nos systèmes aient accumulé une redondance effarante au cours de leur histoire : on en connaît les raisons. Mais que, au moment de reconstruire, les mêmes erreurs se reproduisent… il n’y a pas d’excuse. Cela ressemble fort aux logiques perverses que Jacques Généreux dénonce dans « La déconnomie » à propos des politiques économiques.
Orchestra Networks, en tant que « pure player » depuis son origine, a évité cet écueil. N’étant pas inféodée à d’autres intérêts, la solution a toujours et forcément été multi-domaine. Ce n’est pas un hasard, d’ailleurs, si Orchestra Networks compte parmi les fondateurs du Praxeme Institute. D’aucuns y verront le signe d’une communauté culturelle profonde.
Une entreprise qui voudrait améliorer radicalement son système informatique, comme le prône Praxeme, trouverait dans EBX la solution parfaite. Elle lui permettrait de restaurer l’unité de ses données, et de se rapprocher de la pureté sémantique. Cette étape est nécessaire pour simplifier le système et recouvrer une créativité qui a bien déserté le domaine de l’informatique.
Dans un sens, on peut voir, dans la destinée d’Orchestra Networks, une belle illustration de la « French Tech ». Dans l’esprit : plutôt que concevoir des solutions tactiques qui traitent partiellement le sujet, penser une solution globale et pragmatique… et s’y tenir
Lien vers l’étude de Gartner : http://www.orchestranetworks.com/gartner-mdm-magic-quadrant/.
La transformation est une des grandes préoccupations des compagnies d’assurance, grandes et petites. Souvent réduite à sa dimension technique (transformation numérique ou digital transformation), elle touche néanmoins tous les aspects de cette activité, entraînant quelques difficultés à agir et à penser.
Quelques réflexions, appuyées sur une longue expérience du secteur et prolongées par des recommandations de mise en oeuvre ont été réunies dans ce papier :
Elles feront l’objet d’une intervention lors du Symposium Praxeme.
