J’ai déjà parlé du concept de simplicité sur ce blog. J’espère que tout le monde est convaincu des avantages que cela procure à tous les niveaux :

• Une interface simple sera plus facile à comprendre et à utiliser ; elle sera plus ergonomique.
• Un code simple sera plus facile à corriger et à faire évoluer ; il sera plus facile à maintenir.
• Une procédure ou une méthode sera adoptée d’autant plus rapidement qu’elle sera simple à appréhender et facile à mémoriser.

Nous sommes d’accord, le «simple», c’est bien. Et comme d’habitude, c’est aussi le moment de dire que le «simpliste», ce n’est pas bien. Faire quelque chose de simpliste, c’est lorsqu’on recherche la simplicité aveugle ; quand on confond «en faire moins» avec «en faire le moins». Il faut parfois complexifier un peu un programme pour en simplifier l’ergonomie. Ou faire des concessions sur la simplicité d’une procédure si cela peut en augmenter l’efficacité.

Bref. Ce dont je veux vous parler aujourd’hui, c’est du concept de rusticité.

L’un des fondements du travail d’informaticien, c’est d’aimer la technologie, de se passionner pour l’avant-garde du high-tech, de chercher à connaître les technos du futur. C’est ainsi qu’on cherchera à mettre en œuvre des concepts ou des briques logicielles (ou matérielles) que nous ne maîtrisons pas forcément, pour le plaisir d’apprendre à les utiliser. Souvenez-vous ce que je disais sur la R&D : il ne faut pas confondre développement et veille technologique.

Sans aller jusqu’à faire de la recherche alors qu’on devrait faire du développement, on peut conduire nos choix en se laissant porter par des effets de mode. Quelle est la techno «hype» du moment ? Quels sont les derniers «buzzwords» à connaître ?

En entreprise, les facteurs qui conduisent à un choix technologique sont multiples. La stabilité et la pérennité sont très importants. Ils le sont souvent plus que la performance ou le coût.
Ajoutez cela à la simplicité, et vous aboutissez à la «rusticité».

Une techno rustique, c’est quoi ?

Attention à ne pas comprendre de travers ce que j’essaye d’expliquer. Je ne suis pas en train de dire qu’il faut systématiquement utiliser des technologies antédiluviennes, au nom de leur rusticité. Moi je parle de “rusticité high-tech”, si je puis dire 🙂

Prenons un exemple au sujet des langages de programmation :

1. Coder un site web en Fortran, ce n’est pas rustique, c’est débile. Votre site sera difficile à maintenir, vous aurez du mal à trouver des développeurs Web compétents dans ce langage, vous n’aurez aucun gain de performance par rapport à d’autres langages, et il vous manquera l’accès à un certain nombre de librairies très utiles.
2. Par contre, une application de calcul scientifique distribuée sur un cluster pourra être codée en Fortran. C’est un choix très répandu : C’est un langage sans allocation dynamique, donc qui s’optimise très bien sur les architectures distribuées ; de nombreux scientifiques continuent à maintenir du code écrit en Fortran il y a 30 ans, sans avoir objectivement besoin de changer de langage ; réutiliser ce code est une bonne idée.

Un exemple concernant l’innovation fonctionnelle :

1. Depuis la première version de Microsoft Word sous Windows, l’ergonomie générale des logiciels de traitement de texte WYSIWYG a finalement peu évolué, si on la compare aux changements technologiques qui sont intervenus dans leurs entrailles.
2. Lorsque le logiciel ICQ est sorti en 1996, c’était une révolution du point de vue des fonctionnalités qu’il proposait. Il a créé les messageries instantanées. L’IRC existait déjà, permettant à des utilisateurs de discuter entre eux en temps réel, au sein d’espaces numériques partagés. L’email existait aussi, permettant à une personne d’envoyer des messages à une unique personne. Mais ICQ offrait la possibilité de se constituer une liste d’amis, de voir leur statut de connexion en temps réel, et d’instancier des discussions personnelles avec chacun d’eux. Pourtant, d’un point de vue technologique, il s’agit là d’une application client-serveur particulièrement basique.

Quelques autres exemples :

• Une société française, éditrice d’une solution de sauvegarde en réseau, a besoin de porter son logiciel serveur sur un très grand nombre de plate-formes. Ce logiciel contient une base de données. Plutôt que d’implémenter une solution complexe, les données sont stockées dans une arborescence étudiée sur le système de fichiers. Les répertoires servent d’index. Le seul problème, facilement gérable, est que cela peut potentiellement consommer un grand nombre d’inodes. Mais à part ça, c’est une solution simple, performante et très stable, supportée de la même manière sur tous les systèmes Posix. Pourquoi réinventer la roue, alors que les systèmes de fichiers font partie des choses les mieux optimisées dans les kernels ?
• Google a sorti son navigateur Chrome il y a deux ans. L’une des “grandes avancées” de ce navigateur était le fait qu’il utilise un processus séparé pour chaque onglet, au lieu d’utiliser un thread au sein du même processus. On est en plein dans le rustique : Faire un fork() pour créer un nouveau processus, ça existe depuis la nuit des temps ; par contre, on enseigne que les threads sont moins gourmands en ressources, plus rapides et plus souples, et ils sont donc présentés comme étant la solution de choix quand on veut faire des traitements parallèles. Sauf qu’on a tous vu un jour un navigateur se planter tout entier, juste parce que l’un des onglets contenait un plugin qui est parti en erreur. Le choix du multi-processus au détriment du multi-thread, c’est un choix rustique mais très intelligent.
• Dans le domaine des appareils portables (téléphones, smartphones, PMP, …), un des enjeux majeurs concerne les écrans. Chaque constructeur essaye de mettre au point des écrans qui soient lisibles, contrastés, lumineux sans être fatiguant pour les yeux, réactifs et bons marchés. Dans ce domaine, les nouvelles technologies pleuvent : IPS, AMOLED, Super-AMOLED, Super-LCD, E-Ink, Mirasol, Pixel Qi, … Mais des appareils se préparent à déferler sur le marché, équipés d’écrans « C-Paper » qui reprennent une technologie éprouvée, remise au goût du jour, et dont le rapport qualité/prix semble particulièrement bon (voir cette chronique sur le site Blogeee). C’est le genre de chose qui peut faire la différence dans un univers high-tech ultra-compétitif.
• Dans les années 90, et jusqu’au début des années 2000, l’informatique lorgnait du côté de la reconnaissance d’écriture et de la reconnaissance vocale. Le Newton d’Apple, puis le Palm Pilot et les PocketPC reposaient tous sur un principe qui semblait alors naturel : pour communiquer avec la machine, écrivons dessus avec un stylet. Cela a fonctionné plus ou moins bien. Pareil pour les logiciels IBM ViaVoice et Dragon Dictate, qui nous proposaient de commander nos ordinateurs à la voix. Qui le fait aujourd’hui ? De nos jours, les smartphones se commandent au doigt − le stylet à disparu − et les textes y sont tapés sur des claviers virtuels. C’est moins futuriste, mais ça fonctionne beaucoup mieux. Et si la reconnaissance vocale s’y intègre chaque jour un peu mieux, on reste sur des usages de niche (traduction, aide aux handicapés) éloignés des promesses passées.

Et concrètement ?

Dans le quotidien d’un informaticien, la rusticité revêt de nombreuses formes, mais repose toujours sur 3 aspects :

1. Simplicité : Tout à déjà été dit à ce sujet, non ? Supprimez l’inutile, gardez l’essentiel.
2. Stabilité : Privilégiez les solutions éprouvées, dont les qualités ont été vérifiées au fil du temps, et qui resteront valables plus longtemps que la durée pendant laquelle vous en aurez − a priori − besoin.
3. Connaissance : Privilégiez les solutions que vous maîtrisez. Ne faites pas confiance (à une techno, un choix fonctionnel ou autre) si vous êtes totalement néophyte sur le sujet. Quand vous serez monté en compétence et que vous aurez fait des prototypes, vous pourrez alors envisager d’y aller ; mais pas avant.

Alors je ne peux que vous conseiller de garder tout cela à l’esprit, ça pourra vous servir.