Merci pour vos commentaires. Plusieurs remarques :

• La révolution est effectivement plus technique que conceptuelle. Mais c’est souvent le cas. On parlait de réseau mondial d’ordinateurs bien avant la "révolution internet". Ce qui est important c’est que cela devienne possible et donc réel. Par ailleurs des applications comme Seti@Home étaient développées spécifiquement en prenant en compte le "cluster" qui allait l’héberger. La grande nouveauté du "cloud computing" c’est que l’on développe un système par dessus lequel les applications sont crées de façons transparentes et sont isolées de tout l’aspect technique. 
• Concernant la sécurité il s’agit la comme je l’ai dit plus haut du plus gros problème. Et il y a de vrais réticences sur ce point, parfois justifiées, parfois non. Mais au dela de l’aspect technique vous confiez déja votre trésorerie à une ou plusieurs banques et rien que votre relevé bancaire serait très intéréssant pour vos concurrents. Et aucun des fournisseurs de "cloud" n’aura intérêt à ce qu’un scandale de confidentialité n’éclate car cela ruinerait leur business model. (Sans compter les dommages et intérêts colossaux). Pour ce qui est de la cryptographie, on sait faire des codes qui sont très difficiles à cracker par le commun des mortels. L’essentiel est que le coût de cassage du code soit supérieur à la valeur des informations chiffrées. 
• Concernant la mise en transparence de la technique (Philou) je répondrai que l’on entends la même chose à chaque fois que l’industrie informatique franchit une étape. Les plus vieux trouvaient que l’on ne pouvait pas coder autrement qu’en Assembleur, puis que laisser gérer la mémoire par le systéme d’exploitation était une perte de performance et une hérésie, puis que la gestion automatique de la mémoire était une hérésie, etc, etc, ... Or l’expérience a montrée que simplifier le développement permet à l’humain (à compétence égale) de faire moins d’erreurs et une partie de la perte brute de performance est regagnée par une meilleure conception. Et on regagne souvent comme cela ce qui se perd de l’autre coté. Prenez le Java. Ce langage a la réputation d’être lent parce que à ces débuts, on mettait les plus mauvais programmeurs dessus ou que l’on ne prenait pas le temps de former. Mais si vous prenez un programmeur bien formé et que vous le mettez sur une application complexe, la perte de performance sera de seulement 5 à 10% par rapport au C++. Ce qui est largement amorti par la loi de moore. Et puis le mauvais programmeur qui fait du Java, si vous lui aviez donné un compilo C++ en main je ne vous explique même pas le désastre. Je ne dis pas qu’il ne reste pas des cas ou un codage à l’ancienne même en assembleur n’est pas indispensable. Mais cela concerne un très faible pourcentage des développements. 

Après comme le montrent certains posts, il y a visiblement une barrière à franchir pour que les utilisateurs l’acceptent. Mais la même barrière a existé du coté d’internet (je me souviens l’air halluciné de mes parents la première fois que je leur ai montré le jouet ou encore les grandes peurs liées aux fraudes à la CB) et tout s’est résolu. 

Il faut bien voir que comme toute nouvelle techno, le développement prendra dix bonnes années à la fois pour l’aspect technique mais aussi pour que les gens l’acceptent et se l’approprient.