A propos de Systèmes d'Information ...

On me demande souvent mon avis sur des Systèmes d’Information. L’exercice consiste à analyser le travail de centaines de personnes, le patrimoine accumulé sur des dizaines d’années, ce qui s’avère être un travail difficile, sinon vain dans une approche exhaustive. Que faire d’un avis nanométrique dont on ne tirerait aucun levier d’action à un niveau macroscopique ? Pour éviter cet écueil, il faut substituer l’approche linéaire à la recherche ciblée de structures fondamentales et surtout récurrentes. Truisme me direz-vous ? Oui si l’on ne connaît pas à l’avance ces canevas de solution déployés face à des situations vues et revues. A l’inverse posséder un inventaire de ces patterns, caractéristiques récurrentes de nos SI, dont la portée s’étend de l’organisation, au fonctionnel et au technique, permet de zoomer la où des solutions élégantes ou au contraire inadaptées se déploient régulièrement

La présence ou l’absence de patterns dans du logiciel fonde souvent sa qualité intrinsèque. Que diriez-vous d’une application de gestion multi-entité, c'est-à-dire capable de gérer plusieurs types de centres d’activité, par rapport à un logiciel mono-entité ? Pour deux logiciels qui auraient pu être cartographiés de manière identique (comptabilité, gestion back, gestion front, ..), vous tenez là l’essence de leur différence, et donc de leur valeur. Le logiciel est dit multi-entité car on l’a déployé dans des environnements variés, en résolvant de manière identique le problème récurrent de déploiement, typiquement par une capacité de paramétrage par entité

Les pattern multi-X (multi-langue, multi-géographies, multi-clientèle ..) caractérisent toujours des logiciels rodés et à forte valeur ajoutée : le même code sert des besoins variés. Ce n’est pas pour autant qu’il faille conclure que seuls les logiciels multi quelque chose sont de qualité. Il est parfois souhaitable que des applications soient dédiées à des produits ou des clientèles, ayant leurs contraintes propres, souvent liées à des rythmes d’évolution différents. Deux clientèles, deux entités ont des rythmes de croissance différents ? Mieux vaut développer deux applications

Comme on identifie les bonnes pratiques répétées dans le temps, on peut aussi identifier les bêtises récurrentes qui font nos applications, on parlera d’anti-pattern. Pattern « 0 refactoring » : une erreur de design historique est pérennisée malgré les problèmes récurrents qu’elle pose, par exemple utiliser un numéro de carte SIM comme identifiant du client [1]. Pattern organisationnel « Bunkerisation » : les projets se referment sous la pression et reproduisent X données ou services existants au prétexte qu’on ne pourra pas faire évoluer cet existant dans la même chronologie. L’anti-pattern Bunkerisation produit des SI balkanisés, redondants et peu maintenables, c’est pourtant un des plus présents dans nos organisations

Au-delà de limiter le volume d’informations nécessaire pour appréhender ce qu’est ou n’est pas le SI, le niveau de granularité du pattern fonde aussi les capacités d’action des dirigeants : renforcer certains patterns, corriger certains anti-patterns. Aller plus fin sert finalement peu : indépendamment d’être fausse, la carte au 25000^ème du SI n’aura pas beaucoup de lecteurs

Le concept englobant de pattern, concentré d’expérience ou de connerie humaine, est essentiel pour analyser et piloter son SI. Nous verrons prochainement comment l’exploiter dans la construction de SI. A bientôt