L'élégance des solutions

Il est très facile, lorsque l'on travaille dans l'informatique, de se concentrer sur de grandes solutions complexes. Il semble que ce soit là que doivent se trouver les bonnes solutions – de vastes solutions, beaucoup de logiciels, tous les gadgets les plus récents. Ce que nous faisons est passionnant et il est très facile de se laisser emporter par l'élan. Il est plaisant de mener des projets ambitieux et stimulants. Entendre ce que font les autres professionnels de l'informatique, comment d'autres entreprises résolvent leurs problèmes et discuter avec des fournisseurs ayant de grands systèmes à nous vendre, tout cela ajoute à l'enthousiasme et il est très facile de perdre le sens de la portée et de l'objectif ; il est si courant de voir des solutions démesurées et complexes à des problèmes simples qu'on en vient à croire que c'est tout simplement ainsi que fonctionne l'informatique.

Mais il n'en est rien. La complexité est l'ennemie tant de la fiabilité que de la sécurité. Les solutions inutilement complexes augmentent les coûts aussi bien d'acquisition que de mise en œuvre et de maintenance, tout en étant généralement plus lentes, plus fragiles et en présentant une vaste surface d'attaque plus difficile à appréhender et à protéger. Les solutions simples, ou plus justement, élégantes, constituent la meilleure approche. Cela ne signifie pas que toutes les conceptions seront simples, loin de là. Des conceptions complexes sont souvent nécessaires. L'informatique n'est guère un domaine dépourvu de complexité. En réalité, on considère souvent que le développement logiciel est peut-être la plus complexe de toutes les entreprises humaines, du moins parmi celles menées à une certaine échelle. Une installation informatique typique comprend des millions de lignes de code, des centaines ou des milliers de protocoles, un grand nombre de systèmes interconnectés, des couches de configurations logicielles uniques, plus de paramètres qu'aucune équipe ne pourrait jamais connaître, et c'est seulement alors que nous y ajoutons la complexité de centaines, de milliers ou de centaines de milliers d'humains imprévisibles et irrationnels qui tentent d'utiliser ces systèmes, chacun à sa manière. L'informatique est, sans aucun doute, complexe.

Ce qui importe, c'est de reconnaître que l'informatique est complexe, que cela ne peut être totalement évité, mais de s'attacher à concevoir et à élaborer des solutions aussi simples, aussi harmonieuses… aussi élégantes que possible. Cette idée de conception vient, du moins selon moi, du génie logiciel, où le code complexe est considéré comme une erreur et où le code simple et élégant, facile à lire et à comprendre, est tenu pour réussi. L'un des plus grands compliments que l'on puisse adresser à une ingénieure logicielle est que son code soit jugé élégant. Comme il est approprié que cette célèbre citation soit attribuée à Blaise Pascal, dont l'un des langages de programmation les plus populaires des années 1970 et 1980 porte le nom (traduite ici sommairement… de l'original français) : “Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte.”

Il est souvent bien plus facile de concevoir des solutions complexes et alambiquées que de déterminer quelle approche simple suffirait. Que nous soyons pressés ou que nous ne sachions par où commencer une recherche, l'élégance représente toujours un défi. L'élan de l'industrie pousse à promouvoir la voie la plus difficile. Il est dans l'intérêt des fournisseurs de vendre davantage de matériel, non seulement pour réaliser la vente initiale, mais aussi parce qu'ils savent qu'à davantage d'équipement correspond davantage de revenus de support, et que si suffisamment de nouveaux équipements complexes sont vendus, les besoins de support cessent d'augmenter de manière linéaire pour croître de manière géométrique, du support supplémentaire étant nécessaire non seulement pour l'équipement ou le logiciel lui-même, mais aussi pour la configuration et le support des interactions entre systèmes ou des personnalisations additionnelles. Les incitations financières qui sous-tendent la complexité sont considérables, et elles ne s'arrêtent pas aux fournisseurs. Les professionnels de l'informatique gagnent une grande sécurité de l'emploi, ou l'illusion de celle-ci, en gérant de vastes ensembles de matériel et de logiciels qu'il est difficile de transmettre sans heurts à un autre professionnel de l'informatique.

Souvent, la complexité est tellement présupposée, tellement attendue, que le processus de sélection d'une solution débute en tenant pour acquise une grande complexité, sans la moindre prise en compte de la possibilité qu'une solution moins complexe puisse suffire, voire se révéler supérieure indépendamment même de la question de la complexité et du coût. La complexité est parfois même si complètement liée à certains concepts que j'ai réellement été confronté à l'incrédulité face à l'idée qu'une solution simple puisse surpasser une solution complexe en matière de prix, de performance et de fiabilité.

La rhétorique est aisée, mais quel en est un exemple concret ? Les meilleurs exemples que je rencontre aujourd'hui sont pour la plupart liés à la virtualisation, qu'il s'agisse du stockage, d'une couche de gestion du cloud, de logiciels ou de la virtualisation elle-même. Je constate très fréquemment qu'une conversation portant sur la seule virtualisation évoque instantanément, pour certains, l'exigence d'un stockage en bloc partagé et en réseau, d'un logiciel coûteux de gestion de la virtualisation, de nombreux nœuds de virtualisation redondants et d'un logiciel complexe de haute disponibilité – dont aucun n'est intrinsèque à la virtualisation et dont la plupart sont rarement destinés à soutenir, ni même réellement dans l'intérêt de l'entreprise pour laquelle ils seront mis en œuvre. Plutôt que de partir des besoins de l'entreprise, ces concepts découlent essentiellement d'idées technologiques préconçues. Il est simple de pointer du doigt la complexité et de donner l'impression de résoudre un problème – la complexité crée un sentiment de réconfort. Distillez nombre d'arguments et vous entendrez : “Comment cela pourrait-il ne pas fonctionner, c'est complexe ?” La complexité procure une illusion de complétude, le sentiment d'avoir résolu un problème, mais cela peut souvent masquer le fait qu'une solution n'est peut-être pas réellement complète ni même fonctionnelle, le degré de complexité rendant la chose difficile à percevoir. Notre esprit n'accepte alors pas aisément qu'une approche plus simple soit plus complète et résolve un problème là où une approche complexe échoue, car cela paraît si contre-intuitif.

Un excellent exemple en est que nous en venons à parler de redondance plutôt que de fiabilité. La fiabilité est difficile à mesurer, la redondance est simple à quantifier. Une brique est extrêmement fiable, même seule. Il ne faut aucune redondance pour qu'une brique soit stable et robuste. Sa conception est simple. On pourrait fabriquer une structure porteuse à partir de nombreux bâtonnets redondants qui ne serait pas, et de loin, aussi fiable qu'une seule brique. Si l'on parle en termes de fiabilité – la probabilité que la structure ne s'effondre pas – il est clair que la brique est un meilleur choix que plusieurs bâtonnets. Mais si vous dites “or il n'y a aucune redondance, la brique pourrait céder et rien ne viendrait la remplacer”, vous avez l'air ridicule. Or, lorsqu'il s'agit d'ordinateurs et de systèmes informatiques, nous trouvons des systèmes si complexes que rarement les gens distinguent s'ils disposent d'une brique ou d'un bâtonnet et, par conséquent, ne pouvant déterminer la fiabilité, qui importe, ils se concentrent sur la redondance, aisée à quantifier, qui n'importe pas. Le système dans son ensemble est trop complexe, mais rechercher la solution simple, celle qui s'attaque directement au cœur du problème à résoudre, peut réduire la complexité et nous offrir, au bout du compte, une bien meilleure réponse.

Cela se constate jusque dans le RAID. Le RAID en miroir est simple : un disque ou un ensemble de disques n'est qu'une copie exacte d'un autre ensemble. C'est on ne peut plus simple. Le RAID à parité est complexe, avec des calculs sur une bande variable répartie sur de nombreux périphériques, qui doit être encodée à l'écriture et décodée en cas de défaillance d'un périphérique. Le RAID en miroir est dépourvu de cette complexité et résout le problème de la fiabilité des disques au moyen d'opérations de copie simples et élégantes, extrêmement fiables et très bien comprises. Le RAID à parité est inutilement complexe, ce qui le rend fragile. Or, ce faisant et en sapant sa propre capacité à résoudre le problème pour lequel il a été conçu, il paraît aussi, simultanément, plus fiable sur la seule base de sa propre complexité. L'esprit humain saute immédiatement à la conclusion “c'est complexe, donc c'est plus avancé, donc c'est plus fiable”, mais ni l'une ni l'autre de ces progressions n'est logique. La complexité ne suggère pas qu'une chose soit plus avancée, et le fait d'être avancé ne suggère pas qu'elle soit fiable ; mais l'esprit humain est lui-même complexe et facilement induit en erreur.

Il n'existe pas de réponse simple pour trouver la simplicité. Savoir que la complexité est mauvaise par nature, mais parfois inévitable, nous apprend à rester vigilants ; cela ne nous apprend toutefois pas quand soupçonner un excès de complexité. Nous devons demeurer vigilants, cherchant toujours à déterminer s'il existe une réponse plus élégante, et ne pas accepter la complexité comme la bonne réponse au seul motif qu'elle est complexe. Nous devons remettre en question les solutions proposées et nous remettre nous-mêmes en question. “Cette solution est-elle vraiment aussi simple qu'elle devrait l'être ?” “Cette complexité est-elle nécessaire ?” “Cela exige-t-il la complexité que j'avais présumée ?”

Dans la plupart des recommandations de conception de systèmes que je formule, la première étape de détermination technique que je franchis habituellement, après celle consistant à m'enquérir du besoin métier à résoudre, est de remettre en question la complexité. Si la complexité ne peut être justifiée, elle est probablement inutile et va activement à l'encontre de l'objectif pour lequel elle a été retenue.

“Est-il vraiment nécessaire de répartir ces disques en plusieurs grappes distinctes ? Si oui, quelle en est la justification technique ?”

“Le stockage partagé est-il vraiment nécessaire pour la tâche à laquelle vous le destinez ?”

“Les besoins de l'entreprise justifient-ils réellement le recours à des technologies de haute disponibilité distribuées ?”

“Pourquoi remplaçons-nous un système simple qui était adéquat hier par un système radicalement plus complexe demain ? Qu'est-ce qui a changé au point qu'une amélioration majeure, tout en restant simple, ne suffise plus largement mais exige des ordres de grandeur de complexité supplémentaire et des dépenses supplémentaires qui n'étaient pas justifiées auparavant ?”

Ce ne sont là que des exemples courants ; la complexité existe dans chaque aspect de notre industrie. Cherchez la simplicité. Visez l'élégance. N'acceptez pas la complexité sans l'examiner rigoureusement. Passez-la par le crible proverbial. Ne laissez pas la complexité s'insinuer là où elle n'est pas justifiée. Ne péchez pas par excès de complexité – dans le doute, échouez simplement. Trop simplifier une solution se traduit généralement par une défaillance mineure, tandis que la rendre trop complexe ouvre la voie à un degré de défaillance bien plus grand. Le pari le plus sûr est celui de la solution la plus simple. Et si une solution simple est retenue puis se révèle inadéquate, il est bien plus facile d'ajouter de la complexité que de la retirer.