Le vocabulaire technique se renouvelle, pas forcément les principes d’architecture logique qui doivent nous mener à trouver la structure optimale d’un système informatique.
Quelques ressources pour guider vos travaux pour améliorer les systèmes informatiques :
Un investissement est en cours pour rédiger le guide “Approche de l’aspect logique” en version 2 de la méthode Praxeme, ainsi que les procédés de conception logique.
Les indicateurs de performance et les tableaux de bord se sont répandus dans tous les secteurs d’activité. Pourtant, les critiques formulées dès les années 70 se sont précisées et renforcées (de la dénonciation de la « quantophrénie » par le sociologue Vincent de Gaulejac jusqu’au récent ouvrage « The Tragedy of metrics » de l’historien de l’économie Jerry Z. Muller). Il en va des métriques comme des droits humains : on peut certainement mener une critique de leurs usages, origines, biais… mais cette critique ne doit pas les éliminer ; elle doit plutôt les renforcer, en les refondant, en les protégeant des déviations et en rendant plus rigoureuse leur pratique.
Ce sujet devait, un jour ou l’autre, être abordé dans le cadre de l’initiative pour une méthode publique. C’est chose faite avec la publication du document « Les procédés métrologiques ». Cette nouvelle contribution de CONIX pose les bases de la métrologie d’entreprise, et introduit les procédés métrologiques qui vont de la conception des indicateurs à leur mise en œuvre.
Partons d’une illustration. Nous récapitulerons ensuite les principaux messages qui caractérisent l’apport de Praxeme à cette discipline.
Une illustration
Prenons le tableau de bord d’une voiture. La notion de tableau de bord est ici très concrète. Elle fournit, d’ailleurs, l’origine de la notion de tableau de bord en entreprise, par rapport métaphorique.
Le tableau de bord d’une voiture affiche, somme toute, peu d’informations : la vitesse, le nombre de tours/minute, le niveau de carburant, un indicateur de feux allumés, un signal de clignotant activé. Il y a des variantes. Par exemple, le tableau de bord peut indiquer la vitesse à passer.
Bien sûr, il n’est pas question d’afficher trop d’informations et de risquer la surcharge mentale ou la distraction du conducteur. Pourtant, bien d’autres mesures et informations décrivent la réalité de la voiture et de la conduite. Certaines, d’ailleurs, se trouvent sur les applications fournies sur smartphone. Par exemple :
la limite de vitesse sur la portion de route où l’on se trouve, et le signalement de son éventuel dépassement ;
la consommation instantanée de carburant, déterminée par les conditions de vitesse et de pente ;
la consommation lissée sur la distance, révélatrice du style de conduite ;
cette même consommation rapportée au poids du véhicule (information permanente), à la charge (variable), à la puissance ou au type de moteur, etc.
la portion de cette consommation due à des usages annexes, comme le chauffage ou la climatisation ;
la distance par rapport aux plus proches véhicules en avant et en arrière ;
le nombre de personnes convoyées, à introduire dans l’évaluation économique du trajet ;
la production des gaz d’échappement (CO2, particules…).
Si la consommation de carburant n’est pas une information suffisamment percutante pour inspirer une conduite responsable, on peut l’exprimer en montants financiers. Son analyse peut renvoyer à des styles de conduite, à des comportements types. De même, les nuisances sonores produites…
En élargissant à l’intention du déplacement et à la préoccupation environnementale, on pourrait ajouter :
l’état du trafic,
le temps prévu pour le trajet, en distinguant : le temps « utile » du déplacement, les temps d’attente liés aux conditions de circulation, le temps mis à trouver une place de stationnement ;
les moyens alternatifs de déplacement et l’évaluation en temps et en argent des différentes solutions ;
le taux d’occupation moyen des véhicules sur le même trajet…
On peut penser encore au signalement des radars ou de la présence policière, mais alors, on rencontre un problème éthique : ces moyens de sécurité routière sont perçus comme des obstacles à déjouer ; leur absence est alors interprétée comme une impunité à contrevenir aux règles communes.
Allons plus loin, encore, dans le but de faire prendre conscience des conséquences à plus long terme des comportements. Ajoutons :
le niveau de bruit et sa contribution aux nuisances sonores (bruit du moteur, bruit causé par le roulement, musique, avertisseur) avec les limites prévues par la loi (tapage diurne, tapage nocturne) ;
la contribution à la pollution immédiate et à ses effets sur la santé (particulièrement aux abords des écoles) ;
la contribution à la pollution à long terme et au réchauffement climatique.
En conclusion de cette illustration :
Une approche métrologique sérieuse identifie de nombreuses métriques.
Rien de ce qui se mesure n’est étranger à la rationalité.
La sélection de métriques pour les exposer à travers un tableau de bord répond à des intentions qu’il convient d’élucider. Elle révèle ou trahit, plus ou moins directement, des présupposés et des valeurs.
La construction des indicateurs peut aider à sensibiliser à des conséquences lointaines. Elle peut devenir un moyen pour lutter contre l’inconséquence.
L’inconséquence est l’ignorance des conséquences de nos actes. Masquée par les déclarations de vertu, elle est le plus grave fléau qui assombrit notre avenir.
La métrologie d’entreprise
La métrologie d’entreprise est la discipline qui perçoit l’entreprise en termes de métriques, et aide à l’analyser en s’appuyant sur les mesures.
Il est essentiel, dès l’abord, de bien marquer la différence entre :
cette discipline qui cherche à aborder rationnellement et objectivement l’entreprise ;
la formulation des objectifs, aux niveaux collectif ou individuel, laquelle peut éventuellement s’appuyer sur les indicateurs.
Cette deuxième activité ressortit à une autre discipline, que nous pourrions nommer la téléologie d’entreprise, et qui revient au management.
L’essentiel des critiques adressées aux tableaux de bord, loin de condamner la mesure en elle-même, dénonce le détournement opéré au moment de fixer des objectifs. Le premier défaut des tableaux de bord tient à leur étroitesse : en sélectionnant et en mettant en relief quelques indicateurs seulement, on nie la complexité de la réalité, et on conditionne les acteurs à gruger le système. Nous sommes face à un paradoxe : d’un côté, tout le monde s’accorde sur le constat de la complexité ; de l’autre, on prétend se contenter d’une poignée d’indicateurs pour piloter cet objet complexe qu’est l’entreprise.
Certes, il ne sert à rien d’afficher, à chaque instant, toutes les mesures imaginables : le pilote ne pourrait rien en faire ; cela pourrait même représenter un risque. Simplement, nous devons prendre conscience que :
Un tableau de bord, sélection des métriques possibles, se limite à une toute petite fenêtre sur la réalité de l’entreprise et de son environnement.
Il est construit pour un usage précis, par exemple le suivi opérationnel, mais laisse échapper, forcément, de nombreux facteurs.
Il est donc nécessaire de détecter les situations qui rendent le tableau de bord caduc.
À ce moment-là, le pilote doit pouvoir s’extraire de sa routine et, le plus rapidement possible, accéder à une vision plus large et documentée sur la situation.
C’est ainsi que nous devons mettre en place un véritable modèle métrologique, un ensemble structuré de centaines, peut-être de milieu de métriques, susceptible de capturer une part significative du réel. Quand nous prétendons en faire l’économie, nous courrons le risque de manquer les phénomènes.
Les orientations de l’approche métrologique dans Praxeme
Les paragraphes qui suivent résument les positions de la méthode publique quant à la conception des indicateurs et, plus largement, à la métrologie d’entreprise. Le fait d’insérer cette discipline dans l’ensemble plus vaste des disciplines liées à la conception et à la transformation des entreprises représente un atout et augmente les retombées.
La notion de modèle métrologique : nous pensons qu’un tableau de bord de quelques dizaines d’indicateurs est insuffisant pour comprendre le comportement de l’entreprise ; ces tableaux de bord sont nécessaires pour le pilotage courant, mais insuffisants pour comprendre l’entreprise et appréhender sa complexité. Le modèle métrologique est un ensemble structuré de métriques qui ambitionne de rendre compte de la réalité de l’entreprise et de son environnement. Les tableaux de bord en sont des extraits, orientés sur les besoins des décideurs et des responsables. Ceux-ci doivent être conscients des limites d’un tableau de bord, lequel n’est qu’une fenêtre étroite sur la réalité. Dans certaines circonstances, il est nécessaire d’embrasser du regard un paysage plus large.
Les champs d’analyse : nous entendons toujours parler d’indicateurs de performance ; c’est qu’il y a des indicateurs qui portent sur autre chose que la performance. Praxeme fixe les champs d’analyse : le fonctionnement du Système Entreprise (dont sa performance), le développement de ce système (dont la qualité organisationnelle et architecturale), l’environnement du système (risques et opportunités du marché). Ces trois champs d’analyse appellent des procédés différents pour concevoir les métriques.
Les trois champs d’analyse
Les relations entre les métriques : un modèle métrologique et un tableau de bord diffèrent non seulement par le nombre de métriques rassemblées, mais aussi par les relations que le modèle pose entre les métriques. Ces relations sont de deux types : construction et corrélation. Les relations de construction reposent sur les fonctions arithmétiques et statistiques ; elles rendent compte de l’assemblage des données élémentaires en indicateurs significatifs, plus faciles à interpréter. Les relations de corrélation formulent ou vérifient des hypothèses sur la causalité entre plusieurs facteurs de la réalité. Ces relations se montrent à travers des diagrammes métrologiques, et s’assortissent des formules de calcul.
Les heuristiques : les procédés métrologiques apportent essentiellement des techniques pour trouver les métriques. Le terme « métrique » est préféré, car plus neutre que celui d’indicateur et évoquant une approche systématique. Une question cruciale est celle du point de départ pour trouver les métriques. La méthode en propose plusieurs.
Une approche systématique : les procédés métrologiques permettent de trouver des milliers de métriques et de les assembler en une hiérarchie qui s’élèvent jusqu’à des indicateurs synthétiques associés aux grandes préoccupations de l’entreprise. Imposer un nombre maximum d’indicateurs revient à nier la complexité de l’entreprise et de son environnement. Une telle attitude conduit à prendre des risques inconsidérés.
Une sélection pragmatique des indicateurs : pour autant, on ne saurait afficher des milliers d’indicateurs que les pilotes devraient consulter quotidiennement. Il est donc nécessaire de leur proposer des tableaux de bord, qui donnent un aperçu du modèle métrologique complet. En contrepartie, la méthode doit préciser les circonstances qui doivent alerter les pilotes quand leurs tableaux se révèlent insuffisants et laissent échapper des signaux importants pour l’avenir de l’entreprise.
La métrologie dans l’architecture de l’entreprise : le modèle métrologique se range dans l’aspect intentionnel dont il constitue une des facettes. La Topologie du Système Entreprise aide à trouver les points de départ pour concevoir les métriques. La méthode propose des règles systématiques. Les métriques s’organisent en « domaines d’attention ». L’acte de « projection », défini pour tous les éléments d’intention, permet de prolonger l’élaboration du modèle métrologique en inscrivant les métriques dans les autres aspects. À terme, cette démarche conduit à réduire la fracture entre le système décisionnel et le système opérationnel.
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
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.
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.
Une bonne nouvelle
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.
Des obstacles à surmonter
Encore faut-il que le formalisme standard soit utilisé correctement. Or, sa bonne utilisation se heurte à plusieurs obstacles :
Tout d’abord, l’approche par les processus se contente, assez souvent, de représentations schématiques qui se limitent à décrire superficiellement les activités.
Ensuite, cette attitude est parfois revendiquée, selon l’argument qu’une description complète d’un processus ne serait pas comprise par les acteurs du métier. En conséquence, une diapositive est préférable à un modèle ; une notation intuitive, à un formalisme rigoureux.
Enfin, à l’intérieur même des pratiques de BPMN, s’est répandue l’idée que l’on n’a pas besoin de toute la notation.
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.
Une illustration
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.
Quelques points particuliers
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 :
les sous-processus événementiels (pas vraiment une innovation puisqu’ils existaient dans le modèle de traitement de Merise, mais un peu oubliés) ;
le branchement basé sur événement (typique du style de modélisation de BPMN) ;
la compensation (mécanisme le plus sophistiqué dans BPMN, que l’on retrouve tel quel dans BPEL) ;
la chorégraphie (enfin ! un moyen simple de représenter les activités collectives) ;
la notion de “définition d’événement” (EventDefinition, dans le méta-modèle) qui n’a pas de correspondant graphique (seul l’événement se visualise), mais qui permet d’assurer la cohérence dans une conception de processus, ou d’un ensemble de processus.
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.
Conclusion : un nécessaire effort d’apprentissage
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” :
“Esquisser le processus”, où l’on démontre que le formalisme aide à révéler les manques de l’expression textuelle ;
“Ordonnancer les activités”, où l’on découvre les principaux types de branchements (gateways) offerts par BPMN ;
“Structurer le processus”, qui règle la question de la présentation du modèle ;
“Introduire la temporalité dans les processus”, dimension évidente et pourtant négligée ;
“Prendre en compte les perturbations”, au-delà du fonctionnement nominal, afin de concevoir des processus robustes et d’anticiper les crises ;
“Distribuer les activités et décrire la coopération” ;
“Architecturer l’activité métier”, et passer à la portée “entreprise” (ce qui soulève quelques questions de méthode et d’outillage) ;
“Modéliser l’activité métier”, récapitulatif des actions du modélisateur.
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.
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)
Les budgets nécessaires pour assurer la conformité au RGPD (Règlement général pour la protection des données),
les amendes à venir en cas d’échec (on ne manque pas d’oiseaux de mauvais augure)…
…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 :
juridique (l’aiguillon de la loi),
stratégique (l’occasion à saisir pour créer de la valeur, plutôt que d’adopter une posture défensive),
communication et marketing (les enjeux d’image et de confiance),
organisation (l’impact sur les comportements des collaborateurs et sur les processus – pas seulement une case de plus dans l’organigramme),
informatique (la technologie à dompter).
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.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Durée
Description
cookielawinfo-checbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
