Menu
Les standards d’Internet se sont imposés par leur simplicité : que ce soit TCP/IP, SMTP/POP3, HTML ou HTTP, ils étaient faciles à mettre en œuvre et à porter d’une plate-forme à l’autre. Mais la simplicité est une vertu qui est rarement appréciée des informaticiens (tout le monde connaît le fameux « pourquoi faire simple quand on peut faire compliqué ! » qui est plus qu’une plaisanterie dans notre milieu !). Ces derniers aiment trop souvent les solutions technologiquement avancées qui peuvent résoudre les cas les plus complexes, même si elles ne sont pas forcément les mieux adaptées à la situation. Au début du Web, nombreux sont les acteurs qui ont voulu remplacer HTML et HTTP jugés trop simplistes et pas taillés pour les cas les plus ardus (qui se souvient de ces tentatives basées sur Java et CORBA ?). Sun et Microsoft ont voulu « améliorer » les pages HTML avec respectivement les applets Java et les contrôles ActiveX.
Les experts veulent de la complexité !
Au grand dam des experts qui méprisent systématiquement les techniques modestes pour préférer les propositions sophistiquées, ce sont justement les solutions les plus simples qui se sont souvent imposées parce qu’elles sont simples. Toute technologie a besoin d’un certain temps avant d’atteindre sa maturité. Les performances sont tout juste correctes, et les mises en œuvre des différents vendeurs pas forcément au point. Or plus une technologie est sophistiquée, plus elle va consommer de ressources (et donc impacter les performances), et plus les problèmes de compatibilités seront fréquents. C’est ce qui est arrivé à CORBA. Peu adapté à Internet (surtout à l’époque où la plupart des particuliers en étaient toujours au bas débit) et sujet à de nombreux problèmes d’incompatibilités. CORBA n’a jamais réussi à écorner HTTP qui, avec sa version 1.1, a su résoudre ses problèmes de performance. Parfois, qui peut le plus est incapable du moins.
Tim Berners-Lee a sauvé le Web grâce à son entêtement…
Le Web est un des exemples les plus célèbres où la simplicité triomphe. L’une des critiques récurrentes auxquelles Tim Berners-Lee a eu droit dès le début est l’absence de répertoire centralisé de liens -celui-ci afin d’éviter le phénomène de liens brisés et la tristement célèbre « erreur 404 ». Berners-Lee a -heureusement- persisté. Personne n’aime le problème de liens brisés, mais l’autre alternative -avoir un répertoire centralisé de liens- aurait certainement empêché le Web de se développer comme il l’a fait. En faisant l’impasse sur la gestion des liens brisés, Tim Berners-Lee a permis à quiconque le voudrait, de créer sa page Web sans avoir à demander d’autorisation à personne (d’où le développement phénoménal qu’on a connu).
Autre composant du Web génial de par sa simplicité : le langage HTML. L’utilisation d’un format texte pour décrire une page était tout sauf évident. Au début des années quatre-vingt-dix, on s’orientait vers les environnements graphiques pour décrire la pagination (quoi de plus normal ?) et utiliser un format texte semblait désuet, il a pourtant de nombreux avantages : sa simplicité fait que n’importe qui peut créer des pages Web en utilisant n’importe quel outil et sur n’importe quelle plate-forme… Ça n’est pas rien !
N’importe quelle application écrite en n’importe quel langage peut facilement générer du HTML. Et comme il est au format texte, on peut également le stocker facilement dans une base de données. Mais simplicité ne veut pas forcément dire limité. HTML est un langage qui contient beaucoup d’intelligence implicite. Tout d’abord, les termes utilisés sont uniquement des termes de pagination. Le langage parle de paragraphe, de tableau et non de widget, de handle et autres termes techniques. Le fait que le HTML ne permette pas une description au pixel près fait que l’on n’a pas besoin de préciser l’emplacement au pixel près des éléments.
Ensuite, si l’on définit un tableau dont la largeur fait 50% de la largeur de la page, c’est au navigateur non seulement de déterminer la largeur du tableau en pixels, mais également de déterminer la largeur de chaque colonne suivant le texte contenu. Par comparaison, encore plus de quinze ans après le Web, les environnements graphiques traditionnels vous obligent à élargir vous-même les colonnes d’un tableau lorsqu’elles sont trop étroites, même s’il y a de la place. Pareillement, une des forces du SQL est d’avoir été au format texte. Si SQL a de nombreux défauts (il n’est toujours pas vraiment standardisé malgré toutes ces années : si des normes existent, chaque SGBDR possède encore ses propres nuances de SQL), il reste un langage simple (du moins pour les requêtes de base), qui peut être généré facilement par n’importe quelle application écrite en n’importe quel langage sur n’importe quelle plateforme.
Pourquoi une telle obsession de faire complexe ?
L’une des raisons est une déformation professionnelle. Lorsqu’on a un marteau en main, tout ressemble à un clou. Les informaticiens n’aiment pas le bricolage, même quand ça marche. L’autre raison est que plus une solution est complexe, plus elle justifie l’existence d’une organisation. Difficile de vendre un serveur Web si le protocole est simple à mettre en œuvre. Ce qui explique que tous les éditeurs commerciaux se sont tournés vers la vente de serveurs d’applications tels que WebSphere d’IBM, un serveur très puissant et performant mais pas des plus simples à utiliser. Une des raisons pour lesquelles Microsoft ne sait pas (ou ne veut pas) faire simple réside dans la tendance à toujours rajouter des fonctionnalités pour justifier aux clients d’acheter la prochaine version.
Le dogmatisme, une maladie fréquente chez les grands acteurs
Le dogmatisme technique est une maladie fort répandue en informatique, surtout chez les acteurs dominants… Le rôle de leader d’un marché impose presque naturellement d’avoir une « vision » technique pour orienter ce marché. Les dirigeants des grandes sociétés d’informatique aiment à être dépeints comme des spécialistes de la technique ayant fréquemment des visions technologiques éblouissantes à tel point qu’il doit être dangereux de les accompagner en voiture !
Hélas, ces illuminations débouchent souvent sur des propositions d’architectures qui dépassent rarement leurs présentations PowerPoint !
Ce n’est pas pour rien que tous (ou quasiment tous) les éléments techniques qui se sont imposés ces vingt dernières années proviennent, soit des milieux universitaires, soit de startups minuscules. En particulier dans le cas des startups, le dogmatisme technique ne joue aucun rôle, car il est obligé de s’effacer devant le pragmatisme technique imposé par des ressources restreintes qui se double d’un fort courant novateur pour faire la différence; les universités sont capables d’un grand pragmatisme du fait d’un manque de ressources comme du plus grand dogmatisme en ne regardant que l’aspect théorique. C’est bien la combinaison gagnante, formidablement plus puissante que l’attitude arrogante du type « nous savons puisque nous sommes les plus forts ! »
Certes, les tenants de la solution la plus élégante et la plus « parfaite » peuvent avoir quelquefois raison sur le plan théorique, ils ont en revanche le plus souvent tort sur le plan pratique. Car le monde réel ne s’accommode que de solutions souples capables de s’insérer dans un environnement perturbé.
TCP/IP ou la promesse du “meilleur effort”, mais pas plus !
TCP/IP est sans doute le meilleur exemple de cette bonne adaptation au monde tel qu’il est alors que les promoteurs de l’OSI voulaient à tout prix cadrer à ce que devrait être un protocole dans un monde tel qu’on voudrait qu’il soit. La philosophie du « meilleur effort » paraît sûrement insuffisante à certains, il n’empêche qu’elle s’est avérée assez performante et fiable pour s’imposer largement.
Idem pour l’histoire du client-serveur… Si c’est le client-serveur de données qui s’est imposé dans la grosse majorité de ces projets, ce n’est pas un hasard… Alors qu’au début du client-serveur de nombreuses déclinaisons techniques étaient répertoriées, c’est la plus « disponible » qui s’est naturellement répandue, car les éditeurs de SGBDR ont proposé rapidement les middlewares nécessaires et suffisants pour permettre aux applications sur PC d’agir en tant que « frontaux » des SGBDR. La mise en œuvre de traitements coopératifs, au travers du protocole APPC d’IBM offrait une bien plus grande sophistication que le « simple » client-serveur de données, mais au prix d’un développement bien plus complexe… Une nouvelle fois, c’est la simplicité technique, synonyme de facilité de mise en œuvre, qui s’est imposée (de la même façon que TCP/IP a triomphé d’OSI ou que le Web a balayé les autres formes de services en ligne…).
Idem encore pour ce qui est des bases de données réparties. On a attendu en vain la mise au point des mécanismes assurant leurs cohérences (commit à deux phases puis même à trois phases…) pour constater au bout du compte que seule la pratique d’une réplication intelligente permettait de fonctionner en mode distribué au niveau des données.
La simplicité est la qualité “mal-aimée” du milieu informatique, mais ce sont les solutions simples qui résistent au monde réel, s’imposent durablement, changent notre quotidien et nos habitudes…
