Développement logiciel : viser la perfection ou accepter les défauts ?

A l'occasion du Syposium Gartner 2008, j'ai eu l'occasion de suivre une session "non-conformiste" ("maverick session") passionnante de Nick Jones (habituellement spécialisé dans les technologies mobiles) dans laquelle l'analyste développait l'idée qu'avec leur complexité croissante, la cible de logiciels sans défaut devient une utopie et qu'il vaudrait mieux consacrer ses efforts et ses budgets à préparer et gérer les conséquences des défauts qu'ils comportent inévitablement.
Lydia Leong, autre analyste de Gartner, développe maintenant des idées similaires, en partant du constat que les infrastructures de cloud computing qui se popularisent sont elles aussi loin d'être parfaites et requièrent de nouvelles approches d'architecture et de conception des applications. Le postulat de base est réel et, ceux qui ont "tâté" du nuage pourront le confirmer, les incidents sur les serveurs, le stockage ou le réseau sont des événements courants dans la vie d'une application en cloud. Lorsqu'il s'agit d'indisponibilités "pures et simples", l'architecte peut toujours compter sur les mécanismes de redondance plus ou moins inhérents aux offres les plus sérieuses, mais des problèmes plus insidieux sont nettement plus complexes à prendre en compte, par exemple la variabilité des temps de réponse des services sur le web.
Traditionnellement, les applications sont conçues en supposant que ces problèmes ne se produiront pas et ce sont sur les responsables des infrastructures de l'entreprise que retombe la responsabilité de garantir la fiabilité des systèmes dont ils ont la charge. Les DSI auraient donc facilement le réflexe de considérer que ce risque est une raison supplémentaire pour éviter le cloud computing et continuer à privilégier leurs installations internes supposées "parfaites".
Pourtant, je prétends que cette approche ne suffit pas à écarter la menace et que les réflexions sur la "tolérance applicative aux pannes" restent un impératif dans toutes les configurations. En effet, les architectures applicatives mises en oeuvre de nos jours dans les grandes entreprises deviennent tellement complexes et impliquent tellement de composants, internes et externes, que la fiabilité de l'infrastructure devient presque anecdotique dans la gestion des incidents.
Pour prendre un exemple auquel je suis actuellement confronté, prenez un système relativement simple de e-commerce (qui n'est pas déployé dans le cloud). Pour encaisser les paiements des internautes, il fait appel à un composant externe, comme tant d'autres sites. L'application a été conçue, sans surprise, comme si le module de paiement fonctionnait parfaitement ou, au pire, devenait totalement indisponible. Malheureusement, l'expérience prouve que la réalité est bien différente : parfois les temps de réponse s'allongent et l'application "croit", à tort, que le paiement a échoué, parfois le service fournit des résultats incohérents... Nous sommes bien là dans un cas, qui n'a rien d'exceptionnel, où il aurait été utile de prévoir le pire dès la conception...
Qu'il s'agisse des incidents touchant les infrastructures ou des inévitables bugs émaillant les applications, il serait vain d'espérer pouvoir tous les éviter, surtout lorsqu'ils échappent à notre contrôle, comme dans le cas du cloud computing ou de l'utilisation de services externes. La seule solution qui reste est donc de concevoir des systèmes qui acceptent ces anomalies et les gèrent au mieux. Naturellement, cela demande une nouvelle approche de l'architecture et de la conception des applications, qui n'est pas encore répandue chez les professionnels. La bonne nouvelle est qu'avec la popularité grandissante du nuage, les compétences nécessaires vont se développer...