Fatalité entropie-v1

L’ACCROISSEMENT DE L’ENTROPIE DES
SYSTÈMES D’INFORMATION EST-ELLE UNE
FATALITÉ ?
René MANDEL
www.value-architecture.com
Version 1
13/04/2015

SOMMAIRE
Table des matières
1. PRÉAMBULE.......................................................................................................................1
1.1 LA MAÎTRISE DE LA COMPLEXITÉ DES SI.............................................................1
1.2 UN DÉFI SCIENTIFIQUE ET TECHNIQUE................................................................1
2. L’INTÉGRATION DES SYSTÈMES D’INFORMATION..............................................3
2.1 L’ALGEBRE DES COMPOSANTS DU SI....................................................................3
2.2 FATALITÉ DE LA COMPLEXITÉ................................................................................4
2.2.1 Dérive vers la complexité.........................................................................................4
2.2.2 Existence de données « de référence ».....................................................................4
2.2.3 L’intégration imparfaite des composants de référence.............................................5
2.3 MECANIQUE DE LA COMPLEXITÉ...........................................................................7
2.3.1 Divergence selon le taux d’imperfection..................................................................7
2.3.2 Les vraies raisons des particularités.........................................................................7
3. AGIR SUR LE CŒUR DE L’INTÉGRATION.................................................................9
3.1 RENDRE LE MARCHÉ DES COMPOSANTS PLUS PARFAIT.................................9
3.1.1 Quel ROI du SI avec une algébre parfaite................................................................9
3.1.2 Agir sur le marché interne......................................................................................10
3.2 DOTER LES COMPOSANTS DE RÉFÉRENCE DE CAPACITÉS
D’INTÉGRATION GÉNÉRIQUES (PRINCIPE DE « JANUS »).....................................10
3.2.1 Les fonctions de « traduction » et d’intégration de données génériques................11
3.2.2 Modélisation générique des « puits de données »..................................................13
3.2.3 Cas des « référentiels de données »........................................................................14
3.2.4 Gérer la subsidiarité................................................................................................15
3.3 PROFESSIONALISER LES ACTEURS DU SI...........................................................15
4. VERS UNE ALTERNATIVE À LA « GOUVERNANCE »...........................................17
4.1 RÉSISTANCES À LA GOUVERNANCE PYRAMIDALE ET AUX MÉTHODES
LOURDES...........................................................................................................................17
4.2 LES DÉCISIONS DES PROJETS NATURELLEMENT DANS LE BON SENS.......17
4.3 SYNCHRONISER LES DONNÉES SUR LA SIMPLICITÉ.......................................18
4.4 CHANGER DE PARADIGME.....................................................................................18
fatalit-entropie-v1-150331122602-conversion-gate01-reupload.doc 13/04/2015

L’accroissement de l’entropie des systèmes d’information est-elle une fatalité ? PAGE N° 1
1. PRÉAMBULE
1.1 LA MAÎTRISE DE LA COMPLEXITÉ DES SI
Les systèmes d’information résultent d’une réalité de plus en plus complexe :
multiplication des capteurs, extension des domaines applicatifs, empilement des
technologies, sédimentation applicative, …
Intuitivement on peut qualifier cette dérive, au cours du temps, comme un accroissement
d’une « entropie » des systèmes (distincte des autres entropies connues car un facteur
humain entre en ligne de compte). L’Architecture d’Entreprise a pour ambition d’imposer
un modèle pour donner de l’ordre. C’est une approche rationnelle et autoritaire qui
suppose que le modèle est respecté et applicable dans la durée. En pratique, une
planification rationnelle, certes souhaitable, est en grande part irréaliste et dispendieuse.
L’Urbanisme des Systèmes d’Information est une approche plus modeste qui compte sur
la mise en ordre progressive, au fil des projets, à moindre coût. Mais il est clair qu’en
l’absence d’effort collectif et central, le désordre s’accroit « naturellement ». Qu’elle est
donc la quantité d’énergie nécessaire pour revenir à l’ordre, en l’imposant ou en facilitant
l’agilité ? D’ailleurs comment définir l’entropie des SI ?
Mais l’accroissement de l’entropie est-elle une fatalité ?
On peut penser que les mêmes causes, qui provoquent l’imbrication fatale, et l’embolie,
dans un fonctionnement en cercle vicieux, pourraient agir au contraire par cercles
vertueux et réduire progressivement l’entropie. Cette simplification serait naturelle, non
planifiée et dirigée par une gouvernance. Une des pistes, pour cette transformation
naturelle du patrimoine, est d’introduire quelques composants clés, catalyseurs de vertu et
tueurs d’entropie : le système sociotechnique se transformerait alors de lui-même, de
façon déconcentrée. L’effort de mise en ordre serait minimal et relayé naturellement par
toutes les parties prenantes des SI. Cependant cette piste, ouverte comme exposé ci-après
par des avancées technologiques, est ignorée par l’idéologie rationnelle dominante.
L’accroissement de l’entropie des SI n’est pas une fatalité, elle résulte d’une part de la
dérive naturelle des SI, et d’autre part de l’utopie d’une maîtrise irréaliste ignorant la
dynamique des micros décisions de construction des SI, et des opportunités
technologiques. Il faut changer le paradigme de l’EA. Et étudier l’alternative aux
approches purement méthodologiques.
1.2 UN DÉFI SCIENTIFIQUE ET TECHNIQUE
L’activité de développement de logiciels est devenue, au cours du temps, majeure dans
l’économie :
René MANDEL Mars 2015

• Les composants logiciels sont présents partout, dans tous types de supports
matériels, et de façon virtuelle dans le « nuage »,
• Toutes les organisations disposent d’équipes internes, ou sous-traitent pour
assembler, intégrer des composants et constituer des SI de plus en plus
déterminants pour leur activité, pour l’analyse, la stratégie, l’engagement des
clients,…
• Le poids économique de ces activités est une préoccupation macro-économique
primordiale : nombre d’emplois, redistribution mondiale des compétences, flux
financiers induits,…
En somme l’ingénierie du logiciel devrait s’appuyer sur une science du logiciel à la
mesure de ces enjeux, comme par exemple les enjeux écologiques justifient le
programme de recherche ITER sur la fusion nucléaire.
Force est de constater que cette science du logiciel n’a pas été jusqu’à présent à la mesure
des enjeux, et qu’en pratique les SI des grandes organisations se heurtent à des défis de
complexité. Les SI s’avèrent en effet rigides, sur-complexes, coûteux, fragiles, cloisonnés
« en silos », et, finalement difficiles à maîtrisés.
Les efforts de gouvernance, et les méthodologies d’Enterprise Architecture, visent à
pallier à ces difficultés pratiques et organisationnelles. Cette approche autoritaire et
rationnelle a des limites, en particulier par sa lourdeur et son implantation
organisationnelle pyramidale, même si elle cherche à se réformer en intégrant les
approches « agiles ».
En effet l’extension des SI est dans une phase explosive, qui ne permet plus de s’en
remettre exclusivement aux anciennes recettes basées sur un passé technologique
obsolète et des outils artisanaux.
Le défi est à la fois scientifique et technique :
• Scientifique car on ne dispose pas de recul suffisant pour expliquer, modéliser les
comportements des acteurs des projets qui aboutissent aux imbrications,
duplications, dysfonctionnement constatés.
• Technique, car le monde technologique est en évolution rapide, et des bases
technologiques nouvelles permettent d’espérer un changement de paradigme pour
que la maîtrise de la complexité soit consubstantielle au développement du
logiciel. Ce fait majeur est une opportunité méconnue qui doit bousculer les
approches méthodologiques. Encore faut-il que le sujet soit examiné avec une
rigueur à la mesure de ces enjeux.

2. L’INTÉGRATION DES SYSTÈMES D’INFORMATION
Dans l’activité de production de logiciels, depuis plusieurs décennies, les limitations sont
connues. En particulier les effets pervers de l’intégration mal maîtrisée ont amené à
élaborer des méthodes d’Architecture d’Entreprise (Zachman, Togaf, …) et de
gouvernance. Une des questions clé est celle de l’intégration des composants pour
constituer, par assemblage, les SI.
2.1 L’ALGEBRE DES COMPOSANTS DU SI
Les SI sont constitués, quels qu’ils soient, à partir de divers composants (logiciels,
techniques).
On peut donc avoir une vision globale d’un SI, comme un tout qui évolue :
• Par l’assemblage et le désassemblage de composants
• Par les cycles de vie des composants eux-mêmes.
Ce cycle d’un SI, qui n’est pas celui du « run time » mais celui du logiciel et des
composants techniques, est complexe et résultante de toutes ces évolutions.
Chaque composant a son propre cycle de vie, avec une phase de création, des épisodes de
maintenance, de refonte, de nécrose (abandon progressif), ….
Une forte particularité des SI est l’interdépendance entre les composants. En effet de
multiples interactions sont nécessaires, voulues, ou mêmes involontaires.
On peut dire qu’entre 2 composants il y a une « fonction » d’interaction qui permet de
considérer l’ensemble qu’ils constituent comme un nouveau composant. Ce nouveau
composant peut lui-même interagir avec d’autres. Cette fonction est « transitive » et par
assemblages successifs se constituent des ensembles de plus grande taille (associativité).
Ainsi, du point de vue ensembliste, les composants obéissent à des lois particulières.
On pourrait faire l’analogique avec la physique moléculaire, et au comportement des
atomes entre eux (voir http://www.value-architecture.com/2015/03/les-limites-de-la-
complexite-des-si.html) …
Les interactions voulues se dénomment « l’intégration ».
Les composants, en s’intégrant, respectent une « algèbre » qui leur est propre (on peut la
représenter par une formulation algébrique).

On pourrait faire l’hypothèse d’une algèbre des composants « parfaite » respectant une loi
de composition associative ((x * y) * z = x * (y * z) et commutative : x*y*z = x*z*y.
Mais en pratique, les particularités d’intégration comme la dispersion des projets entre
équipes et dans le temps, laissent penser que cette hypothèse n’est pas réaliste dans l’état
de l’art actuel.
2.2 FATALITÉ DE LA COMPLEXITÉ
2.2.1 Dérive vers la complexité
Au cours du temps, de nouvelles interactions apparaissent, par « transitivité » de
l’intégration : de proche en proche des dépendances involontaires et non objectivées se
créent ainsi. En effet, l’intégration est maîtrisée « par proximité » (des maîtres d’ouvrage,
des maîtres d’œuvre, technique, temporelle, …) mais la propagation de la connaissance
est toujours limitée, et repose sur une base humaine. Ainsi, au-delà des cercles de
proximité, des dépendances indirectes et involontaires sont créées.
Les imperfections s’accroissent aussi au cours du temps :
• la connaissance se dilue progressivement
• de nouveaux besoins apparaissent auxquels il faut répondre par de nouvelles
intégrations, voire ne pas répondre en admettant des lacunes ou incohérences.
Ce phénomène est classique et bien connu sous ses différentes manifestations : effet
spaghetti, adossement des systèmes avec risque systémique (effet domino), rigidité du
patrimoine rendant les évolutions couteuses (nécessité de refontes lourdes) voire
impossibles, empilement technologique, …
Par exemple l’effet spaghetti est dû à la combinaison des particularismes des émetteurs et
des récepteurs : s’il y a n émissions d’un même ensemble d’informations sous n variantes,
et p réceptions de cet ensemble sous p autres variantes, se construisent au fil des projets n
X p types d’échanges, alors que le passage par un point focal, du type « puits de
données » n’en nécessiterait que n + p. De façon plus générale n + p intégrations sont
complexifiées en n X p.
De ce fait, les SI sont « sur-complexes » s’étant développés en « récif de corail » par
ajouts opportunistes et intégrations privilégiant la proximité et le court terme. Ils sont sur-
complexe car un assemblage plus simple pourrait produire un résultat identique, voire un
meilleur résultat, si l’on prend en compte l’amélioration en flexibilité.
2.2.2 Existence de données « de référence »
Dans tous les SI on constate qu’il existe le besoin de partager des « données de
référence ». Cet état de fait général, qui ne souffre aucune exception, est connu lui aussi
de longue date. Le rôle clé de ces données pour maîtriser le désordre des systèmes, bien
au-delà de la stricte sphère des SI, est aussi admis par toutes les organisations.
La réponse organisationnelle est de mettre en place une gouvernance de ces données,
gouvernance minimaliste, ou au contraire maximaliste, mais qui est souvent source de
tensions internes. En effet un équilibre des pouvoirs est à trouver pour préserver

l’indispensable cohérence « centrale » et la non moins indispensable autonomie
« périphérique ».
Du fait de cette recherche de l’équilibre, on constate des excès, soit dans un sens soit dans
un autre, qui génèrent des dysfonctionnements : incohérences, redondances, rigidité,
confusions, doubles saisies, contournements. Et dans de nombreux cas les données de
référence, par exemple sur le client (notion de « golden data ») qui ne sont pas en qualité.
2.2.3 L’intégration imparfaite des composants de référence
Toujours dans la vision ensembliste, on doit s’intéresser à une classe particulière de
composants qui est celle de ces composants « de référence » (de type « master data » ou
« puits »).
Un composant de référence joue un rôle particulier dans un périmètre (la totalité du SI ou
un sous-ensemble) : il est susceptible d’être « intégré » avec tous les autres composants
de ce sous-ensemble, et cette intégration est parfaitement transitive : un composant
intégrant une telle référence hérite de cette faculté et peut servir de référence à son tour,
et à l’identique.
En quelque sorte la loi de composition serait associative : (x * y) * r = x * (y * r) et
l’héritage des propriétés de la référence pourrait se noter Hr(x*y*r)=Hr(y*r)=Hr(r).
En réalité, on constate toujours que l’intégration de ces composants est « imparfaite » et
donne lieu à des aberrations. Comment expliquer les imperfections de cette « algèbre » ?
2.2.3.1 Composants usurpateurs
Des composants, qui ne sont pas classés parmi les composants de référence, peuvent,
pour des raisons variées (absence de connaissance, volonté de contrôle, volonté de
modifier le modèle, …) être substitués à un composant de référence au sein de son sous-
ensemble.
L’usurpation peut être :
• Conceptuelle : modification du modèle, introduction d’une variante sans réel
apport, refus de la généricité, imbrication d’un complément,
• Syntaxique : introduction d’un dialecte local, rendant les échanges locaux
particuliers et nécessitant une traduction pour être compris dans le périmètre
d’élection du composant de référence,
• Sur les modes de latence : introduction d’une cinématique d’échange particulière
(lots, rythme de mise à jour, messages, invocation de services…).
2.2.3.2 Intégration opportuniste
Sans qu’il y ait création volontaire de composants usurpateurs, les liens d’intégration
peuvent se développer dans le désordre, par proximité, sans respecter la qualité de
l’intégration proposée par les composants de référence.

Par exemple, si un composant de référence n’offre pas le mode d’échange attendu, la
temporalité requise, … un composant usurpateur pourra paraître illusoirement légitime, et
prendre une position durable, même si la lacune la justifiant disparait.
Ainsi un maillage aléatoire des composants se crée, et rend le système de plus en plus
complexe.
Perver
Vraie
source
Usurpeur
Sain
Vraie
source
Développement d’un maillage sur-
complexe
Conduisant progressivement à :
2.2.3.3 Lacunes d’intégration

Il est aussi fréquent, devant les difficultés à intégrer les composants, qu’on fasse
l’impasse, en se reportant sur des solutions « manuelles » : saisies en double, consignes,
reports de données à vue, …
Ces solutions, satisfaisantes si les volumes sont faibles, sont peu sécurisantes à moyen
terme, et doivent être encadrées par des contrôles qui posent aussi la question des
données de référence.
2.3 MECANIQUE DE LA COMPLEXITÉ
2.3.1 Divergence selon le taux d’imperfection
Au cours du temps les composants évoluent, la population change, et les liens
d’intégration se font et défont.
Il y a donc une certaine intensité de projets, et une démographie de tous ces éléments.
Il y a d’abord une dérive du périmètre, qui va en général dans le sens d’une extension du
système, et de sa population. Il devient ainsi plus complexe. Mais il ne faut pas qu’il
devienne au cours du temps « sur-complexe » par augmentation des dysfonctionnements
indiqués ci-dessus.
En pratique, avec un taux d’imperfection élevé, la complexité s’accroît de façon
combinatoire, rendant des refontes et réingénieries coûteuses nécessaires, et une
gouvernance lourde indispensable.
En somme la complexité obéit à une loi de série qui est rapidement divergente : des
imperfections naturelles s’introduisent au cours du temps, et ont un effet pervers
cumulatif.
Par contre si de nouvelles imperfections ne se produisent pas, les anciennes imperfections
seront naturellement résorbées au fil des évolutions (une intégration imparfaite étant
remplacée par une intégration parfaite). La série sera convergente et la complexité se
réduira naturellement. Sur la base de quelques hypothèses paramétrées (taux de couplage
entre générations, taux d’imperfections dans ces couplages, effectif des générations
successives, …) on pourrait créer un modèle numérique pour simuler cette série.
L’entropie serait mesurée au sein du graphe des dépendances entre composants de base
(les « atomes ») : nombre moyen d’arcs par composant.
2.3.2 Les vraies raisons des particularités
De fait, dans l’interposition des « composants usurpateurs », il existe de vraies raisons :
• Absence de modélisation de la subsidiarité
o exemple du référentiel des structures, des identités, …
o exemple de la subsidiarité sémantique
De fréquentes divergences sont en réalité dues à une subsidiarité cachée, qui n’est pas
objectivée. Une façon pratique de lutter contre cela est d’objectiver la subsidiarité par une
modélisation adaptée, et de paramétrer ce modèle pour le rendre flexible et évolutif.

• Pas de gestion des multiples latences :
o services de flux de fichier à différentes échéances,
o lots de population variables : mis à jour, stock,…
• Séparation entre 2 mondes (Batch, temps réel) et multiplication des protocoles et
formats
• Pas de gestion des 3 dates et de l’historique (voir à ce sujet l’approche « puits de
données »).
Ces sujets, mal étudiés au plan conceptuel, divisent les éditeurs, et balkanisent le SI.
Pourtant il s’agit des mêmes facettes des objets du SI, traitées comme particulières, sans
objectiver le « modèle » commun.

3. AGIR SUR LE CŒUR DE L’INTÉGRATION
Comme dans d’autres sciences, on peut d’une part étudier le système dans sa globalité, ou
dans son fonctionnement détaillé. Par exemple la physique a d’abord dégagé des lois
générales, bien que l’intuition de l’existence des atomes soit très ancienne. La physique
quantique est venue ensuite formuler les modèles de comportement et d’interaction à
l’échelle des atomes.
Mais, en physique, l’homme n’intervient pas dans ces interactions atomiques. Dans le
cycle de vie des SI, par contre, les comportements humains, aussi bien ceux des
individus, et surtout ceux dus aux conditionnements sociaux, sont déterminants.
D’ailleurs les outils disponibles dans les activités de conception des SI, et lors de la
maintenance, sont frustres, à base de cartographies élaborées de façon artisanale.
3.1 RENDRE LE MARCHÉ DES COMPOSANTS PLUS PARFAIT
3.1.1 Quel ROI du SI avec une algébre parfaite
La question du ROI d’un SI est primordiale : un SI coûte et apporte de la valeur tout le
long de sa durée de vie, et on ne peut juger de son utilité que sur cette durée. Nous avons
proposé un modèle mathématique pour formuler ce ROI (voir :
http://fr.slideshare.net/RenMANDEL/roi-infrastructure-v8).
L’intégration de 2 composants, qui crée logiquement un nouveau composant, altère ce
ROI. D’une part elle a aussi un coût, et une valeur, et a un impact sur les coûts et valeurs
des composants intégrés. On peut ainsi considérer que cette intégration a aussi un ROI, et
que la fonction d’intégration, active dans l’ensemble des composants, se « projette » sur
l’espace des ROI. Et si l’on est rationnel, l’intégration ne se réalise que si elle améliore le
ROI.
Ce modèle « atomique » est simple. On peut le propager au niveau macro en faisant des
hypothèses, et en particulier que l’algèbre des composants est « parfaite » :
• Un composant qui serait utile à d’autres composants serait « intégré » quelle que
soit la « distance » entre eux.
• Les effets pervers mentionnés ci-dessus seraient connus et maîtrisés par les
acteurs concernés, et limités pour ne pas dégrader le ROI en toute hypothèse (on
pourrait formuler cela dans une approche probabiliste).
Bien sûr ces calculs sont difficiles et arbitraires, car, alors qu’on sait répartir les coûts, il
en va autrement pour la valeur qui est fluctuante et dépendante du contexte externe. Les
composants de référence trouvent leur justification dans leur intégration aux autres,
comme s’il y avait une transaction interne, avec un prix de cession.
Cela pose donc la question du « marché » interne des composants.

L’accroissement de l’entropie des systèmes d’information est-elle une fatalité ? PAGE N°
10
3.1.2 Agir sur le marché interne
Ainsi, au-delà de cette perfection de l’intégration souhaitable, la question est celle de la
« perfection » du marché interne d’échange de composants : un composant de référence
sera « intégré » (une sorte de transaction économique interne) s’il permet une évolution
optimale du ROI (voir la note citée ci-dessus sur le ROI). Ceci rappelle le besoin de
rendre l’information symétrique, dans un marché « parfait », pour que les « acheteurs »
ait une connaissance des avantages, des garanties, des risques. Une approche
contractuelle (cf. la théorie des contrats en économie industrielle) permettrait de répondre
à cet objectif.
Cette transparence du marché interne des composants, appliquée aux composants de
référence, permettrait d’éviter « l’usurpation », qui place dans le patrimoine des
composants usurpateurs, avec des effets pervers à court terme et surtout à moyen terme.
Cela implique aussi que les composants de référence soient disponibles sur le marché
« en avance de phase » par rapport aux cycles de développement des autres composants.
3.2 DOTER LES COMPOSANTS DE RÉFÉRENCE DE CAPACITÉS
D’INTÉGRATION GÉNÉRIQUES (PRINCIPE DE « JANUS »)
Une autre clé pour optimiser les intégrations autour des composants de référence est de
doter ceux-ci de capacités d’intégration « génériques » leur permettant d’être assemblés
dans tous les contextes, de façon « parfaite » et sans surcoût.
A cet effet les qualités sont :
• L’anticipation d’évolutions futures, pour garantir aux projets un « service » adapté aux
nouvelles technologies et aux exigences futures : préfigurer, pour les projets,
des modalités nouvelles, plus alignées sur les possibilités actuelles (ESB, latence
faible, Cloud, ...) et les attentes imposées au SI (tout connecté, mobilité, traçabilité,
transparence, toutes sources, agilité,...).
• L’offre d’interfaces variées pour une insertion « non-intrusive » au sein du
patrimoine existant : admettre toutes les modalités d'échange et d'intégration, pour une
cohabitation avec le patrimoine existant sans surcoûts, et dans des pas de temps
courts.
On peut qualifier cette capacité de « Janus », à l’instar du dieu Romain au double visage, l’un
tourné vers le passé, l’autre vers l’avenir.

11
Cette capacité est obtenue par le développement de services de données utilisant une
bibliothèque d’intégration de données (plusieurs solutions existent sur le marché), et le
la conception d’un modèle générique adapté au type de données de référence.
Une architecture d’interopérabilité peut par exemple être constituée pour s’appliquer aux
mondes de la répartition de flux (batch, messages) et à celui de l’orchestration de services
(services web, Soa, …) et les faire converger.
Puits de
données
Web
GRC LEGACY …
Web
ERP
Référentiels
de données
Dispositif d’interopérabilité
Orchestration
des échanges
Répartiteur
De flux
Puits de
données
3.2.1 Les fonctions de « traduction » et d’intégration de données génériques
La bibliothèque d’intégration de données se décompose en plusieurs fonctions. Elle doit
aussi être enrichie par une couche de services et de pilotage. Ces fonctions sont décrites
ci-dessous (on peut aussi se référer aux publications du Gartner sur le sujet).
3.2.1.1 Le « transport »
C’est le niveau de la tuyauterie qui permet de transporter les messages ou les lots de
données.
Il y a d’une part les transferts par fichier en lots de données, d’autre part ceux de
messages, par exemple au travers d’un ESB.

12
3.2.1.2 La « connectivité »
Ces composants permettent de se connecter à une grande variété de bases de données de
divers éditeurs ou du monde open source. D’autres permettent d’interagir selon divers
formats: champs fixes, balisés (XML, JSON, EDI), spécifiques à des ERP, …
3.2.1.3 Les fonctions de « conversion »
Grace aux composants de connectivité, il est possible de convertir les divers formats les
uns vers les autres. En outre, par quelques clics certaines bibliothèques permettent un
travail sur les métadonnées: le mapping de données consiste à recomposer de nouveaux
échanges ou flux à partir de données choisies dans les flux ou échanges existants.
Ces composants peuvent être activés dans un contexte de type « batch », par exemple
dans un ETL classique, comme dans un contexte « message » ou temps réel.
3.2.1.4 Fonction de « stockage »
Cette « couche » est d’utilité variable selon les usages. La fonction de « stockage » peut
utiliser plusieurs techniques: SGBD classique, ou nouvelles solutions de la famille
« NoSql ».
3.2.1.5 Les fonctions de « synchronisation, qualité de données »
La consolidation de différents flux et échanges fait apparaître divers problèmes de qualité
des données: doublons, divergences, incohérence d’identification par rapport aux
référentiels, incohérences temporelles, non qualité des identifiants, adresses, … les
fonctions doivent encapsuler le diagnostic et les fonctions de corrections. Ces fonctions
sont clés pour la gouvernance et la qualité des données d’un référentiel. Elles sont en
général apportées par des solutions de type Master Data Management (MDM).
3.2.1.6 Fonction de « services de données »
Les services de données ont pour objectif d’exposer et de diffuser les données. Des
approches fonctionnelles doivent permettre de les exposer selon des regroupements, des
lots, des latences attendues par les structures internes ou externes, et par les applications
qui souhaitent les utiliser (en respectant les consignes indiquées par les dépositaires des
données). Cette fonction est à développer et adapter au domaine.
3.2.1.7 Le « pilotage »
Ce niveau pilote et supervise la répartition des flux et l’orchestration des services.

13
3.2.2 Modélisation générique des « puits de données »
Les puits ont d’abord pour vocation des substituer à N + P interactions aux N X P
interactions qui se créent naturellement, selon le schéma suivant :
Devient :
N X P fluxN X P conversions de format
Référentie
l
Source
GRC
Source
Infinite
Source
externe
Vision 360 Décisionnel Erp
PuitsPuits Conversions
de format

14
Pour une présentation du principe voir : http://www.value-architecture.com/2014/03/a-la-
decouverte-des-puits-de-donnees.html
La clé de la conception est dans l’identification du « grain » générique, qui permet de
tracer toutes les évolutions des objets dont les données de référence sont placées dans le
puits. Le travail de définition des événements et des différentes datations est primordial,
pour garantir la stabilité du modèle.
(voir aussi : http://fr.slideshare.net/RenMANDEL/principe-du-puits ).
Par principe les Puits ne doivent pas être intrusifs, ni nécessiter de refonte des processus.
En effet il est hors de question de déposséder les applications de leurs processus, en
général très imbriqués. Par contre les Puits assurent la traçabilité, en particulier pour le
suivi de la mise en qualité des données (cf. le modèle « tridaté »).
Le modèle « tridaté » d’un puits
Il existe un moyen simple pour repérer les puits potentiels : objectiver les cycles présents
dans l’écosystème (voir : http://www.value-architecture.com/2013/02/les-azimuts-des-
chaines-de-valeur.html), car chaque cycle est à l’origine d’événements, motivant un puits
qui lui est dédié. Un puits, clé de la cohérence, est destiné au traçage d’un tel cycle.
3.2.3 Cas des « référentiels de données »
A noter que les référentiels de données, qui structurent le SI, sont plutôt « à cheval » entre
plusieurs cycles, et garantissent une cohérence inter-cycles.
L’offre du marché de solutions de MDM permet de disposer de solutions flexibles et
opérationnelles.

15
L’utilisation de la bibliothèque d’intégration permettra aussi une insertion non-intrusive,
et évolutive, contrairement à certains projets de MDM très centrés sur la gouvernance.
Le principe est alors d’organiser un « point focal » pour diffuser, en l’état, les données
qui jouent actuellement le rôle de référentiel.
Ceci n’exclut pas une évolution progressivement contrôlée, en particulier pour assurer la
qualité des données, et la synchronisation des sources. L’impact sur les processus
d’alimentation est alors à examiner, et implique une réingénierie.
Les fonctions de services de données et de pilotage peuvent être communes entre Puits et
Référentiels.
3.2.4 Gérer la subsidiarité
On pourrait croire qu’il existe une seule configuration dans l’architecture des références
de données. En réalité, les périmètres de ces systèmes peuvent être variables, et les
solutions actuelles peuvent anticiper cette flexibilité.
Comme évoqué ci-dessus, on doit à cette occasion modéliser la subsidiarité et propager le
modèle entre les différents référentiels et puits. Un modèle unique et intégré a peu de
chances de convenir pour permettre un équilibre entre :
• La cohérence sur les objets, les concepts communs,
• L’autonomie indispensable.
La subsidiarité est une question sensible, les « curseurs » ne sont toujours évidents. Il est
dès lors utile de prévoir ce paramétrage pour créer une flexibilité et résister à d’éventuels
« séismes organisationnels ».
3.3 PROFESSIONALISER LES ACTEURS DU SI
Autour de cet enjeu de simplification du SI, avec l’émergence des opportunités présentées
ci-dessus, il faudrait que les acteurs du SI sortent de l’artisanat actuel.
La question, de façon globale, est de reporter une partie de l’énergie placée dans les
investissements opportunistes, ou dans les grandes manœuvres méthodologiques, vers :
Puits
Vision
360
Point focal Bibliothèque de conversions
de format: batch, message,
accès API, …

16
• L’investissement, à moindre coût, dans des composants « Janussiens », en évitant
l’écueil des approches MDM classiques trop gourmandes en gouvernance et en
« big bang »,
• La « commercialisation » interne, avec une offre de services de données de haut
niveau,
• La prise en compte des besoins des projets, au niveau déconcentré.

17
4. VERS UNE ALTERNATIVE À LA « GOUVERNANCE »
4.1 RÉSISTANCES À LA GOUVERNANCE PYRAMIDALE ET AUX MÉTHODES
LOURDES
Nous avons vu que la réponse aux incohérences, aux dérives, et autres confusions
apparaissant naturellement a été d’introduire toujours plus de gouvernance des données
et, plus particulièrement, des données de référence.
Cette gouvernance répond effectivement à un enjeu de maîtrise majeur.
Cependant elle se heurte à plusieurs résistances :
• C’est une organisation à mettre en place, souvent avec des ressources dédiées,
• Bien souvent il existe des oppositions internes, du fait des différents objectifs et
des différents métiers, et un développement pyramidal dans l’organisation,
• Les régimes transitoires pour mettre en place le système (MDM ou autre), dans
une approche rationnelle et exclusive, sont longs et semés d’embuches.
• Les bases conceptuelles de ces systèmes sont fragiles, ne réglant pas les
problèmes de subsidiarité, de datation, d’historisation, de traçabilité, …
Par ailleurs les méthodologies historiques d’Architecture d’Entreprise sont lourdes
(volumétrie documentaire impressionnante, cursus, …) et coûteuses (personnels
spécialisés et « certifiés », procédures à respecter) à mettre en œuvre, et trouvent leur
justification dans de grands projets, qui cumulent coûts et risques.
4.2 LES DÉCISIONS DES PROJETS NATURELLEMENT DANS LE BON SENS
Nous avons vu que la disponibilité sur le marché de routines d'"intégration de données"
permet de créer, autour de ces puits et référentiels, une ceinture de conversion pour des
accès dans toutes les temporalités et latences, et selon tous types de protocoles...
Ces composants, organisés en "services de données", font leur affaire de la complexité
des "dialectes" locaux et variabilités opportunistes.
L’enjeu est de rendre ces services transparents, facilement accessibles, opérationnels,
démontrables par des Proof Of Concept, pour que les acteurs des projets prennent les
bonnes décisions sans autre forme de procès.

18
L’opportunité offerte par l’offre technologique est de pouvoir proposer cette offre pour
un coût modique en regard des énormes enjeux mentionnés ici.
La motivation doit venir des acteurs projets, en répondant à leurs souhaits :
• De maîtrise des coûts,
• De disponibilité à court terme,
• D’agilité à moyen terme,
• De garantie de fiabilité.
Les décisions des projets iront alors « naturellement » dans le bon sens, celui de la
simplicité. Et ces mêmes forces, qui agissent dans le contexte imparfait que l’on connait
en l’absence de composant « Janussien », simplifient progressivement le SI.
4.3 SYNCHRONISER LES DONNÉES SUR LA SIMPLICITÉ
Dans cette recherche de la simplicité, les données de référence sont clé. On constate
d’ailleurs qu’elles existent universellement, dans tous les contextes.
Elles sont les piliers de tous les SI, dans l’existant comme pour la cible. Elles retracent
les cycles des objets au travers de tous les âges des organisations, et des transformations
réalisées :
• Personnes, structures, produits, concepts, services, entités, …
En somme les SI sont devenus complexes par cumul des particularités, ils doivent
retrouver modularité et simplicité en se synchronisant sur ces piliers.
Ceci nécessite de « gérer les particularités » dans toutes leurs dimensions :
subsidiarités, dates, latences, protocoles, …
Ceci guidera la capitalisation pour les nouvelles avancées de la numérisation extensive :
Les ruptures techniques (Cloud, Big data, Hadoop) et culturelles exigent une vision
rénovée, détachée des approches en silos, des cartographies de SI et processus. Une
vision alignée sur les fondamentaux des chaînes de valeur, et dont les invariants des
modèles des données de référence sont les incarnations.
4.4 CHANGER DE PARADIGME
Le paradigme de l’EA se fonde sur une approche rationnelle, sensée contrôler le SI par
une vision globale.
Certes l’approche de l’urbanisme des SI « à la française » se démarque de la volonté de
contrôle gouverné prônée par l’EA, et ses Framework. Elle se fonde sur la progressivité,
et une mise en œuvre au fil des projets par un alignement sur la cible, au moindre coût.

19
Cependant, la domination internationale va dans le sens de standards « rassurants », dont
le sérieux semble à la mesure de l’épaisseur de la documentation, et du nombre d’experts
mobilisés. Cette tendance est relayée par les formations, certifications, qui propagent et
pérennisent le modèle.
Certes, le besoin de grandes orientations demeure, et il ne faut pas rejeter l’utilité des
réflexions sur la cible.
Mais le paradigme est clairement à remettre en cause, à revisiter, pour inverser la charge
de la preuve, et explorer des solutions plus adaptées au contexte « agile », « tout
technologique », « tout connecté » actuel.

Fatalité entropie-v1

Contenu connexe

En vedette

Similaire à Fatalité entropie-v1

Plus de René MANDEL

Dernier

Fatalité entropie-v1