mercredi, octobre 31, 2007

Open Social de Google: la plate-forme / API expliquée par Marc Andreessen de Ning

OpenSocial de Google est déjà évoqué sur le site du New-York Times (et sur 105 autres sites via Google News au moment où j'écris) alors que l'annonce officielle par Google et ses partenaires n'aura lieu que demain à Mountain View.

C'est quoi Open Social? Une initiative pour transformer tous les réseaux sociaux en plateformes (systèmes d'exploitation) d'hébergement d'applications développées par des tiers. On ne sait pas encore si les 2 grands en termes de revenus, Facebook et MySpace, seront là: certainement pas au début car les leaders ne sont jamais les premiers à ouvrir le marché qu'ils dominent.

Mais, par contre la Google Orkut, LinkedIn, Hi5, Friendster, Salesforce.com, Oracle, iLike, Flixster, RockYou, Slide et Ning sont à bord du bateau.

C'est confirmé par Marc Andreessen, le père de Netscape dans sa jeunesse et maintenant le fondateur de Ning qui est à bord du bateau OpenSocial.

Quand il expliquait sa vision sur les 3 niveaux de plate-formes de l'Internet, M. Andreessen préparait le terrain à cette annonce sûrement.

En tant que partenaire "fondateur" d'OpenSocial, il peut apporter des informations concrètes à cette initiative:
  • il s'agira d'une API (i.e. interface de programmation) standard utilisable sur les plates-formes citées plus haut et toutes celles qui rejoindront l'initiative.
  • elle est basée à 100% sur Javascript (AJAX) et HTML: les éléments d'affichage résultants de ce code seront intégrés dans les pages de la plate-forme d'accueil. On utilise ici des standards plutôt que le FBML propriétaire de Facebook
  • cette API sera supportée par une approche plate-forme de niveau 2: le code livré par le développeur tournera sur l'infrustruture du réseau social (i.e. ses serveurs). Mon "célèbre" Linternux fait aujourd'hui un grand pas en avant!
  • elle permettra d'accéder aux infos de la plate-forme mais aussi d'aller vers l'extérieur des appels AJAX à des web services distants (via XHR - xmlhttprequest)
Cet API uniforme et standard reprend l'idée de Java: le célèbre "Write Once, Run Anywhere". Une application écrite pour Ning pourra ainsi aussi fonctionner sur Plaxo et Linkedin. Gros plus pour les développeurs qui auront ainsi l'opportunité de monétiser la même application avec de multiples audiences!

M. Andreessen annonce que des prototypes seront montrés dès ce soit mais que la "production" officielle sur Ning comme chez les autres demandera encore un peu de temps: celui de finir les tests.

En conclusion, l'ouverture de Facebook de Mai dernier qui était une brèche marquante en Mai lors de l'annonce par M. Zuckerberg fait maintenant (5 mois plus tard seulement...) pâle figure en apparaissant comme quelque chose d'affreusement propriétaire.

Les 15 milliards de valorisation Facebook, ils plongent de combien à votre avis avec ete annonce?
Je n'y croyais personnellement pas de toute façon (Microsoft est plus malin que celà...)

PS: je reviendrai en détails sur l'API quand elle aura été publiée.

Source: blog Media & Tech (par didier durand)

mardi, octobre 30, 2007

Publicité Internet: évolution historique du marché et répartition des budgets

Après les chiffres Skype et ceux de Youtube, je reprends encore ce graphique dans le rapport 2007 de Mary Meeker. Il détaille la publicité Internet ("online") sur le marché américain.

Les notes qui l'accompagnent sont intéressantes:
  • un marché publicitaire mondial estimé à 630 milliards de dollars pour 2007 (+4% sur un an)
  • la publicité en ligne aux USA estimée à 21 milliards pour 2007 (en croissance de 26% - sur un total mondial de 31 milliards selon ZenithOptimedia) qui représente 10% du gâteau publicitaire US total. Elle n'en représentait que 4% en 2002 et en représentera 17% en 2012.
Revenons au graphique, il est particulièrement instructif:
  • la courbe rouge de la croissance descend: le transfert des budgets vers Internet se poursuit pour rattraper le décalage audience / utilisation vs allocation publicitaire. Mais, on va arriver d'ici quelques années à une place "honnête" pour Internet dans le media mix des annonceurs (cf. prédiction 2012 ci-dessus)
  • le domaine du search engine marketing (SEM) / keyword marketing est celui qui tire ce marché vers le haut (cf la partie rouge des barres ci-dessus)
Pourquoi ? Parce que le SEM est très directement mesurable et parce que les mesures prouvent par des chiffres ce qu'il apporte. Le slide suivant de la même présentation de M. Meeker est 100% explicite:


Le SEM apporte 36% des nouveaux clients sur les sites de e-commerce, loin devant les autres moyens publicitaires en ligne.

Les annonceurs tracent ensuite ce que ces nouveaux visiteurs achètent et puisqu'ils achètent, l'annonceur continue à investir davantage sur le moteur de recherche.

De plus, le panier moyen d'achats permet de définir le prix maximum de l'enchère (le fameux CPC) pour que cette publicité reste rentable.

Une vraie économie de marché - au plus pur sens de la définition Wikipedia - se met en marche à travers la publicité SEM.

Elle aura clairement des répercussions à terme sur les formes publicitaires traditionnels qui devront à leur tour - d'une manière ou d'une autre ...- également devenir mesurables. (avec des chiffres objectifs...)

Source: blog Media & Tech (par didier durand)

lundi, octobre 29, 2007

Gmail: 70% de spam dans les mails entrants - Faible?

le "grand" blog Google publie aujourd'hui un graphique sur le pourcentage de mails entrants qui sont des spams avant filtrage (depuis 3 ans)Ce qui est intéressant, c'est que ce taux est faible. En effet,
Cela veut dire quoi ?
  • Que Gmail n'utilise pas (encore) la technologie Postini ?...
  • Qu'alors des spams passent les mailles du filet et que les utilisateurs ne les rapportent pas (cf courbe bleue ci-dessus)
  • ...Ou alors, plus improbablement, que les utilisateurs de Gmail ne sont pas cibles du spam. J'en doute!
Le spam est une plaie du web rendue possible par le faible coût du gaspillage sur Internet

Mais, bon, les outils actuels le traitent bien. Alors ce n'est finalement pas très grave...




Source: blog Media & Tech (par didier durand)

Skype: 10 millions d'utilisateurs en ligne

Skype du groupe Ebay, service de téléphonie gratuite via Internet, vient de passer le 27 Octobre une barre significative : celle des 10 millions d'utilisateurs simultanés en ligne.

Elle vient après:La progression n'est plus aussi fulgurante qu'en 2005 quand Mary Meeker décrivait Skype comme le service à la progression la plus rapide de l'histoire.

Tout le monde finit (inéluctablement) un jour ou l'autre par rentrer dans le rang...

D'ailleurs, à la récente conférence Web2, cette même Mary Meeker dans son traditionnel "Etat de l'Internet" annuel a publié un graphe fort instructif sur Skype: le nombre des utilisateurs croit toujours respectablement à maintenant plus de 220 millions mais le revenu par utilisateur annuel stagne à 1.6 dollars (cf. la courbe rouge)

[Sur le même slide, M. Meeker donne le volume global du marché télécoms mondial pour 2007: 1'500 milliards de dollars - en progression de 8 points sur 2006]

Ce modèle de revenus m'impressionne d'une certaine manière: vous connaissez beaucoup de sociétés télécoms qui vivent avec 1.6$ par an et par utilisateur et génèrent ainsi plus de 300 millions de dollars ?

2 caractéristiques émergent de ce modèle:
  • Self-service total: pour avoir une chance d'être rentable, un tel service doit pouvoir être piloté à 100% par l'utilisateur final. Avec un 1.6$.cela veut dire que si quelqu'un de chez Skype ouvre votre dossier, Skype perd ensuite de l'argent avec vous pour plusieurs années à cause du coût administratif (RH) généré! Cela rappelle furieusement le modèle AdSense / Adwords de Google: je n'ai jamais vu un commercial Google....
  • aggrégation: à nouveau "les petits ruisseaux qui font les grandes rivières" sont un modèle commercial qui ne peut être viable qu'à travers Internet où le coût de la transaction commerciale devient quasiment nul.
Note: ce modèle et la croissance ne semble malgré tout pas satisfaire le management d'Ebay puisqu'ils viennent de passer une dépréciation de 630 millions pour "éponger" la survaleur (en tout cas vue comme telle maintenant...) payée lors de l'acquisition de Skype.

Source: blog Media & Tech (par didier durand)

dimanche, octobre 28, 2007

[fun] La pendule (binaire) des geeks


En vente chez Thinkgeek: la pendule à affichage binaire
Le mode d'emploi est:

Si vous voulez sélectionner vos amis, les faire jaser ... ou passer pour un illuminé total! ;-)

Source: blog Media & Tech (par didier durand)

jeudi, octobre 25, 2007

deal Microsoft - Facebook: 15 milliards de valorisation ou un simple prêt ? (usurier ....)

Tout le monde (je ne citerai personne...) s'extasie aujourd'hui devant la valorisation obtenue par Facebook avec Microsoft: les 240 millions de dollars mis par Redmond pour 1.6 % de Facebook, cela fait effectivement tout juste 15 milliards pour les 100%.

Ces 15 milliards, c'est donc 100 fois le chiffre le chiffre d'affaires attendu pour 2007 (150 millions) et 500 fois le bénéfice prévu (30 millions). le PER de Google à 50 n'est donc qu'1 dixième du (pseudo-)sommet atteint par Facebook.

Chapeau, Mark Zuckerberg, le fondateur de 23 ans qui vau(drai)t ainsi 3 milliards: il possède 20%!

Eh bien, pour moi, tout ce qui précède est erroné et ceux qui interprètent ainsi ont tort! Croire que Microsoft est capable d'un telle "légèreté", c'est vraiment les mésestimer: on ne devient pas le géant qu'ils sont sans savoir calculer...

Ces 240 millions ont une contrepartie: Microsoft est le partenaire publicitaire exclusif de Facebook (USA et étranger) jusqu'à 2011. Une superbe rample de lancement pour MS-AdCenter!

Dans ces 4 ans, supposons que Facebook passe à 300 millions en 2008 puis ajoute ce même montant à son CA chaque année. C'est raisonnable vu la croissance prévue du marché publicitaire en ligne et le succès publicitaire de Facebook via ces 42 millions d'utilisateurs actuels et le + 250'000 fait chaque jour.

Ce sont donc 300 + 600 + 900 + 1200 = 3 milliards de dollars qui vont être réalisés par Facebook dans les 4 années du deal.

En prenant la commission officielle de Google (env. 20%) comme base de calcul pour Microsoft, la firme de Redmond va donc recevoir 600 millions en retour de ces 240 millions d'aujourd'hui!

Ce sont de purs intérêts financiers puisque ces 240 millions seront toujours dans Facebook en 2011 (et vaudront sûrement beaucoup plus à ce moment!....).

Plus de 200% d'intérêt, ce n'est pas un prêt usurier, cela ? Ou alors je ne m'y connais pas...

Bénéfice accessoire: avec ce modeste 1.6%, Microsoft va sûrement faire fuir Yahoo et Google en tant qu'investisseurs complémentaires dans Facebook. ... Ou comment bloquer la concurrence avec une mise minimum! Finalement, d'une pierre, deux coups.

Alors, bravo Facebook ou bravo Microsoft ? Pour moi, c'est clair....

Source: blog Media & Tech (par didier durand)

mercredi, octobre 24, 2007

Chiffres Youtube: 206 millions de visiteurs & 21 milliards de minutes en aout 2007

Comme chaque annnée, Mary Meeker a publié le rapport officiel annuel de la banque d'affaires Morgan Stanley sur l'état de l'Internet. La version 2007 est ici.

Une foule de chiffres très intéressants pour ceux qui, comme, moi cherchent en permanence des repères à jour.

Les premiers qui m'intéressent actuellement, ce sont les chiffres de Youtube:
Ci-dessous le graphe de l'évolution des 2 indicateurs ci-dessus


Pour ceux qui cherchent d'autres chiffres historiques sur youtube, mes précédents billets sur le sujet:
Bonnes lecture et analyse! (partagez svp vos conclusions...)


Source: blog Media & Tech (par didier durand)

Fondation Mozilla / Firefox: revenus 2006 et autres chiffres

La fondation Mozilla qui développe le navigateur Firefox (mais aussi Thunderbird moins en vogue pour des raisons déjà expliquées) n'est pas à but lucratif: son manifeste que j'avais traduit à l'époque l'exprime très clairement. Il s'agit de contribuer à l'amélioration de la société digitale dans laquelle nous vivons en offrant une alternative de haute qualité et multi-plates-formes aux solutions propriétaires à la MS IE.

Au vu de cette mission, la fondation Mozilla doit une bonne transparence à sa communauté. C'est que ce que fait Mitchell Baker, sa patronne, en publiant les revenus 2006 et en revenant sur d'autres chiffres:
  • 67 millions de dollars de revenus totaux (+26% sur 2005)
  • 61.5 millions de dollars en provenance des moteurs de recherche: l'immense majorité en provenance de Google qui est le moteur de recherche par défaut du navigateur. Pour vous en convaincre tapez par ex. "Paris" dans la ligne d'URL de Firefox, vous atterrissez alors sur une page de résultats de Google avec les boîtes publicitaires tellement lucratives en colonne de droite)
  • Les dépenses ne trouvent qu'à hauteur de 20 millions (salaires des développeurs permanents et coûts d'infrastructure). La fondation se trouve donc à la tête d'un compte bien garni: 74 millions en banque.
  • Ses coûts d'infrastructure vont croissant pour supporter un trafic phénoménal: à la fin de 2006, 600'000 téléchargements (nouveaux utilisateurs) et 25 millions de requêtes de demandes des éventuelles mises à jour (utilisateurs existants). Tout cela pour 2.1 téraoctets de volumes transmis chaque jour!
  • Plus de 1'000 développeurs ont contribué à la version 2 de firefox
  • la fondation subventionne des sujets connexes à ses travaux (pour 300'000 dollars en 2006) comme le projet Creative Commons. 16'000 personnes ont décrit des bugs dans le système de gestion du logiciel.
  • Le nombre d'utilisateurs actifs de Firefox est aux alentours de 120 millions (12-15% des internautes mondiaux)
Je suis un accro de Firefox et ne reviendrais en arrière (MS IE) pour rien au monde!

Donc, longue vie à la fondation Mozilla pour continuer à pousser encore très loin les innovations (comme le projet The Coop) qu'elle a supportées jusqu'à présent loin des contraintes de rentabilité habituelles.

C'est un vent frais qui doit continuer à souffler!

Source: blog Media & Tech (par didier durand)

mardi, octobre 23, 2007

Commentaire du jour [29] - Erratum sur les TAC Google

[Commentaire du jour sur Media & Tech: quoi et pourquoi - Les autres commentaires du jour]

Merci à Arnaud du blog Dauran qui m'a fait remarquer une imprécision dans mon billet sur les résultats de Google au 3ème trimestre 2007: elle concerne les TAC (Traffic Acquisition Costs) annoncés par Google.
La commission retenue par Google n'est donc pas de 16% comme écrit dans le premier jet mais de 22.8% (1- 1.12/1.45) donc plutôt même en légère augmentation par rapport à 2005.

[C'est rassurant de savoir que l'on est surveillé de près: moins de bêtises publiées. Continuez!]

Source: blog Media & Tech (par didier durand)

Google Books: 1 million de livres dans l'index et 27 partenaires

Lors de l'annonce des derniers résultats trimestriels de Google, son management a livré des infos sur les grands projets en cours.

Ainsi, Larry Page a annoncé que:
  • le nombre de livres maintenant numérisés (et donc indexés) par le projet Google Books a dépassé le million
  • 27 bibliothèques sont maintenant partenaires de l'opération.

Pour moi, l'impact (majeur) de ce projet est encore lointain (Google s'est donné 300 ans pour accomplir sa mission d'organiser l'information mondiale...) mais il est capital pour rendre l'Internet utile pas seulement pour notre présent et notre passé proche mais aussi pour notre passé plus lointain voire l'histoire de notre civilisation. Notre passé plus lointain reste encore majoritairement archivé dans les livres.

Il me paraît donc utile de "stocker ce jalon du million" dans Media & Tech pour pouvoir y revenir quand on verra l'impact de ce projet (et de celui de ses concurrents comme celui de Yahoo-Microsoft) sur nos méthodes de recherche historique.

Pour l'instant, ce projet reste toujours la source d'une immense controverse et de procès...
Sur le fond, c'est bon pour l'Homme. Gageons donc que la situation finira par s'assainir quand chacun aura trouvé sa place.

PS: pour vous éviter des commentaires enflammées: je me rappelle que ce projet servira aussi à créer de nouvelles surfaces publicitaires et donc de nouveaux revenus. ;-)

Source: blog Media & Tech (par didier durand)

vendredi, octobre 19, 2007

Google: chiffres du troisième trimestre 2007

Erratum:

Merci à Arnaud du blog Dauran qui m'a fait remarquer une imprécision dans mon billet sur les résultats de Google au 3ème trimestre 2007: elle concerne les TAC (Traffic Acquisition Costs) annoncés par Google.
La commission retenue par Google n'est donc pas de 16% comme écrit dans le premier jet mais de 22.8% (1- 1.12/1.45) donc plutôt même en légère augmentation par rapport à 2005.

[C'est rassurant de savoir que l'on est surveillé de près: moins de bêtises publiées. Continuez!]

Billet original:

Google ci , google ça, je sais que certains ont en font une overdose (... et donc me reproche parfois d'en parler trop). Mais, c'est un vrai phénomène: je me dois donc d'en parler.

Les chiffres du géant de Moutain View pour ce troisième trimestre 2007 annoncés hier (slides ici) le prouvent encore une fois ce développement extraordinairement rapide (... et financièrement très sain!):
  • Revenus: 4.23 milliards de dollars. +57% sur la même période de 2006
  • Bénéfice brut d'exploitation: 1.32 milliards de dollars. 31% des revenus (!)
  • Bénéfice net (GAAP): $1.07 milliards de dollars
  • Bénéfice par action: (EPS - "earnings per share"): 3.38 dollars
  • Revenus des sites Google: 2.73 milliards de dollars, 65% of total.
  • Revenus du réseau Adsense: (i.e la Longue Traîne publicitaires des sites tiers): 1.45 milliard, 34% du total. Le graphe ci-dessous montre que les sites propres Google croissent financièrement plus vite que les sites tiers

  • Sommes reversées aux éditeurs des sites Adsense ("Traffic Acquisition Costs"): $1.22 milliard, 29% des revenus. La commission prélevée par Google est donc de (1-1.22/1.45) = 16%. Elle a fortement baissée depuis les 21.5% de Janvier 2006! La concurrence de Microsoft Adcenter et Yahoo Panama?
  • Revenus non publicitaires: 41.9 millions. Les revenus sont donc toujours 99% publicitaires! (tendance stable depuis 2 ans)
  • Cash en banque: $13.1 milliards. (des dépenses massives d'acquisition possibles...)
  • Employés: 15,916 - + 2,130 dans les 3 derniers mois!.
Ce genre de chiffres est récurrent depuis l'IPO.

Donc, respect, Mr Google!

[Via InsideGoogle]

Source: blog Media & Tech (par didier durand)

mercredi, octobre 17, 2007

Google: faites ce que je dis, pas ce je fais !....

Ce qui a fait le succès de Google, c'est ça:



Eh bien, le site MeanGene a proposé (de manière un peu humorisitique....) à travers ces diapositives successives de modifier le design de la page d'accueil de Google pour respecter les règles "best practice" d'une structure de page conforme aux principes de SEO ("Search Engine Optimization") favorables au crawling des pages par ce même Google et consors, il arrive alors à ceci:


Donc, c'est bien "faites ce que je dis et pas ce que je fais" ;-)

Pour poursuivre, dans cette lignée sarcastiques, on voit que la page d'accueil de Yahoo ci-après est elle beaucoup plus "seo compliant" de part son interface graphique ;-)


Source: blog Media & Tech (par didier durand)

mardi, octobre 16, 2007

[Fun] Si vous êtes fier de votre célébrité virtuelle....

.... alors il vous faut avoir cette bague qui "publie" (vaniteusement ?.... elle s'appelle "Vanity Ring") le nombre de requêtes sur Google pour votre nom et prénom dans les dernières 24 heures.


Le chiffre est remis à jour quotidiennement par connexion (sans-fil ) via un PC à Internet
Personnellement, je ne crois pas à la validité du nombre: Google ne livre pas le nombre global de requêtes faites sur un mot-clef ou un groupe de mots. Où le designer va-t-il chercher ce nombre? Un "bricolage" sans valeur objective réelle?...

En plus, pour moi, cela ne fonctionnerait pas: mon célèbre homonyme Didier DURAND, chef du Cyrano Bistrot à Chicago me vole sûrement la vedette pour sa défense héroique du foie gras aux USA. Mais, comment savoir si c'est lui ou moi que l'on cherche avec "didier durand" sur Google? (Bon, c'est sûrement lui! Il prend le "top spot" sur "didier durand" dans google.com....)

En tout cas, je vous l'avais bien dit: l'identité virtuelle et la célébrité éthérée afférente (...) doivent se gérer! ;-)



Source: blog Media & Tech (par didier durand)

dimanche, octobre 14, 2007

Publicité en ligne: augmente toujours mais reste (trop) concentrée

Reuters annonce des chiffres intéressants sur la publicité Internet:
  • la dépense mondiale totale devrait être autour de 31 milliards de dollars en 2007 (voir aussi les chiffres Yahoo).
  • Cela représente, selon ZenithOptimedia, une croissance de 27% alors que le secteur des médias ne croitra cette année que de 3.7%!
  • la croissance prévue est de 21% pour 2008 puis 13% pour 2009 pour atteindre 43 milliards de dollars. ((voir aussi les chiffres Yahoo).
  • le marché Internet représentera alors près de 10% du marché mondial (estimé à 495 milliards de dollars) mais sera malgré tout derrière les grands médias comme jounaux et magazines.
Malgré cette forte croissance, le ratio entre dépenses Internet et utilisation Internet est très défavorable: pour une relation conforme à l'utilisation du média, des (dizaines de) milliards de dollars devraient encore basculer des médias traditionnels vers l'Internet dans le media mix concocté par les annonceurs.

L'autre point soulevé par cet article est l'incroyable concentration du marché:
  • pour la zone USA, les 50 premiers sites représentent 90% des investissements publicitaires selon les statistiques IAB.
  • Plus compact encore, les 10 premiers sites américains font 70% de leur marché.
Ce retard d'investissement publicitaire sur Internet et cette structure trop concentrée posent un vrai problème: Tout le monde veut se financer par la publicité dans l'ère du Saas. Mais cela n'en prend pas le chemin: les grands comme Google (hégémonie américaine mais aussi européenne) ou MySpace et Facebook prennent tout le "gâteau" ou presque. Peu de chances pour tous les autres de pouvoir (sur)vivre seulement via la publicité.

Et je ne parle même pas du prochain retournement économique qui va nécessairement augmenter cette concentration des dépenses à cause des réductions de budget qui s'ensuivront....

Source: blog Media & Tech (par didier durand)

jeudi, octobre 11, 2007

Projet NACA[2]: transcodage automatique vers Java de 4 millions de lignes Cobol

UPDATE 01-2012: Le projet NACA a donné naissance à Eranea, société dédiée à la migration 100% automatisée de grandes applications métier vers Java et Linux. Voir  www.eranea.com ou email à contact@eranea.com pour plus d'informations
_______________________________________________________________________

Mise à jour: le code source des outils du transcodage NACA est maintenant en Open Source. Voir http://media-tech.blogspot.com/2008/07/les-outils-du-projet-naca-de-publicitas.html.
[Introduction: cet article fait partie d'une série qui décrit le projet NACA ayant conduit au remplacement d'un mainframe IBM sous MVS/OS390 par des serveurs Intel sous Linux. Le projet a été lancé en Janvier 2003 et s'est terminé avec succès au 30 Juin 2007.

Il a été réalisé volontairement de manière 100% iso-fonctionnelle (i.e. sans aucune modification pendant et par le transcodage) pour l'application et a engendré la conversion automatisée de 4 millions de lignes de Cobol vers leur équivalent Java. L'économie en cash-outs - paiements externes - est de plus de 85% de leur montant annuel = initial d'environ 3 millions d'euros annuels

Articles déjà parus:
]


L'enjeu majeur du projet NACA était sans aucun doute le transcodage de l'applicatif "maison" de PubliGroupe appelée PUB 2000 (4 millions de lignes de Cobol - applications transactionnelles sous CICS + programmes batches - base de données relationnelles DB2 + procédures stockées sous DB2 en Cobol -750'000 transactions/jour).

Pour les développeurs qui veulent juger par la structure, la palette d'outils développés pour le projet et décrits dans la suite représente:

  • transcodeur lui-même (NacaTRANS) : 83'000 lignes de code source Java; 688 classes.
  • environnement d'exécution (NacaRT) des programmes transcodés: 153'000 lignes; 890 classes.
  • outils de test automatiques (NacaTools): 16000 lignes; 128 classes.
A cela, il faut ajouter les codes sources suivants: Java lui-même, Apache Tomcat, l'IDE Eclipse, Berkeley Db java Edition, quelques composants l'immense librairie Apache Commons, Apache Xerces comme parser XML, Apache XSLTC, quelques petits composants de Apache Struts , Apache Log4J , Apache Ant, CVS

Pourquoi transcodage = enjeu majeur ? Parce que finalement quand on passe d'un système à l'autre, on retrouve en général les mêmes composants (couches de télécommunications, système de contrôle de la machine, gestionnaire de sécurité, moniteur transactionnel, séquenceur des travaux batches, etc…) : les nouveaux composants sont sur base de technologies modernes avec des concepts plus récents et efficaces mais à la fin on finit toujours par imprimer, sauvegarder et gérer le système de manière similaire à la génération précédente.
Ce ne donc pas les composants systèmes ni les ingénieurs qui les pilotent, habitués à ces générations successives de système, qui posent problème. Le point d'achoppement d'une migration technologique, c'est toujours l'applicatif. Quand il est fait "maison", il faut toujours l'adapter de manière importante. Et comme ce chef d'œuvre (en tout cas, vu comme tel…) a naturellement la vertu d'être unique, tous les coûts de migration d'un système à l'autre sont exclusivement à la charge de l'entreprise propriétaire.
Comme expliqué dans l'épisode [1], la pierre angulaire du projet NACA, c'est le Logiciel Libre (OSS- "Open Source Software") avec Linux comme fondation de l'édifice. Nous ne voulions pas déroger à ce principe pour l'applicatif. Aussi, un choix comme le Cobol Microfocus (qui fonctionne sous Linux) aurait peut-être permis un chemin peut-être plus facile a été abandonné car il n'est pas Open Source. Il est de plus (fort) coûteux et ne nous pas aurait permis de restructurer / instrumenter notre application comme la couche objet (Java) que nous intercalée nous a permis le faire [J'y reviens plus bas]
Des premiers essais en quelques semaines par un prototype interne nous ont montré que le transcodage automatisé de Cobol à Java était "jouable". Sur le bon principe "Buy before Make", nous avons donc passé un appel d'offres à plus de 20 sociétés (quel que soit leur pays d'origine) susceptibles de répondre: beaucoup de sociétés en liens offshore avec l'Inde mais personne capable de faire un transcodage 100% automatique.
Doté d'un groupe de développeurs-experts, PubliGroupe à pu se permettre de poursuivre en interne la voie du transcodeur (i.e une sorte de compilateur Cobol vers Java) développé "maison" parce que le transcodage 100% automatique était un must dans la stratégie NACA développée dans le premier billet.
Les objectifs que nous nous sommes fixés pour ce transcodage:
  • fonctionnement 100% automatique: le transcodeur reçoit les fichiers source de l'application Cobol: programmes, définitions des zones de données (les fameuses COPY CLAUSE de Cobol), les ordres SQL (souvent séparées en fichiers INCLUDE isolés), les définitions d'écrans (BMS Maps pour un mainframe IBM) et génère à partir de tout cela une application Java structurée en servlets Tomcat accédant à la base de données relationnelles via JDBC et assurant le dialogue vers les écrans par une interface http/HTML native.
  • lisibilité du nouveau code source Java: certains des répondants à notre appel d'offres généraient du Java mais ce Java avait l'aspect d'un langage machine (… une sorte d'assembleur pour ceux qui connaissent encore ce langage…). Ce Java était certes opérationnel et sans faute mais absolument illisible et non maintenable pour un être humain. L'objectif de notre transcodeur (tenu par la suite…) de générer un Java totalement lisible par un programmeur standard. La motivation en est très simple: à la sortie du transcodage, nous voulions un code pouvant vivre encore 10 ans au moins. Une nouvelle génération de PUB 2000 "from scratch" est maintenant mise en chantier mais on connaît la durée de ce genre de chantier !... Il faut donc que le programmeur qui connaissait la version Cobol ne soit pas noyé dans la nouvelle mouture transcodée. Sinon gare aux coûts de maintenance…
  • maintenabilité du nouveau code source Java: encore une fois, il s'agit de pouvoir poursuivre l'évolution fonctionnelle de l'application transcodée. Nous avons donc pris l'option de générer des servlets Java copiant le plus fidèlement possible le Cobol initial. Le Java généré n'est ensuite pas dans le plus pur style orienté objet mais si vous êtes prêts (nous l'étions à 100%) à des concessions dans la pureté théorique du code généré, le résultat obtenu est un programme Java calqué quasiment ligne pour ligne sur le programme Cobol originel. Un vrai bonheur pour les programmeurs applicatifs qui à la fois connaissait parfaitement leur "poésie" Cobol et ne sentent pas encore tout à fait à l'aise avec les dernières subtilités OO de Java.
  • homogénéité du code produit: comme personne ne met ces "petites mimines délicates" dans le code Java nouveau, ce dernier est incroyablement homogène car le code est généré à partir de l'analyse syntaxique du Cobol selon un algorithme toujours le même. On efface donc les touches personnelles de poésie d'un code maintenu pendant longtemps par des personnes différentes.
  • nettoyage du code: le Cobol est structurellement simple. Il est donc possible de détecter puis de retirer certaines zones de code mort. Nous en avons encore sûrement laissé derrière nous, mais pas mal ont quand même été purgées.
  • iso-fonctionnalité du code: c'est une conséquence naturelle du transcodage automatique. Mais, elle est importante: en ne travaillant jamais à la main, on n'introduit pas d'erreurs et on ne met pas en danger le projet par "l'ajout en passant de ces quelques petites fonctions que tout le monde attend depuis longtemps" qui finissent par s'avérer fatales car , par leurs bugs, elles troublent tout le planning du projet.
  • découpage du code transcodé en 2 niveaux: nous avons découpé notre code généré en 2 couches: (a) la partie visible: un objet par verbe Cobol et un objet par variable du programme. Ces objets s'utilisent mutuellement pour exécuter le programme. Dans cette partie du code se trouve la correspondance ligne à ligne entre Cobol et Java. Ce sont donc ces 4 millions de lignes Java que les programmeurs applicatif maintiennent désormais chez nous (b) une bibliothèque d'exécution ("runtime"), appelée NacaRT - développée spécifiquement pour émuler Cobol et son environnement d'exécution CICS ou batch ). Cette bibliothèque est elle très (très) fortement orientée objet. Elle est le pilier d'appui des objets verbes et variables du (a). L'intérêt de cette architecture est multiple: (1) on préserve visuellement l'ordre et la structure du programme Cobol initial (2) la très forte orientation objet avec une hiérarchie d'héritage très profonde permet de faire évoluer de manière fondamentale le comportement du programme (performances, répartition de charge, etc…) par modification de l'implémentation des objets sous-jacents de la hiérarchie. Une hiérarchie profonde permet ensuite de circonscrire ces modifications de comportement à des zones plus ou moins vastes de l'application en fonction de l'endroit où l'on place la modification
Les conséquences d'un tel choix d'architecture de transcodage:
  • transcodage répétable autant que nécessaire: le processus est 100% automatique. L'absence d'intervention manuelle permet de refaire l'opération autant que nécessaire à coût nul ou presque.
  • stratégie de test devient encore plus critique: puisque l'on peut transcoder sans effort, on a envie de le faire souvent (voir les 2 points ci-dessous). Par contre, il faut alors pouvoir tester facilement le résultat effectif du transcodage. On arrive donc très vite à la conclusion qu'un outil de test automatique va de pair: nous avons donc développé cet outil de test (NacaTools) autant pour le batch que le transactionnel. Il s'agit de comparer une base de données résultant d'une batterie de transactions-tests en Java sur une base de départ connue à une copie de la même base de données résultant de la même série de transactions-tests faites depuis les transactions CICS. En plus bien sûr, on compare chaque champ de chaque écran de chaque transaction-test afin de vérifier que les 2 extrémités de l'application (les données permanentes et l'interface utilisateur) sont bien identiques. Nous avons ainsi développé plusieurs centaines de tests de nos applications que nous avons repassé des dizaines de fois pendant la mise au point du transcodeur et du runtime. L'objectif était de ne déranger les utilisateurs qu'une seule fois et pas chaque semaine pour tester les bugs corrigés durant la semaine (….et vivre de pleins fouets les nouveaux): ils sont venus pour nous constituer la batterie de tests. Et ensuite, on les a revus que lors des tests finaux. Même si la migration est terminée, vous vous doutez sûrement que nous continuons à utiliser cette batterie de test comme outil d'assurance-qualité de la maintenance applicative faite maintenant manuellement par nos développeurs sur le nouveau-code Java.
  • continuité de l'évolution fonctionnelle applicative: le transcodage et les tests afférents étant sans douleur, on peut continuer à faire évoluer son application en Cobol pendant toute la période de bascule. En effet, on intègre les nouvelles fonctions en Cobol, on transcode et on teste automatiquement. Et hop, la nouvelle fonction fonctionne aussi en Java. Une telle migration entre le 100% des utilisateurs sur Cobol - 0% sur Java vers 0% sur Cobol - 100% sur Java dure forcément plusieurs mois, Il est impensable d'interrompre la maintenance fonctionnelle sur une telle durée.
  • possibilité de migration progressive: come nous disposons d'après ce qui précède d'un moyen d'avoir une application identique dans le monde mainframe/COBOL et dans le monde Linux/Java sans peine ni coûts excessifs: nous avons pu prendre le temps de passer nos utilisateurs de l'ancien environnement au nouveau par "petits paquets" au début puis par paquets plus gros au fur et à mesure de la confiance croissante. Cela s'est ainsi fait sans douleur ni retour arrière. Encore aujourd'hui, je recommanderais exactement la même approche à tout projet de migration similaire. Cette souplesse de migration est le bon (meilleur ?) moyen de ne pas trop faire monter la pression. Dans une migration "big bang", on ne dispose que de quelques heures pour réagir quand un problème important survient sinon c'est retour arrière et le nombre des allers-retours est en général limité avant que le projet ne s'arrête définitivement… Dans une migration douce où les 2 applis cohabitent aussi longtemps que nécessaire, une telle pression n'existe jamais: on voit les goulets de performances arriver en ajoutant les paquets d'utilisateurs et en voyant leur impact. Quand le "mur" approche, on met la bascule en pause, on révise l'implémentation des objets du runtime qui posent souci et puis on repart. Pas de stress inutile!
  • possibilité de cohabitation de versions Cobol & Java à long terme: ce point ne nous concerne pas directement. Mais la stratégie NACA est intéressante pour un éditeur de logiciel qui aurait à faire cohabiter 2 versions de son application pendant la durée de migration d'un portefeuille de licences placées chez des clients: la méthode migration douce rend une mutation technologique quasiment transparente (… et très économique) car il dispose en permanence d'une application identique dans "l'ancien et le nouveau monde".
  • extension transparente des fonctionnalités de l'application originelle: la logique business est préservée lors du transcodage par la couche supérieure clonant le Cobol (cf plus haut). Ensuite, l'extension des objets de la bibliothèque d'exécution permet d'ajouter des fonctions supplémentaires à forte valeur ajoutée avec un minimum d'effort. Pour donner quelques exemples (déjà réalisées dans NACA ou dans nos plans d'améliorations complémentaires):
    • techniques: par ex: introduction de messages de logging partout où nécessaire, profiling de l'application, instrumentation automatique de l'application pour récupérer des données plus fine sur son utilisation, etc…
    • fonctionnelles: par ex
      • lien "live" (par RPC) avec d'autres applications pour leur transmettre des en temps des données nouvelle / modifiées au sein de l'application commerciale
      • génération automatisée d'hyperliens vers d'autres applications en fonction de la donnée affichée (ex.: l'affichage d'un code client est agrémenté d'un hyperlien vers le système de CRM externe ou vers une autre transaction de la même application utilisant le code client en entrée
Afin de ne pas faire trop long, je réserverai les détails d'architecture technique du système de transcodage à un prochain billet de la série promise sur le projet NACA.
J'espère par ce qui précède vous avoir convaincu de l'intérêt d'une migration progressive combinée à (… ou permise par) un transcodage automatique. En synthèse, on pourrait dire que c'est sûrement un peu plus long et coûteux qu'une migration "big bang" parfaitement menée. Mais, encore faut-il que le "parfaitement menée" soit une réalité sinon, pour le projet, c'est la trappe quasi-assurée! Et chacun sait que la perfection n'est pas de ce monde….
Note (cf début d'article) pour les (très) férus de détails technologiques: en plus de nos propres packages, nous avons fait appel aux composants Open Source suivants:
  • Java lui-même qui est maintenant un vrai Open Source alors qu'il ne l'était pas au début du projet NACA
  • Apache Tomcat comme conteneur des servlets représentant les clones des transactions CICS originelles. JBoss a été envisagé au début. Mais, n'ayant pas trouvé de réelle utilité à la lourde mécanique des EJBs ("Enterprise Java Beans") et ayant discuté avec d'autres les ayant mal vécus (performances et complexité, nous avons décidé de rester avec le très efficace (et incroyablement stable...) Tomcat jusqu'à ce qu'il ne suffise plus. Et, il a suffi jusqu'au bout ;-)
  • l'IDE Eclipse avec divers plug-ins dont un spécifique développé "maison" sur lequel je reviendrai ultérieurement
  • Berkeley Db java Edition pour ses fonctions de tris massifs dans les batches. C'est un moteur complet de fichiers ISAM sequentiels indexés mais nous n'avons pris que le tri car toutes nos données sont 100% relationnelles. Il a par ailleurs fallu l'enrichir pour supporter le très propriétaire format EBCDIC d'IBM.
  • quelques composants de l'immense librairie Apache Commons pour l'implémentation de certaines structures de données et fonctions très standards à toute application
  • Apache Xerces comme parser XML dans le transcodeur lui-même et dans NacaRT pour le passage des XMLs générés par l'application à l'HTML envoyé par le navigateur
  • Apache XSLTC comme compilateur XSLT pour les transformations successives des XMLs utilisés à l'éxécution: enrichissements /modifications successifs du XML initial pour arrriver à du HTML finalement envoyé au navigateur
  • quelques petits composants de Apache Struts pour une meilleure gestion des URLs, des servlets et de leur correspondance
  • Apache Log4J pour assurer la journalisation (logging) de tous les messages émis par le transcodeur, l'application initiale et par les objets "instrumentés" de la biblliothèque NacaRT
  • Apache Ant comme outil de transcodage / compilation / contruction de l'ensemble de l'application ( NacaTrans, NacaRT, Nacatools + 4 millions de lignes de source Java de l'application transcodée. En fait, nous avons utilisé AntHill un dérivé commercial de Ant qui ne nous a pas donné entière satisfaction durant le projet: aujourd'hui, on prendrait Ant natif ou carrément autre chose dans le même domaine de la construction d'applications.
  • CVS pour la gestion de tous ces sources. Aujourd'hui, ce serait vraisemblablement Subversion (SVN) qui était encore très / trop jeune quand nous avons commencé.
PS (pour ceux arrivés jusqu'à là dans la lecture...): tout n'est pas aussi idyllique que cela pourrait en avoir l'air. J'ai demandé à nos développeurs / experts de faire un inventaire des "points durs" du transcodage. Ils feront l'objet d'un prochain billet.

mercredi, octobre 10, 2007

Linternux: vers une entrée dans les entreprises? (SLA pour Amazon S3)

Amazon vient d'annoncer un contrat de service forme (SLA - Service Level Agreement) pour son service S3 de stockage de données en ligne. L'engagement est plus qu'honnête: l'objectif est 99.9% avec 25% de réduction de la facture si la barre des 99% est franchie vers le bas.

Au-delà des chiffres et des remboursements, ce pas d'Amazon ouvre pour moi le monde de l'entreprise aux technologies de type SaaS ("Software as a Service") car un service comme S3 (ou son concurrent chez Microsoft) n'ont aucune chance d'entrer dans l'entreprise tant que le fournisseur ne se mouille pas de manière formelle à travers un tel SLA. Un volume élevé d'activité (comme les 5 milliards d'objets en gestion sur S3) n'est pas un argument pour un service achats digne de ce nom: il faut un vrai contrat!

Maintenant, c'est fait! Le concept Linternux peut penser à faire son entrée dans le monde "corporate".

PS: il semble que ce soit sous la pression de concurrents tout neufs comme Nirvanix qui mettent en avant contre S3 le SLA de leur propre service qu'Amazon ait dû à son tour "montrer" patte blanche. La concurrence a décidémment toujours du bon...

Source: blog Media & Tech (par didier durand)

[Fun] AJAX: une application pour la classification périodique des éléments

Quand on a pas mal baigné dans les études scientifiques et que l'on croise une belle application des sciences sur Internet, on a toujours envie d'en parler. C'est que je vais faire!

Voici donc une très belle mise en oeuvre des technologies AJAX par Micheal Dayah avec ce superbe mashup qui fait abondamment appel à la très volumineuse Wikipedia (qui va encore ainsi gagner un peu de trafic....). Si vous voulez retrouver vos cours de chimie d'antan, c'est par ici pour "jouer" avec ce superbe tableau périodique des éléments très interactif

Il doit être content là-haut, le professeur Mendeleiev, père de cette classification!

Source: blog Media & Tech (par didier durand)

mardi, octobre 09, 2007

Facebook: les applications tierces ne sont PAS une longue Traîne

Conclusion de mon dernier billet sur la "Longue Traîne des applications Facebook" finalement apportée par C. Anderson aujourd'hui: la distribution des applications tierces sur Facebook ne suit finalement PAS la forme "officielle" de la Longue Traîne (i.e une loi de puissance)

Pour preuve, le diagramme finalement calculé par les équipes de T. Oreilly montre que, sur des axes logarithmiques, le rang de l'application et l'activité ne sont pas en (bon) lien linéaire du genre log(y) = a*log(x) + b.Affaire bouclée.

Je réitère ma conclusion d'hier: finalement, tout ce qui décroît visuellement rapidement n'est pas Longue Traîne. Je me me tiendrai pour dit! Vous aussi?

Source: blog Media & Tech (par didier durand)

lundi, octobre 08, 2007

Plate-forme Facebook et ses applications: La Longue Traîne (loi de puissance) s'applique-t-elle aussi ?

Un article intéressant de Tim O'Reilly (toujours dans mon Top5 des blogs indispensables) sur la répartition du succès des applications tierces sur Facebook en tant que plate-forme applicative (Rappel: Facebook est la seule plate-forme du web 2.0 de niveau 2 qui soit significative actuellement)
T. OReilly dit (un peu vite ?) que c'est une Longue Traîne standard en publiant le graphe du succès de ces applications

Et là, surgit Chris Anderson en tant que gardien du temple des lois de puissance pour remettre la théorie d'équerre:
  • la courbe a décroissance très rapide montrée par O'Reilly n'est pas forcément une longue traîne (i.e. loi de puissance). Les lois lognormales, à décroissance exponentielle ont cette même forme de décroissance rapide. Tout ce qui décroît vite n'est pas Longue Traîne...
  • En effet, les chiffres donnés par O'Reilly sont plutôt anti-Longue Traîne: tout est trop concentré vers la gauche (i.e. la tête de la traîne). L'intérêt de la Longue Traîne est justement une bonne distribution de la demande vers la droite de la traîne (i.e. les niches d'intérêt). C. Anderson donne un exemple avec la loi de puissance la plus simple 1/x: sur un échantillon de 5'000 applications, les 84 premières devraient représenter seulement 55% et pas 87% pour les applications tierces sur Facebook aient un succès en Longue Traîne!
Pour Anderson, une telle distribution de la demande trop massivement concentrée est justement le signe d'un marché immature où règne la "tyrannie de l'effet réseau" (sans contrepoids par moteur de recherche efficace par exemple): " The social networking on Facebook is too powerful. This is the tyranny of network effects, where viral success is the only kind and popularity snowballs into an avalanche or goes nowhere at all. That sort of herd behavior is usually a sign of an immature market." [Pour enfoncer le clou sur cette sur-concentration , il ajoute perfidement que la quasi-totalité des applis tierces Facebook sont sans intérêt: ce que mes premières explorations personnelles sur Facebook tendraient aussi à me faire croire...]

C. Andersson a demandé les données à T. Oreilly pour caractériser la distribution de la demande (pour les fans de maths, elle sera Longue Traîne si activité = k*log(rang) + constante avec k< style="font-style: italic;">
Lecon à retenir: il n'est pas forcément judicieux de mettre le mot "Longue Traîne" à toutes les sauces. Une courbe à décroissance (trop) rapide peut finalement être le exactement le contraire: cf ce qui précède. Tiens, il faut que je relise cet ancien billet sur La Longue Traîne des blogs! J'essaierai d'y faire désormais attention...

Source: blog Media & Tech (par didier durand)

samedi, octobre 06, 2007

Commentaire du jour [28] - Nokia contre Google via Navteq: bagarre ou pas?

[Commentaire du jour sur Media & Tech: quoi et pourquoi - Les autres commentaires du jour]

En parlant du rachat de Navteq (fournisseur de Google Maps) par Nokia (et de sa nouvelle mue), je pariais pour des frictions prochaines entre la socité finlandaise et celle de Mountain View.

David et Renaud ont 2 avis différents du mien qui valent la peine d'être lus:

David (pas de lien fourni par l'auteur - désolé!) a écrit: "Il ne reste plus qu'à attendre la réaction. Il y a fort à parier que Google mènera une négociation avec Nokia, mais aussi se préparera une porte de sortie. L'entreprise la plus abordable restant pour l'instant TomTom.

Les coccinelles permettent pour l'instant uniquement d'ajouter une "couche 360 degrés" aux cartes NavTeq. La véritable valeur de Navteq pour Google est le fond cartographique, mais seulement pour les marchés de l'Amérique du Nord et du Sud. L'Europe pour sa part est fournie à Google par Tele-Atlas.

Tele-Atlas et Navteq resteront donc pour moi en concurrence auprès de Google, mais ... que deviendra dans un proche avenir la petite société montante Lead Dog, elle aussi fournisseru de cartes auprès de Google : http://www.goleaddog.com/e/france.html

Google n'a pas toujours racheté le leader du marché (FeedBurner, YouTube), mais parfois la petite pousse flexible. Je pencherai donc pour le rachat assez rapide d'une "petite pousse de la cartographie", juste pour faire monter un peu la pression auprès de NavTeq et Tele-Atlas.

Précision utilse : je ne travaille pas (pour le moment) chez Google ;)"

Renaud lui a écrit: "Je pense que ca ne va rien changer... TeleAtlas et Navteq sont les 2 fournisseurs majeurs de carto au monde... et ils comptent bien le rester. Leur position dominante restera sur les pays "majeurs". Se faire racheter va permettre à TA et Navteq d'avoir un peu de cash et de respirer un peu... car ca coûte très cher de produire de la donnée carto.

Je ne pense pas que ce soit stratégique pour Google d'avoir sous son aile un fournisseur de données carto majeur. Au contraire, son fort trafic et sa notoriété lui permet de plus facilement négocier les prix avec ces fournisseurs. Et dans GMaps il n'y a pas que des cartes, il y a aussi des vues aériennes et satellites qui à côté doivent vraiment coûté très cher... Je pense que c'est la clé pour Google s'il a investir, c'est bien à ce niveau.
Effectivement acquerir un acteur plus "modeste" est une solution aussi pour avoir des pays non couvert par TA et Navteq, comme il l'a fait avec Endoxon en décembre 2006."


Source: blog Media & Tech (par didier durand)

vendredi, octobre 05, 2007

Deals FON avec BT et Neuf Cegetel: finalement bon pour qui?

Le Deal FON + British Telecom en Angleterre et FON + Neuf Cégétel en France ont été abondamment annoncés dans la presse.

Eh bien, je vais jouer mon Nick Carr et dire que je ne comprends pas l'intérêt commercial / industriel pour FON d'une telle démarche et j'attends vos contre-arguments de pied ferme... Aidez-moi svp à comprendre!

FON est donc une startup qui déploie un réseau wifi P2P mondial essentiellement gratuit avec 3 types d'utilisateurs (cf ce 1er billet):
  • les Linus qui offrent leur point d'accès Wifi à la communauté en échange de la réciprocité: ils ont une utilisation gratuite illimitée des autres points d'accès de la communauté.
  • les Aliens étrangers à la communauté qui paient leur accès aux points wifi de la communauté FON
  • Les Bill qui monétisent leurs points d'accès via les Aliens ci-dessus en partageant avec Fon.
Donc, en résumé. la source de revenus ce sont les Aliens dont FON partage les revenus avec les Bill. Les Linus sont là pour offrir la couverture maximale au service et créer des points de monétisation supplémentaire à FON. Ils reçoivent un service étendu en échange.

Dans un deal comme ceux évoqués ci-dessus (si j'ai bien tout compris...), les abonnés ADSL de Neuf ou BT deviennent des Linus. Résultat:
  • moins d'Aliens potentiels pour FON donc moins de revenus potentiels
  • une valeur ajoutée supplémentaire très intéressante offerte gratuitement aux abonnés de BT (3 millions!) et Neuf (600'000): des centaines de milliers (milions) de lieux supplémentaires depuis où connecter leur PC / Ipod Touch ou autre en wifi. L'opérateur télécom ne perd pas un centime puisqu'il continue à encaisser l'abonnement ADSL. En plus, pour un challenger comme Neuf Cegetel, il marque un point face au dominant, Orange en l'occurrence.
Donc, gain pour l'opérateur et perte pour FON.

Je n'ai rien compris ? Merci de vos explications sur "comment FON retombe sur ses pieds". Techcrunch par d'autres chemins arrive à la même conclusion. De même Om Malik sur Gigaom ne comprend pas tout.

Cette problématique de "monétiser le gratuit" (tiens un oxymore ou je n'y connais pas!...) sans revenus publicitaires majeurs est le même problème que vient de vivre Ebay avec Skype. Rachat à prix élevé d'une compagnie qui croît vite, très vite dans son utilisation (gratuite) mais qui ne peut pas transformer cela en revenus significatifs (par rapport au prix d'achat). Conséquence: Ebay jette l'éponge en passant 1.43 milliards de dollars de surévaluation de l'achat par pertes et profits. [Snif... j'aimais l'histoire Skype / Ebay jusqu'à présent!]

C'est quoi la bonne solution dans le "gratuit monétisé"?

PS: le seul intérêt que je vois pour FON, c'est l'investissement de BT dans FON. Infusion de cash ou premiers payouts pour les investisseurs FON. Commercialement, je cherche encore...

Source: blog Media & Tech (par didier durand)

jeudi, octobre 04, 2007

Youtube: la prestigieuse UC Berkeley met 300 heures de cours en ligne

La prestigieuse université de Berkeley a annoncé hier qu'elle allait mettre 300 heures de cours données en son sein sur Youtube. Elle annonce que c'est une première (mondiale)

Pour ce faire, comme Tony Blair ou la Communauté Européenne, elle a créé sa chaîne propre sur Youtube.
Les 300 heures n'y sont pas encore mais le programme annoncé (qui se trouve ici) est vaste: biologie, chimie, ingénierie, sciences sociales et même moteurs de recherches (avec des orateurs prestigieux) . Il y a déjà 201 vidéos chargées au moment où j'écris.

D'ailleurs, en bonne place trône celle de Sergei Brin (lui-même étudiant de Stanford - PhD jamais terminé..) , le fondateur de Google, quand il était venu parler de Google à Berkeley [je vais la regarder].



J'ai rapporté une fois que l'Internet favorisait les contenus courts. Je pourrais bien avoir à ravaler mon chapeau sur le sujet si le de tels programmes ont du succès....Malgré tout, pour profiter de genre d'émissions, je pense qu'il vaut mieux avoir un dispositif à la "Apple TV" pour regarder ces vidéos Internet sur le grand écran de la TV de son salon. Et, puis, ce sera aussi tellement plus confortable quand Youtube mettra à disposition par seulement la version Flash destinée aux écrans PC mais la version haute définition (qu'il est toujours en train de préparer). La télévision culturelle et éducative 2.0 sera alors née... [Note: le démarrage public de Joost, axée sur la haute définition, va peut-être booster Youtube pour offrir une version HD de son catalogue]

J'espère que cette initiative donnera des idées à nos propres universités (Sorbonne, etc...) et grandes écoles (HEC, X, etc...) à moins que l'idée de devenir (partiellement) gratuites et transparentes ne les paralyse. Si vous avez des pointeurs d'initiatives francophones déjà en cours, je prends. Merci d'avance!

Vos avis enflammés sur la désacralisation de l'enseignement par cette mixture de contenus "nobles" avec les contenus plus "funs" beaucoup plus habituels sur Youtube sont également bienvenus!

Source: blog Media & Tech (par didier durand)

mercredi, octobre 03, 2007

Commentaire du jour [27] - Linux et le PAF: des progrès à faire!

[Commentaire du jour sur Media & Tech: quoi et pourquoi - Les autres commentaires du jour]

Le PAF c'est ici le "Paysage AudioVisuel Français". Désolé pour ceux à qui le titre suggérait d'autres choses! ;-)

Suite à mon billet sur le projet NACA, merci à un lecteur anonyme (donc, pas de lien) de son pointeur vers cette vidéo dans laquelle il semble que Linux soit encore un illustre inconnu sur le PAF. Le monde du Libre a des progrès à faire dans sa communication!




Le commentaire intégral de ce lecteur: "un peu hors sujet mais ca vaut le coup : vous avez vu la revanche de linux chez ruquier incroyable, ils voulaient jouer au plus malin avec Tonvoisin Debureau, l'auteur de travailler avec des cons (vu un post de lui, et ke le salut bien bas)
http://www.travailleravecdescons.com.
et qui seme le vent recolte la tempete ! la reponse de tonvoisin debureau une pepite concernant windows http://fr.youtube.com/watch?v=JMI-UxzSUec
linuxiens linuxiennes enjoy !!!

linux s'invite chez france 2 je ne sais pas qui est tonvoisin, mais les autres avaient pas vu le coup venir !"

PS:il y a l'air d'avoir quelques bonnes choses (pas tout...) au 2ème degré sur www.travailleravecdescons.com (que je viens de découvrir)

Source: blog Media & Tech (par didier durand)

mardi, octobre 02, 2007

Nouvelle mue de Nokia qui rachète Navteq? disette de données pour Google Maps....

Nokia annonce le rachat de Navteq pour 5.4 milliards d'euros. Navteq élabore les données cartographiques numériques pour bon nombre de services pour Internet.

En particulier pour Google Maps (cf. image ci-dessous) qui voit ainsi un autre de ses fournisseurs cartographiques importants prendre un peu plus de distance avec lui.

En effet, au mois de Juillet, c'était TeleAltlas qui était happée par Tomtom. Donc, 2 fournisseurs qui d'évaporent en tant que tel pour le géant de Mountain View.

Ce qui est intéressant dans ce rachat, c'est que Nokia est en train d'entamer une nouvelle mue. Elle est coutumière du fait: Nokia était initialement née de la fusion de trois industries remontant au XIXe siècle (papeterie, caoutchouc et câbles). Elle a ensuite basculé dans les années 70 vers l'électronique grand public (téléviseurs) dont elle s'est retirée quand le secteur est devenu trop compétitif pour faire une bascule totale vers les télécommunications avec le succès que l'on sait.

Maintenant, son CEO veut la faire basculer du monde du hardware vers celui du software pour se repositionner dans un monde où les marges sont plus juteuses.

Voilà qui promet des discussions âpres (et plus si non-affinités...) avec Google pour continuer à lui fournir les données de Google Maps. En effet, Nokia est actuellement grosso modo de la même taille financière à la Bourse que Google (147 milliards de dollars) mais plus grosse que lui en CA (41 milliards contre 10 milliards). Elle peut donc discuter pied à pied avec lui! Si elle veut prospérer sur ce terrain des services logiciels, ce sera sûrement au prix de quelques pieds écrasés chez les clients comme Google qu'elle vient de récupérer via Navteq...

A suivre donc pour le chahut qui s'annonce !

PS 1 (sérieux): pourquoi toute cette agitation autour des données (cartographiques) ? Parce que c'est clairement le "Intel Inside" du web 2.0 .

PS 2 (humorisitique): les coccinelles espionnes de Google, c'est pour apprendre à se passer de Navteq / Teleatlas? ;-)

Source: blog Media & Tech (par didier durand)