Liste de partage de Grorico

Je vous l’avais dit que ça serait bientôt possible ! Et voilà, l’algo de chiffrement du GSM baptisé le A5/1 (64 bits) utilisé pour protéger les conversations émisent par 80 % des téléphones du monde entier vient d’être cracké ! W00T ! Et bien sûr cela a été rendu public par le CCC lors de leur petite conférence annuelle.

Alex Biryukov, Adi Shamir et David Wagner ont démontré qu’il leur fallait moins de deux minutes a un petit PC équipé de 128 MB de RAM et de 2 disques durs de 73 GB contenant une série de codes, pour analyser et déchiffrer l’algo A5/1 durant les premières minutes d’une conversation. Ces dictionnaires de déchiffrement sont en libre téléchargement sur les réseaux Bittorrent et la liste du hardware ainsi que les logiciels necessaires à un tel déchiffrement seront bientôt diffusé en open source sur le net.

Alors évidemment, les compagnies de téléphone sont rassurantes car elles annoncent un passage imminent (lol) au A5/3 (128 bits). Ce qui nous fait une belle jambe quand on sait que Elad Barkhan, Eli Biham et Nathan Keller, des chercheurs de Technion, l’institut technologique d’Israel ont déjà mis au point de nouvelles attaques contre le A5/3…

Evidemment, un tel algo utilisé depuis 1988 ne pouvait pas rester solide aussi longtemps… (Ils rêvent les mecs quand même…)

Vu sur Twitter (@MarcBotte), la preuve absolue de la domination de Google en matière de respect de l'anonymat. Si, après des soirées trop arrosées, vous vous êtes levés avec la tête dans le (...

L’informatique est friand des trigrammes et des abréviations et le monde du cloud computing ne fait pas exception à la règle : Iaas, PaaS, SaaS. Ces trois termes proposent de segmenter l’offre de cloud computing. Au delà des mots, qu’est-ce que cela signifie vraiment pour votre entreprise. L’objectif de cet article est de proposer deux visions différentes pour segmenter ce marché : l’une par type de contrat offert, l’autre par typologie de service offert. Nous en tirerons en synthèse quelques repères pour analyser une offre sur ce marché.

Quelques termes

Le cloud computing désigne une nouvelle façon de commercialiser des ressources informatiques au sens large sous forme de service. En pratique, une application web ou un service web permet de réserver une ressource (application, machine, plateforme), d’interagir avec elle au travers d’internet, et de payer cette ressource au prorata de l’utilisation, sans limite de scalabilité.
Le terme de ressource est à prendre ici au sens large : il peut s’agir de logiciels, de machines, d’unités de stockage. Le terme cloud est largement repris depuis quelque temps et il a parfois divergé. Parmi les caractéristiques qui permettent d’identifier ces offres je retiendrai :

• l’aspect virtualisation qui consiste à utiliser des ressources partagées avec d’autres utilisateurs, à pouvoir provisionner aux besoins – de façon élastique ces ressources. En contrepartie elles sont hébergées chez le fournisseur et l’utilisateur n’en maîtrise pas forcément la localisation
• l’aspect self-service c’est-à-dire la capacité à provisionner ces ressources et à y accéder via une simple URL sur internet
• l’aspect paiement à la demande (pay-as-you-go) qui remplace l’investissement (machines, licences) par le paiement de l’application à l’abonnement (location pour un nombre d’utilisateurs et une durée déterminée) ou le paiement de l’application à l’utilisation (facturation à l’URL accédée ou aux ressources consommées).

Analyse par types de contrat offerts

L’offre de cloud computing peut être présentée comme une pile de trois services.
IaaS pour Infrastructure as a Service, désigne les fondations du cloud computing. Il s’agit d’offres de capacité de calcul, stockage et réseau sous une forme comparable à une machine virtuelle.

• PaaS pour Platform as a Service désigne des offres permettant d’héberger des applications respectant certains critères, d’offrir un stockage structuré et requêtable, de fournir un service de messagerie entre machines, etc.
• SaaS pour Software as a Service désigne le fait de distribuer un logiciel en ligne. Le concept est utilisé depuis très longtemps pour les clients mails. Il a été démocratisé avec la suite bureautique en ligne Google Documents, le logiciel de CRM en ligne SalesForces et plus récemment par tous les services Microsoft Online Services.

Cette segmentation s’appuie globalement sur la notion de ressources partagées ou gérées en propre et de contrat conclu entre l’utilisateur et le fournisseur de cloud computing. Elle peut être représentée de la façon suivante :

Contrat au niveau de la machine virtuelle

Le contrat de plus bas niveau proposé est comparable à une machine virtuelle. On parle alors d’Infrastructure as a Service. C’est le cas par exemple du couple EC2 et EBS chez Amazon. Les autres acteurs de ce domaine (ex. GoGrid) respectent le même contrat. C’est un contrat simple, parfaitement reconnu par les systèmes d’exploitation Linux, Windows, Solaris (à quelques paramétrages près, ce qui incite à utiliser une image du système d’exploitation préinstallé par Amazon ou par l’éditeur du système d’exploitation).

Ce contrat offre peu de dépendance car même dans un DataCenter traditionnel, Linux et Windows sont les deux systèmes d’exploitation les plus répandus. Avoir un contrat de type machine conduit à remplacer un achat de matériel réalisé auprès d’un constructeur de serveurs par une location souscrite auprès d’un fournisseur de cloud computing.

Dans ce type de contrat, on partage avec d’autres clients la machine. Au niveau de la sécurité, le mécanisme de virtualisation garantit que le système d’exploitation que vous installez est isolé : il ne peut accéder qu’à son espace mémoire, à son volume de disque. Un système comme Amazon Virtual Private Cloud garantit en plus que vos machines ne sont adressables que sur votre sous-réseau.

Cependant les ressources physiques restent partagées. Se pose alors la question des performances. Si on prend l’exemple d’Amazon, celui-ci s’engage sur des équivalents CPU et une quantité de mémoire vive qui sont, d’après la documentation, dédiées à chaque instance. Les entrées/sorties (I/O) du stockage et du réseau sont partagées avec les autres utilisateurs. Le type d’instance choisi (et donc le prix du service) ne donne qu’un avantage qualitatif : I/O « moderate » ou « high ». Si on se penche sur le service Amazon EBS fournissant des disques durs persistants pour EC2, le paragraphe « Volume Performance » indique que les performances seront influencées par les capacités I/O et seront à tester au cas par cas. Aujourd’hui, la blogosphère est assez active sur le sujet, je citerai cet article qui indique des débits disques pour EC2 (hors EBS) tout à fait raisonnables. Une présentation réalisée conjointement par une startup utilisant MySQL sur EC2 et MySQL fait également état de performances qui l’ont satisfaite (diapositives 27 à 29) malgré quelques points négatifs.

Alors que retenir? Le contrat minimal du cloud computing est de partager des ressources. Intrinsèquement cela suppose un risque de sécurité et une question sur les performances. La sécurité doit être garantie de façon contractuelle par le fournisseur de service. Le contrat implicite au niveau de la performance sera de dimensionner les instances selon ses besoins. La comparaison se fera au niveau du prix payé pour les ressources consommées par rapport au coût d’une installation physique. Le gain sera particulièrement important pour une infrastructure peu utilisée, dimensionnée pour les pics de charge. Très difficile à amortir à l’achat, elle sera beaucoup plus rentable sur le cloud où l’on paye à la consommation.

Contrat au niveau des API

Dans le contrat de type IaaS, seul le matériel est dans le cloud. Le niveau suivant consiste à inclure la plateforme chez le fournisseur. Dans ce cas le contrat repose sur des API ou un environnement d’exécution au sens du développement qu’il faudra respecter. On parle alors de Plateforme As A Service. Ce niveau de contrat est beaucoup plus diversifié. C’est le cas de Google App Engine et Microsoft Azure qui offrent respectivement un environnement Java et .NET permettant l’exécution d’applications dans le cloud. C’est également le cas de bon nombre de services Amazon : S3, Elastic Map Reduce, Paiment font également partie de cette catégorie car ils seront combinés par des développeurs pour fournir de la valeur ajoutée.

Le premier constat est qu’il y a une grande diversité des contrats et des services fournis. Google App Engine et Microsoft Azure permettent de déployer des applications développées en Java et en .NET. Cependant les API ne sont pas tout à fait identiques à leur version classique (toutes les classes du JDK ne sont pas disponibles dans Google App Engine, toutes les classes .NET ne sont pas à priori disponibles dans Azure), le packaging est également différent. Google offre une pile complètement intégrée pour réaliser des applications web. Microsoft propose une pile complète de services de la base de données relationnelle à l’environnement d’exécution d’applications web. Amazon propose des services de plus bas niveau et plus disparates : stockage de BLOB (S3), stockage non relationnel (SDB), calcul réparti (ElasticMapReduce).
La dépendance envers l’API du PaaS, est variable en fonction des plateformes, mais elle est beaucoup plus importante qu’avec une offre de type IaaS. En effet, les offres permettant une portabilité entre le cloud et un déploiement interne sont aujourd’hui très peu nombreuses. La portabilité entre plusieurs fournisseurs PaaS est aujourd’hui inexistante. Les données sont également stockées dans le cloud dans un format qui est parfois propre au fournisseur (exemple du DataStore de Google App Engine).

Dans ce type de contrat, au delà de la machine et du réseau, l’environnement d’exécution (système d’exploitation et middleware) est partagé. Au niveau de la sécurité cela signifie qu’elle devra être entièrement gérée au niveau applicatif à travers les fonctionnalités offertes par la plateforme. Au niveau des performances il faut distinguer deux types de facturation possibles :

• Sur les ressources sous-jacentes consommées. Par exemple l’offre cloud foundry de Spring Source fonctionne sur Amazon EC2 et les ressources sous-jacentes sont facturées
• Sur le nombre d’appels à des API effectuées. Par exemple Google App Engine facture le nombre de requêtes traitées, le nombre de mails envoyés

Dans le second cas, l’offre est beaucoup plus scalable car le fournisseur prend à sa charge l’optimisation pour que la 101ème requête de la seconde ne consomme pas plus de ressources que la première.

Le plus grand bouleversement viendra à mon sens du changement sur l’organisation de l’entreprise. Les tâches d’administration (montée de version, backup, monitoring des machines) sont désormais à la charge du fournisseur de cloud computing. Le contrat d’interface avec le fournisseur repose désormais sur le packaging de la mise en production. La répartition direction des études, direction de la production vole en éclat. Regardons les rôles qui doivent désormais exister dans l’entreprise :

• Développer le code, le tester et le packager (rôle de développeur)
• Réaliser les mises en production et la gestion des versions. Cela consiste à interagir uniquement avec une API
• Gérer les politiques de sécurité (provisionning des utilisateurs, contrats juridiques protégeant les données de l’entreprise)
• Allouer les ressources et gérer la facturation en fonction des pics de charge.

D’autres responsabilités sont encore mal définies et peuvent se trouver selon la plateforme et les contraintes de l’entreprise

• Etre garant des données : sauvegarde, restauration
• Diagnostiquer et réaliser des paramétrages (ex. index sur une base de données). Pour l’instant les capacités des plateformes semblent supérieures aux besoins des projets mais force est de constater que ce volet est globalement assez peu maîtrisé à l’heure actuelle.

Là encore que retenir? Une offre PaaS permet de remplacer par un abonnement, non seulement de l’investissement des machines, mais également les coûts de licence logicielle et d’administration des plateformes. Ce dernier point est à l’origine de grandes modifications dans l’organisation de la DSI car une nouvelle répartition des rôles est à inventer pour tirer partie de ces offres. Enfin les plateformes au niveau développement sont très variées et évoluent pour apporter de nouvelles fonctionnalités. Chaque offre est basée sur un contrat qui lui est propre sans portabilité possible. La dépendance envers le fournisseur est donc plus importante.

Contrat au niveau des fonctionnalités

Le dernier type d’offre de cloud computing est finalement le plus répandu. Il s’agit des offres Software as a Service. En première approche il s’agit de fournir un logiciel à travers internet. Cette approche a été démocratisée d’abord avec les WebMail puis avec des offres comme Google Documents. C’est également celle qui est entrée le plus rapidement dans le monde de l’entreprise avec des offres comme le logiciel de CRM en ligne SalesForce. Le contrat est dans ce cas un logiciel fonctionnel que l’utilisateur paye non plus sous forme de licence mais à l’utilisation.

Ce type de contrat peut en première approche être vu comme un progiciel hébergé. Comme le progiciel, les fonctionnalités seront à la discrétion de l’éditeur. Des offres comme SalesForce offrent de façon couplée un environnement (qui peut être assimilé à du PaaS) permettant de réaliser des développements personnalisés autour du logiciel. Au niveau de la sécurité, des performances et des données, les contraintes seront globalement les mêmes qu’avec une offre de PaaS. La société devra en plus savoir conserver la maîtrise des compétences métiers portées par le paramétrage de l’outil et les extensions au même titre que pour un progiciel.

Même si cette classification est la plus répandue, il est intéressant de la comparer à une autre vision. Afin de mieux comprendre les différences et les interactions entre ces différents services, je vous propose de lire ce découpage à travers le masque de lecture proposé par Philip Evans lors de sa keynote lors de l’Université du SI 2009 organisée par Octo Technology.

Analyse de la répartition des services selon la vision de Philip Evans

Son intervention, brièvement résumée, nous décrit le découpage en couches dans l’industrie informatique. L’IBM 360 a introduit le premier la notion de système d’exploitation générique qui sait faire fonctionner différentes applications (Emergence of modularity à 3′41 »). Ce découpage se retrouve parmi les acteurs internet (Stack Strategies on the Internet à 32′20 » et 48′20 »).

Infrastructure

Grâce à cet éclairage, on peut identifier dans l’offre de cloud computing un premier niveau d’offres centrées sur l’investissement. Le fournisseur fournit l’investissement nécessaire pour construire un DataCenter, assurer sa connexion, sa fiabilité. Il achète en tirant partie de l’effet d’échelles des machines nécessaires. Sa valeur ajoutée est dans l’optimisation et l’amortissement de ses ressources. Elles constituent l’ossature des offres de cloud et sont nécessairement assurées par de gros acteurs. On retrouve dans cette catégorie Amazon, Google, Microsoft, des hébergeurs. Philip Evans parle d’infrastructure. Leur business model est basé sur l’effet de masse. Pour honorer ces investissements, ces acteurs ont besoin de massivement communiquer pour attirer les clients dans leur DataCenter.

Service

On a ensuite un niveau d’offres que Philip Evans nomme service. Il nous décrit ici une valeur ajoutée basée sur l’intégration à l’infrastructure et surtout la scalabilité. Le cœur du métier est ici basé sur la technologie et l’architecture. Les services Amazon comme S3, SQS où SimpleDB rentrent parfaitement dans cette description. D’autres existent mais ne sont pas commercialisés directement comme la BigTable de Google.

Plateforme

On a ensuite un niveau d’offres appelé plateforme. Philip Evans nous le présente à travers les plateformes de réseaux sociaux comme MySpace ou FaceBook. Leur valeur ajoutée réside dans l’apport de briques qu’une communauté va s’approprier pour créer une application finale. Cela s’applique parfaitement aux plateformes logicielles : doit-on utiliser une plateforme Java/Google sur Google App Engine, Java/Spring sur Cloud Foundry ou Microsoft .NET sur Azure? Plus une communauté est importante plus elle sera rentable. A la différence des communautés de réseau sociaux, les développeurs, surtout institutionnels, sont aujourd’hui très fortement liés à une plateforme de par les normes de développement mis en place pour protéger les investissements dans les entreprises. Sur ce créneau, on notera l’offre d’appel gratuite de Google App Engine. Cette offre a pour objectif d’attirer la communauté Java et la communauté PHP qui était la seule aujourd’hui à bénéficier d’hébergements à bas coût. Microsoft et Spring Source misent plutôt sur la compatibilité avec l’existant dans l’entreprise pour attirer les institutionnels.

Communauté

Enfin on a un niveau d’offre appelé communauté par Philip Evans. On est ici dans le monde du Web 2.0 et de la collaboration. Même si la création d’un logiciel par agrégat de contributions comme Wikipedia ne rentre pas encore dans les offres d’entreprise, on note un changement dans ce sens dans les applications de type SaaS. Ainsi celles-ci se veulent beaucoup plus clé en main que les logiciels installés, la montée en compétence ayant beaucoup plus vocation à être réalisée par les utilisateurs que par des formations externes. Par ailleurs elles favorisent les agrégations et la personnalisation. Google Apps, Microsoft Online Services, SalesForce proposent ainsi nativement une très grande quantité d’API. Les utilisateurs peuvent selon les cas :

• Utiliser des portions de l’application (orientation service de Microsoft Online)
• Personnaliser directement l’application (par exemple dans SalesForces)
• Personnaliser l’application et surtout partager ces extensions avec d’autres utilisateurs (par exemple les gadgets Google remplacent graphiques et macros d’Excel et peuvent être simplement partagés)

Aujourd’hui cependant, ces initiatives sont récentes et il reste beaucoup à construire. Comment par exemple assurer la pérennité d’un outil de travail et une maintenance maîtrisée des applications? Une extension à FaceBook pourra facilement être remplacée, abandonnée, ce qui assure une sorte de sélection naturelle. Une extension SalesForce utilisée couramment dans l’entreprise devra à contrario assurer la continuité de l’activité.

Conclusion

Savoir positionner une offre de cloud computing aide ainsi à mieux évaluer la relation qu’on aura avec le fournisseur correspondant.

Choisir un contrat de type IaaS implique d’accepter de partager des ressources. Le fournisseur rentabilise le paiement à la demande par l’optimisation tirée de l’effet d’échelle. Le nombre d’acteurs sera limité du fait des investissements à consentir. Certaines offres de niveau supérieur s’appuient ainsi sur des offres IaaS existantes (par exemple Amazon EC2) pour éviter ces investissements.

Choisir un contrat de type PaaS permet de payer à l’utilisation, par exemple à la requête web pour les offres les plus scalables. Mais cela impacte beaucoup plus l’entreprise car le contrat repose alors sur des API, un modèle de programmation. La gouvernance vis à vis de ce nouveau type de fournisseur est à inventer. La dépendance vis à vis du fournisseur est également un facteur très important. Les offres présentent peu ou pas de compatibilité. Les acteurs ont intérêt à rassembler la communauté la plus vaste et n’ont pas intérêt à faciliter l’interopérabilité.

Choisir un contrat de type SaaS se rapprochera pour une entreprise comme un choix de progiciel en mode hébergé. Les offres SaaS exposées au grand public (web mail, réseaux sociaux) présentent en plus une forte empreinte communautaire : fourniture de widgets, de liens pour tirer partie du marketing viral. Si en interne dans l’entreprise un modèle analogue reste à inventer, certains concepts peuvent dès aujourd’hui être repris de façon plus large pour des sites internet : pourquoi ne pas déployer les téléchargements proposés par son site web sur Amazon S3 comme le fait Spring Source et placer de simples liens sur son site web (regardez les liens sur la page de téléchargement)?. Ou pourquoi ne pas déployer ses vidéos promotionnelles sur You tube et les insérer ensuite sur son site web?

Addendum : Ces deux propositions de segmentation ne sont bien entendu pas les seules. Juste après la rédaction de cet article on m’a ainsi fait part de cette classification en trois niveaux des plateformes disponibles sur internet réalisée par Marc Andreessen. Une vision complémentaire qu’il est intéressant de comparer.

Au nom de la rénovation urbaine, des quartiers entiers de villes comme Londres et Liverpool sont aujourd'hui la propriété de sociétés privées. Et des activités théoriquement aussi anodines que celles de déjeuner ou de prendre des photos y sont désormais interdites.

Produire de l'eau douce à partir d'eau de mer avec quatre fois moins d'énergie que dans une installation classique, c'est déjà remarquable. Cela l'est encore plus quand ces énergies sont renouvelables ou issues de la valorisation de la chaleur résiduelle des industries. L'idée ? Saler l'eau de mer !
Dessaler l'eau de mer, c'est bien, dessaler aussi la facture énergétique, c'est mieux. Si l'eau douce est essentielle pour les activités humaines, elle est aussi une denrée rare en bien...

Un rappel des objectifs et mécanismes du protocole de Kyoto et un bilan du sommet de Copenhague, par le collectif nantais Urgence Climatique, Justice Sociale.

Acte 1 : Kyoto (1997)

• Le protocole onusien de Kyoto, signé en pleine période de capitalisme financier triomphant, a confié l'avenir climatique de notre planète à la mythique main invisible du marché
• Des quota d'émissions de GES sont fixés pour les pays industrialisés signataires
• Les grandes entreprises industrielles reçoivent gratuitement des droits d'émissions de gaz à effet de serre (GES) et les échangent sur un marché
• Seule l'Europe a mis en place ce genre de marché depuis 2005 : résultat, fin 2007 la tonne de CO2 valait 0.02 euros...
• Les « mécanismes de développement propre » (MDP) permettent aux entreprises de récupérer des crédits d'émission si elles investissent pour réduire leurs émissions dans les pays en voie de développement
• Comme ça coûte beaucoup moins cher et que les contrôles des réductions effectives de GES sont très mauvais dans les PVD, les entreprises européennes ont massivement utilisé les MDP (surtout en Chine) pour récupérer des crédits carbone et pouvoir continuer à polluer dans les pays développés, tout en respectant leurs engagements de Kyoto (même mécanisme que la « compensation carbone »)
• Le nouvel accord de Copenhague est dans la même logique de marché. Il est même envisagé d'inclure la forêt et les terres agricoles dans le marché du carbone, les livrant aux spéculateurs de tout poil qui commencent à créer des hedge funds et des subprimes sur le marché carbone mondial naissant
• Quel accord a donc été trouvé à Copenhague?

Acte 2 : Copenhague (2009)

Les négociations

• Même si de nombreux observateurs tiennent la Chine pour responsable de l'échec des négociations, N. Klein et G. Monbiot soulignent l'attitude catastrophique des USA, qui n'ont fait aucune proposition significative, alors que le reste du monde les attendait pour bouger.
• Les pays du Sud ont été les leaders des négociations, alors que l'Europe s'est complètement effacée.
• L'un des seuls points positifs du sommet a été la présence de dizaine de milliers de militants pacifiques, dont beaucoup de jeunes. Le Klimaforum a été un carrefour d'idée et de rencontres. La convergence des luttes sociales et environnementales s'est produite à Copenhague et, on l'espère, fructifiera...
• Le sommet a été gâché par l'organisation danoise, avec l'exclusion des ONG et des pays du sud des négociations la deuxième semaine, une police/milice pratiquant l'arrestation préventive à tout vat, des gymnases/dortoirs à moitié remplis et très loin du centre ville (mais des squats en plein air pleins)

L'"accord"

• Le texte est issu d'un processus anti-démocratique : sous l'impulsion des USA, il a été rédigé par le G20 et soumis ensuite à l'approbation de l'ONU et à la ratification des “parties” (pays) présents : ~ 120 sur 192 avaient signé le 20/12 (Chine et Inde pas très motivés...)
• Il n'y a eu aucun accord sur des objectifs globaux de réduction d'émissions de GES (seul est réaffirmé l'objectif de limiter l'augmentation de température à 2°C)
• Les pays (développés et en développement) doivent définir eux-mêmes leurs objectifs de réduction pour le 01/02/09 et les appliquer ensuite (système “pledge-and-control” : promesse et contrôle)
• Ce mode de fonctionnement (inspiré manifestement par les USA) est une régression par rapport à Kyoto (où des objectifs de réduction globaux (même faibles) avaient été décidés. Il ne garantit en aucune façon que les objectifs de réduction globaux seront suffisants.
• Le problème des contrôle des émissions s'est posé : le Nord voulait imposer au Sud des contrôles internationaux, ce qui a fait achopper les négociations avec la Chine. N. Klein parle d'une tactique délibérée des USA pour susciter une opposition de la Chine et lui faire endosser la responsabilité de l'échec des négociations.
• Importante défaite pour les européens et les pays les plus pauvres : mettre sur un pied d’égalité l’adaptation aux effets du changement climatique (par exemple aux baisses de productivité agricole) et l’adaptation aux mesures prises pour le limiter (par exemple aux pertes de revenus des pays pétroliers, beaucoup plus importants et faciles à chiffrer).
• Le Nord « fournira des moyens » pour l'adaptation

Le fond d'aide à l'adaptation aux conséquences du dérèglement climatique

• Le Nord s'engage à verser 10 milliards par an pour l'adaptation d'ici 2012 (« fast start »). Actuellement, les USA ont promis (royalement) 4 milliards et l'Europe 11 milliards : il en manque...
• Et ensuite 100 milliards/an à partir de 2020
• Pour info : 1) les besoins financiers pour l'adaptation sont évalués à 200 milliards/an, 2) le congrès US vient de voter 600 milliards de budget militaire pour 2010...
• Ce fond d'adaptation sera alimenté par des fonds publics (facilement traçables), privés (difficilement traçables et orientables) et « alternatifs » (la taxe Tobbin sauce Sarkozy... mais le fond doit être alimenté par le Nord : quid des flux financiers des grands centres financiers du Sud : Hong Kong...?)
• Ces fonds seront gérés par des « organes internationaux » : banque mondiale, fond mondial pour l'environnement et un nouveau « machin » : le 'Copenhagen Green Climate Fund'
• L'argent ira en priorité aux plus pauvres
• Les sommes débloquées devront s'ajouter à l'aide au développement « classique »
• Les sommes devront être « prédictibles » d'année en année et « adéquates »...

Les "mécanismes" de lutte contre le dérèglement climatique

• Le marché carbone est évoqué comme un « outil possible », sans plus de précisions
• L'extension du marché carbone à la forêt et aux terres agricoles (REDD+) est mentionné comme nécessaire, mais aucun accord n'a été conclu sur le contenu du REDD+
• Un mécanisme de transfert de technologie est prévu, mais rien de concret n'est dit sur son fonctionnement
• L'accord sera amendable après le prochain rapport du GIEC en 2015

Acte 3 : après Copenhague...

• Les prochaines négociations internationales sur le climat de l'ONU auront lieu à Bonn mi-2010, puis à Mexico pour la prochaine COP en novembre-décembre 2010
• Vu l'immobilisme criminel et le manque de vision des politiques au niveau international, il devient plus urgent que jamais d'oeuvrer au niveau local. Différents types d'action sont envisageables :

1. Action d'éducation populaire aux problématiques climatiques et pression sur les élus locaux par les collectifs Copenhague.
2. Camps climat comme vitrine des alternatives.
3. Plans énergie-climat citoyens nationaux ou régionaux ou locaux, pour proposer des alternatives réalistes et étayées aux politiques à la vue basse, manifestement en panne d'ambitions et d'idées (Negawatt, Virage Energie, Virage Energie-Climat, Villes en transition)