Internet / Web 2.0 comme plate-forme: les 3 niveaux de Marc Andreessen

Marc Andreessen, père du 1er navigateur Internet Mosaic puis fondateur de Netscape (qui a ouvert la voie à toutes les entrées en Bourse de la première bulle) livre aujourd'hui une analyse très profonde sur l'Internet ou le web en tant que plate-forme. Il veut ainsi recadre ce terme que la majeure partie des startups du moment ont tendance à utiliser pour "être (paraître ?) dans la tendance"!

Plate-forme, késako ? Pour M. Andreessen, c'est très simple: un système peut prétendre au titre de "plate-forme" si et seulement si il est programmable (i.e. adaptable) par des programmeurs distincts de ses concepteurs pour lui faire faire des choses non prévues par ces concepteurs ou hors de leur sphère d'intérêts / de priorité.

C'est la définition de toutes les générations précédentes de matériels informatiques précédentes: mainframes, mini, PCs, etc... voire de certains logiciels applicatifs (de type ERP par ex.) offrant des interfaces de programmation (APIs) permettant d'en modifier le comportement.

Partant de ce principe, M. Andreessen propose d'ignorer voire renier tous les services qui s'appellent plate-forme alors qu'ils ne sont pas programmables "de l'extérieur".

Au-delà des plates-formes informatiques "standards" citées plus haut, l'Internet permet de réaliser des plates-formes distribuées (... donc plus complexes!) à travers les liaisons permanentes à très haut débit avec lesquelles il a capillarisé la planète.

Les applications basées sur la plate-forme Internet sont composées de multiples éléments souvent répartis au travers de la planète. C'est ce que j'ai déjà appelé "Linternux" (à plusieurs reprises).

M. Andreessen classe ensuite ces plates-formes actuellement émergentes en trois niveaux (sans jugement de valeur):

• Niveau 1 = API de service (distant): les services distants (avec API): Flickr, Del.icio.us, EBay, Amazon, Google, Yahoo ont été les premiers prestataires à offrir ces APIs de service distantes qui permettent de piloter leurs systèmes pour en extraire des données et leur faire faire des choses autres que les services rendus par l'interface Web de l'application de base du prestataire. Ce niveau 1 a permis l'émergence des mashups où un développeur combine via ces APIs de service (de manière additive ou multiplicative) les données disponibles pour fabriquer sur son propre site un nouveau service bien distinct tant "géographiquement" (autre serveur) que graphiquement (interface utilisateur différente).

Commentaire: Pour Andreessen, le défaut de ce niveau 1 est justement la séparation de l'application utilisatrice du niveau 1: il faut construire un nouveau site en entier avec le logiciel, le matériel, un design agréable, etc... Heureusement que les S3 ou EC2 d'Amazon ont été conçus pour limiter les dégâts: Jeff Bezos, le CEO d'Amazon, estime qu'il peut ainsi faire économiser jusqu'à 70% de cet effort d'infrastructure par l'utilisation de ses services qui sont d'ailleurs eux-mêmes des plates-formes. Ce niveau 1 représente donc pour M. Andreessen une barre financière et technologique encore trop élevée qui freine ainsi l'innovation.

Bien sûr, le niveau 1 est le plus sûr pour l'offreur d'APIs: son client est externe et il est ainsi facile de limiter les dégâts de mashups mal architecturés: ils ne font de la casse que chez eux!

• niveau 2 = plugin par API: le développeur "injecte" de nouvelles fonctions dans l'application du prestataire par un jeu d'APIs (supplémentaires à celles d'accès aux données) qui lui permettent de s'intégrer fluidement dans le site principal et ainsi de profiter de son audience. Facebook a ouvert en Mai 2007 le bal en ouvrant ainsi sa plate-forme au niveau 2. Le succès est arrivé vite et fort: 4'000 applications nouvelles (n'ayant rien coûté en développement à Facebook...) sont maintenant disponibles à ses 40 millions d'utilisateurs enregistrés
  

Commentaire: dans le cas du niveau 2, l'application est toujours externe: elle tourne sur le même serveur distant qu'au niveau 1 mais le résultat est présenté sur le "grand site" au lieu du site de mashup. Le cas d'école dramatique du niveau 2 est bien illustré par ce billet de Jean-Marie: le développeur de talent se trouve submergé par son succès et ne peut pas faire face financièrement. Il n'a pas encore réfléchi à la monétisation solide de son service qu'il lui faut déjà faire face à la horde de visiteurs en provenance de Facebook et louer des tonnes de serveurs.... Résultat: le service s'écroule ou le développeur doit vndre à la sauvette en laissant ainsi beaucoup d'argent sur la table si on compare à une situation où il aurait gagné plus mais moins evite en prenant le temps de construire solidement via des partenaires investisseurs.

Le grand avantage initialement perçu ('audience énorme instantanée) du niveau 2 devient finalement le coup fatal , c'est que le développeur voit son application immédiatement bénéficier de l'audience directe du site Le niveau 1 est plus graduel donc meilleur pour celui qui veut construire pour l'avenir: il faut en effet toujours plus de temps que prévu pour se faire connaître si on part isolé.

Dans le niveau 2, le Facebook-like prend aussi un risque: son image peut être chahutée si les services pluggés cafouillent. La majorité des utilisateurs vont lui attribuer le souci. Mais bon, il dispose du tableau de commande alors il peut couper!...

• Niveau 3 = plate-forme runtime: C'est l'extension du niveau 2 pour annihiler les problèmes d'infrastructure. Le prestataire offre un environnement d'exécution complet au développeur sur lequel celui-ciC télécharge son application et ne s'occupe ensuite pas de son exploitation. Adieu les soucis de matériel et coûts afférents! Le développeur n'a plus besoin de ressources financières: son temps suffit... Il peut par ailleurs rester 100% focalisé sur la correction de ses bugs et l'implémentation de nouvelles fonctions. [Le prestataire a lui bien sûr une problématique très complexe: sécurité, "gérabilité", performances, etc...). Puisque l'environnement d'exécution devient homogène et pour en accélérer encore l'évolution, M. Andressen suggère de lui appliquer une dynamique favorisant l'échange (gratuit ou payant) de code entre les développeurs
  

Commentaire: Marc Andreessen développe actuellement une telle plate-forme: c'est Ning qui est déjà riche de 100'000 applications (de "granularité" très diverse sûrement ...) selon son billet . Il suggère aussi que SalesForce.com devient une telle plate-forme de niveau 3 (restreint à sa spécialisation du support aux forces de ventes). Second Life est aussi dans ce créneau avec toutes les extensions logicielles qu'il permet.

Ma conclusion: les niveaux 2 et 3 me paraissent très dangereux pour le développeur isolé:

• il livre aux grands sites qui l'accueille toutes ses idées
  
• il les réalise "en live" ce qui permet de voir tout de suite ce qui marche de ce qui ne marche pas
• cela se passe tellement vite (puisque le site a déjà des millions d'utilisateurs...) que le développeur doit décider très vite: je vends mon prototype tout de suite (en tant que tel donc moins cher...) ou je risque de tout perdre

Finalement, les niveaux 2 et 3 ne font qu'exacerber ce que promettait le niveau 1 (les mashups): un outsourcing (gratuit!) pour les grands de leur R&D qu in'ont plus qu'à acquérir ou recopier ce qui marche avec une dose de risque devenue infime...

Même s' ils jouent le jeu de la monétisation partagée par ses règles, les goliaths sortiront toujours vainqueur par le truchement du nombre très limité d'agrégateurs que permet un Internet global. Ce reseau favorise une concurrence forte où tout service se bat sans frontière ni distance contre tous ceux qui font la même chose: il n'y aura toujours que quelques grands fleuves financiers basés sur la consolidation des multiples ruisselets-mashups!

Et vous, qu'est-ce que cela vous inspire ces niveaux de plate-forme Internet?

Source: blog Media & Tech (par didier durand)

Web 3.0,...,N.0 : vie online, transparence et publicité

J'aime beaucoup ce récent billet de Nicholas Carr, mon "poil à gratter" favori, sur le business model en vogue du Web 2.0 qu'il étend d'ailleurs aux futures autres générations (3.0, 4.0, ....N.0)

N. Carr attribue ce modèle à Google mais au vu des récentes annonces de Microsoft, on peut sûrement dire que c'est celui des titans de GYM (Google, Yahoo, Microsoft).

C'est une version caustique de la stratégie annoncée pour Microsoft par Ray Ozzie

On peut le synthétiser en "faire vivre en ligne en transparence pour sponsoriser"

Selon Carr, tous les combats que mènent Google actuellement (wifi gratuit, fréquences mobiles, open source, services à la Feedburner, Google Maps & Google Mail rendus gratuits, etc...) sont destinés à détruire toutes les barrières économiques, technologiques et légales afin d'enchaîner 3 étapes:

1. nous faire passer la majeure partie de notre vie online
2. rendre cette actitivité virtuelle traçable et transparente
3. sponsoriser les services gratuites utilisés lors de cette activité par de la publicité (voir la fin de ce billet)
   

Cela renforce mon idée que Google cherche par sa destruction créatrice à aider les producteurs de de contenus services en ligne (blogueurs ou "masheurs") à construire leur site afin de pouvoir écouler ensuite à travers eux plus de publicité et devenir ainsi immensément riche via l'agrégration de micro-résultats.

Cette analyse de Carr me fait par contre percevoir le "SaaS" sous un angle nouveau: l'architecture infomatique idéale pour forcer la réalisation de 1. et 2. ci-dessus. 3. découle ensuite naturellement....

la définition qui en découle: "Web 3.0 involves the disintegration of digital data and software into modular components that, through the use of simple tools, can be reintegrated into new applications or functions on the fly by either machines or people."

On va donc désintégrer nos systèmes informatiques en leurs services les plus élémentaires et les recombiner en temps réel et sans effort pour réaliser des applications de plus en plus personnalisées et personnelles.

Encore un peu ésotérique et lointain, certes! Mais, il semble bien que cette évolution vers un Linternux unifié et global soit le sens de l'histoire (actuelle...)

Conclusion de Carr: mettez tout cela dans votre (Yahoo) pipe pour le fumer!

Source: blog Media & Tech (par didier durand)

Commentaires du jour [15] - Mapplets, Mashup, Assassinat et Attrape-Startup

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

J'ai reçu des commentaires super-intéressants à propos de mon billet sur les mashups promus par mapplets ainsi que les vices et vertus de l'écosystème mashup.

Comme tout le monde ne vient pas relire les commentaires sur ce blog après la publication du billet, je republie les 3 plus intéressants:

• ceux de Benoìt et Richard que j'avais mis en cause via des liens dans le billet (vraiment cool ce Technorati pour répérer quand on est lié par qqn..)
• celui de Stéphane
  

Donc, Richard a dit: "Si j'ai écris que Google assassine les mashups, je parlais en réalité de services existants comme Tinymaps réduit en service has been par MyMaps, et aux services qui proposaient les fonctions que Google a intégré.

Je pense comme vous que le fait de fournir des API grille la concurrence, pourquoi refaire ce qui est disponible ? Mais utiliser une API signifie une dépendance technologique. Dans le cas de TinyMaps par exemple, le travail des ingénieurs a été réduit en poussière par les équipes de Google.

Du côté des micro-contributions, l'idéal pour Google est quand même que l'utilisateur vienne alimenter SA base de donnée que celle d'un tiers. Je pense que c'est à ce niveau là que les mapplets interviennent.

Par exemple, il existe un mapplets "annonces immobilières", imaginez le nombre de sites web qui peuvent commencer à trembler.

Finallement, Google n'assassine pas les mashups, il les transforme en attrape-startups."

Benoìt lui a dit : " Personnellement, l’un des problèmes que je perçois avec les services mashup, conçus avec les API de Yahoo, Microsoft et surtout Google, est que l’entreprise qui le réalise ne possède pas la propriété de la technologie utilisée.

En tout temps, si Google ou autre géant de ce type décide de changer sa politique d’utilisation des API ou de reprendre une idée et de l’exploiter lui-même, les services tiers qui basent leur développement sur des mashups peuvent se retrouver en difficulté.

Par exemple, en novembre dernier, Google a acquis JotSpot. Or, plusieurs entreprises comme Jotxpert développaient des Wikis pour des clients qui utilisent JotSpot. Comme il n’y a plus de nouvelles inscriptions sur JotSpot, ces entreprises perdent des revenus et se voient forcées de réorienter leur offre.

La même chose pourrait bien se produire chez ceux qui construisent leur service autour des cartes de Google. Je ne suis pas de ceux qui pensent que Google est un épouvantable monstre. Mais lorsqu’un géant fait un faux pas, il peut sans le vouloir, ou même le remarquer, écraser quelques partenaires."

Enfin, Stéphane a dit: "Concernant les écosystèmes que construisent les offreurs d'API, je reprendrai Amazon et Google :

Le systeme d'affiliation d'Amazon repose sur l'ouverture de leur catalogue, une part de leur CA est donc intimement lié a l'exploitation de leur API par leur communauté.

Pour Google, c'est different. En quête perpetuelle de nouveaux business models [BM], il est important voire primordial pour eux d'ouvrir autant que possible les portes de leurs 'labs', la meilleure facon de le faire etant de sortir des API. Ceci a pour consequence de 'liberer' non plus la seule creativite du personnel de Google, mais aussi celle de toute la communaute internet.

Il y a donc une différence dans les écosystèmes de Google et d'Amazon. L'existence d'un BM de la part de celui qui met a disposition l'API doit donc être pris en considération. Plus le BM est clair moins il y a de risque que son propriétaire ne viennent perturber votre business, son CA etant relié au votre.

Dans d'autre cas, on part un peu a l'aventure. On ne peut être sur de rien avec les API de Google. Les API ne font qu'entrouvrir les portes des labos, les portes du marketing étant sérieusement verrouillées.

Quelles sont les parades alors ?
Multiplexer les API ? Trop tard car Yahoo! Pipes va donner a tout un chacun l'outil (utlime ?) pour se creer son propre mashup.
On en revient alors à ta définition des mashup : la valeur ajoutée multiplicative. Peut-on alors qualifier TinyMaps de mashup, le service ne proposant qu'une fonctionnalité à l'API GoogleMaps ? Je ne pense pas.

Il faudra alors être certain d'apporter une réelle valeur ajoutée à l'utilisateur pour ne pas se faire écrabouiller par Google (ou Yahoo, pour ne pas les laisser en reste). Mais cette règle n'est-elle pas tout bonnement le principe de tout bon business ? "

Instructifs ces commentaires, non ?

C'est vraiment ce que je trouve fantastique dans la blogosphère: pouvoir échanger des idées avec des personnes que l'on ne rencontrerait pas sans elle.

Source: blog Media & Tech (par didier durand)