L’IT en quête de simplicité

Objectif simplicité

« 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.

Téléchargez cet article

[1] C’est la définition des classes de complexité comme P ou NP en informatique théorique.
[2] Approche présentée dans l’ouvrage Managing Complexity of Information Systems – Wiley 2011.