L’IT en quête de simplicité – quelques pistes
La plupart des méthodes agiles demande de "faire simple". Peut-on aller au-delà des déclarations d'intention et définir les notions de simplicité et de complexité pour un système d'information. Certaines idées issues de la théorie de l'information et du design industriel nous permettent d'y voir plus clair.
"Les choses
devraient être faites aussi simples que possible, mais pas plus simples."
disait Einstein lorsqu’il évoquait l’élaboration des théories physiques. Avant
lui, Guillaume d’Ockham au 14ème siècle énonçait un principe de parcimonie qui
exige que, toutes choses égales par ailleurs, on choisisse, parmi un ensemble
d’hypothèses explicatives, la plus économique. Un principe qui reste à ce jour
un des fondements de toute démarche scientifique. Enfin, plus proche de nous et
dans le domaine du développement logiciel cette fois, une démarche agile comme
le Lean Software
Management énonce un principe de sobriété qui commande d’éviter le
gaspillage, le terme étant entendu ici comme une complexité technologique sans
valeur pour les utilisateurs. Naturellement dans le domaine de l’IT, il faut
comprendre la simplicité comme un concept relatif car nul ne songe sérieusement
qu’un système informatique puisse encore être simple dans un contexte où chaque
application d’entreprise est supposée être multi-canal, « sociale »,
interconnectée avec les systèmes existants et par-dessus-le marché flexible dans
ses évolutions.
La philosophie, l’histoire des sciences et les méthodes
agiles foisonnent donc de beaux préceptes de simplicité. Si personne ne doute
sérieusement de leur pertinence, leur utilité pratique, face à l’inextricable
écheveau d’outils et de technologies qui constituent un système d’information,
laisse à désirer.
Pourtant, qu’elle s’applique à des services ou à des
outils informatiques, la simplicité n’est rien de moins que la source ultime
de valeur pour
les utilisateurs. C’est elle qui offre du temps et de la liberté pour… faire ce
que l’on veut ! Une quête assurément légitime.
La métrique introuvable
Passer des déclarations de principes à une démarche
opérationnelle capable de guider des équipes dans la conception et la
transformation de systèmes informatiques requiert a minima de définir de
manière précise le terme de simplicité, susceptible en l’état de beaucoup trop d’interprétations.
Dans un second temps, il faudrait parvenir à quantifier de manière objective et
mesurable la notion ainsi précisée. Pour sage qu’elle paraisse, cette démarche
est semée d’embûches car le concept de simplicité possède un caractère largement
subjectif, nous y reviendrons. La démarche de définition puis de quantification
s’avère cependant praticable dans une certaine mesure pour un concept voisin, celui
de complexité, plus facilement objectivable. Sans entrer ici dans les détails
de ces travaux de clarification conceptuelle, menés durant un demi-siècle par
les théoriciens de l’information, on peut schématiquement les résumer en disant
qu’il existe différents concepts rigoureux et objectifs qui interprètent chacun
une facette différente de l’idée intuitive de complexité. Il n’existe donc pas une mais des complexités. L’une
de ces notions permet par exemple d’attribuer une complexité bien définie à
un algorithme [1].
Une autre permet
de formaliser l’idée selon laquelle un système est complexe lorsqu’il est
difficile de prévoir son comportement. Une autre encore
permet de rendre précise l’idée qu’un objet est complexe lorsque sa conception
exige beaucoup de calculs. Hélas ces concepts de la théorie de l’information, bien
qu’ils fournissent une clarification conceptuelle indiscutable, ne débouchent
pas sur des métriques utiles pour évaluer pratiquement la complexité de tout ou
partie d’un système informatique.
Dans le champ plus restreint du génie logiciel, différentes
métriques de complexité ont été proposées, ceci sans relation avec les idées qui
viennent d’être évoquées. La plus connue étant probablement la complexité cyclomatique.
Des métriques ad-hoc ont même été concoctées pour s’appliquer aux architectures
des SI dans leur ensemble. Les hypothèses sur lesquelles elles se basent sont souvent
difficiles à justifier, ce qui en restreint énormément le champ d’application. Enfin,
aucune de ces notions ne rend pleinement justice à l’intuition qu’un système
est complexe dès lors que son appréhension globale est impossible pour un
esprit humain. Nous voici donc dans de beaux draps.
Les vases communicants de la simplicité
Puisque la quête d’un concept objectif de complexité utilisable dans tous les domaines de l’IT s’avère sans issue, il nous faut revenir au concept initial de simplicité et accepter son caractère intrinsèquement subjectif. Parmi les rares ouvrages qui abordent le sujet de simplicité avec sérieux, celui de John Maeda, un designer de renommée internationale professeur au MIT, sort du lot. Il décrit dans son ouvrage dix lois de simplicité applicables au design industriel en général. Nous nous inspirons librement de six d’entre elles pour proposer six facettes de simplicité applicables dans le contexte des systèmes informatiques et ceci à tous les niveaux d’une architecture : fonctionnelle, applicative, logicielle ou matérielle.
1. La simplicité par réduction : éliminer le superflu est évidemment au cœur de l’idée de simplicité. Il s’agit non seulement de supprimer ce qui inutile ou redondant mais aussi ce qui n’est que peu utile. Un principe de rusticité qui part du constat empirique, connu sous le nom de principe de Pareto, que 80 % des effets néfastes de complexité sont causés par 20 % des fonctionnalités les moins utiles. Appliquée au nombre de technologies utilisées, une telle réduction permet une meilleure maîtrise et une meilleure prédictibilité des comportements du système. Appliquée aux connaissances, la devise pourrait s’énoncer ainsi : connaître peu d’outils et de concepts mais les connaître de manière approfondie.
2. La
simplicité par masquage : protéger un utilisateur de la
complexité en la masquant lui procurera un sentiment de simplicité. Rien
d’objectif en l’occurrence, nous sommes dans la subjectivité pure. Le masquage
est une illusion agréable à l’utilisateur, voilà tout.
Le plus souvent cette
opération de masquage aura un coût car la complexité globale du système
augmentera. L’encapsulation de la complexité est à l’origine des couches d’abstraction d’une architecture. Les frameworks logiciels, comme Spring ou
Hibernate, encapsulent certaines formes spécifiques de complexité. Un
système d’authentification unique de type SSO masque toute
la complexité liée à la fédération d’identité. Bref, un effort d’apprentissage est épargné à une certaine catégorie
d’utilisateurs.
3. La
simplicité par l’organisation : organiser c’est mettre de la structure là
où il n’y en avait pas. C’est lutter contre l’augmentation spontanée du
désordre de tout système livré à lui-même. Dans un cadre IT, l’accumulation et
l’obsolescence des technologies, les morceaux de code écrits sans conception,
les forces politiques chaotiques contribuent à cette augmentation.
Organiser c’est
réduire le nombre de sous-systèmes pour réduire la probabilité d’un dysfonctionnement
global. Enfin, c’est rendre un système intelligible à un esprit humain c.-à-d. rendre
possible l’apprentissage de son fonctionnement.
4. La simplicité par l’apprentissage : apprendre fait paraître simple ce qui paraissait complexe a priori. Apprendre c’est construire un modèle mental utile pour résoudre une certaine catégorie de problèmes. En contrepoint au principe de masquage, un problème que l’on sait résoudre c’est une complexité qu’il n’est plus nécessaire de masquer. Un développeur qui maîtrise l’optimisation des requêtes SQL n’aura pas besoin de recourir à un framework qui encapsule cette tâche et augmente le niveau d’abstraction du code. L’apprentissage autorise la rusticité.
5. La simplicité par gain de temps : qu’un système ou un individu nous fasse économiser du temps et nous ressentons aussitôt une impression de simplicité. Personne n’aime attendre. Disposer de temps c’est d’une part avoir la possibilité de l’investir dans les tâches qui en requièrent une quantité incompressible, comme celles des rubriques 3. 4. ou 6. Mais c’est aussi et surtout la possibilité d’en jouir librement.
6. La simplicité par la confiance : qu’on l’accorde à une personne ou un système réputé fiable, la confiance permet la détente de l’esprit. Elle crée un calme assimilable à l’expérience concrète de la simplicité. L’absence de confiance à l’inverse est une source de complexité, technique ou sociale, car elle génère d’innombrables tâches de contrôle. Entre partenaires (un client et son prestataire p.ex.) la confiance est source de simplicité car elle dispense d’établir des contrats qui prétendent anticiper de part et d’autre toutes les manquements et les traquenards possibles.
Le point essentiel à retenir est que ces six facettes ne sont pas indépendantes. Elles participent toutes d’un ressenti de simplicité mais il faut les comprendre sur le mode des vases communicants. L’accroissement de la simplicité par masquage (2) par exemple coûtera du temps (5) et de l’organisation (3). Un effort d’apprentissage accru (4) permettra de réduire le nombre des automatismes (1) et le besoin de masquage (2). Créer de la confiance (6) demande du temps (3). Générer de la valeur revient en définitive à faire un bilan lucide de ces six facettes. Il s’agit de répondre à la question : combien de personnes bénéficient d’une certaine facette de simplicité, durant combien de temps et pour quel coût ?
Parions que s’il existait une méthode pour effectuer ce bilan, voilà belle lurette qu’elle aurait été trouvée. La quête d’indicateurs de complexité ou de simplicité utiles nous semble donc vaine. Nous pensons que l’approche la plus efficace et la plus pragmatique consiste à décliner, pour chaque projet et sur chaque couche de l’architecture[2] d’un SI, le bilan des six facettes de simplicité présentées ici.
--------------
[1] C’est la définition des classes de complexité comme P ou NP en informatique
théorique.