Complexité et complication

Complexité ?

Le terme « complexité » fait partie des termes à la mode. Il signifie à la fois l’argument pour une rationalisation plus poussée de nos systèmes (notamment d’information, mais aussi des systèmes entreprise au travers des réflexions sur la Business Architecture), et la crainte plus ou moins mystique devant l’énormité de certaines tâches de transformations des systèmes.

Alors, comme souvent quand on mélange intérêt fort et crainte devant l’ampleur d’une tâche, le concept se dissout dans des discussions qui ressemblent fort à de la procrastination : pendant qu’on discute des meilleures actions possibles, on est moins contraint de se lancer.

Au Praxeme Institute, nous avons l’habitude de différencier complexité et complication.

Complexité vs complication

La complexité est intrinsèque à la réalité étudiée ; la complication est la part inutile ajoutée dans le système entreprise à la faveur de plusieurs phénomènes : manque de synthèse et de pluridisciplinarité, nombre de personnes et compétences requises, conflits politiques et sociaux dans l’entreprise, manque de méthodes analytiques, multiplication des dogmes à la place des rationalités, multiplication des contraintes locales, etc…

La différence est d’importance : la complexité est irréductible, la complication est évitable. Les observations montrent régulièrement que la marge de manoeuvre est énorme : avant de se heurter à la fatalité de la complexité, nous pouvons économiser beaucoup sur les complications. Voyons ça à peine plus en détails.

Formalisation

Jusqu’à présent, la complexité, malgré les travaux de chercheurs éminents, échappait à une définition réellement rigoureuse, c’es-à-dire présentant un niveau de formalisme permettant de conclure à coup sûr. C’est beaucoup moins vrai aujourd’hui. L’atelier « Praxeme et… la science des systèmes » dont l »invité était Marc Aiguier, nous a sortis de cette difficulté. Ce n’est pas le seul apport de cet atelier, mais c’est très important.

L’approche formalisée nous indique qu’un système complexe est un système dans lequel les sous-systèmes (composants) n’ont pas un comportement de groupe déductible de leurs comportements individuels. En d’autres termes, connaître le comportement d’un composant ne permet pas de prédire son impact lorsqu’il sera plongé dans le système.

Cette caractéristique s’oppose à la modularité qui établit l’inverse : la connaissance complète du comportement des composants isolés permet de prédire le comportement du système composite. Et je le rappelle, ces résultats sont issus d’un formalisme fort qui permet notamment d’abstraire l’opérateur de composition et donc de s’appliquer à toute sortes de systèmes.

Dont les nôtres.

Revenons à nos moutons

Ca ne vous rappelle pas des expériences sur le terrain dans nos métiers ? Ces fameux effets de bords imprévisibles qui nous entraînent si souvent à dupliquer des composants pour éviter ces impacts coûteux (et dans la foulée à augmenter la redondance et donc les risques d’effets de bords) ? Ces erreurs qui échappent aux tests unitaires et rendent les tests d’intégration obligatoires même si on a une grande confiance dans les unitaires ? Ces traitements qui semblent se comporter aléatoirement et nécessitent des équipes de production sur le pied de guerre 24/24 7/7 ?

L’état de notre art nous oblige à un constat. Dans la majorité des cas nous ne sommes pas dans les conditions de la formalisation : il est assez exceptionnel de pouvoir affirmer que nous connaissons complètement le comportement d’un composant avant de le plonger dans le système global. La raison en est le manque de rigueur de la conception et des tests et l’approche des tests qui n’utilise pas les avancées pourtant très efficaces des preuves de codes (un autre des apports de l’atelier, mais c’est un sujet différent). Dans ces conditions nous introduisons couramment quelque chose qui ressemble à de la complexité mais qui est évitable. De la complication.

Cette part-là de nos tracas est évitable par la méthode. Rationaliser la démarche de conception diminue très sérieusement la méconnaissance des produits, et, par là même, apporte une bien meilleure prédictibilité des systèmes que nous bâtissons. Il y a là un énorme potentiel d’économies, à tous les niveaux : cash, stress, risques d’entreprise, risques sociétaux. Les enjeux sont d’importance.

Publicités
Cet article, publié dans Enterprise Architecture, Principes, Références, est tagué , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s