La plupart du temps, le problème que l’on rencontre avec les CMS, c’est qu’on est devant une solution pré pensée en terme de modèle de données. Sauf si vous faites du blogging pur et simple, j’ai toujours l’impression qu’il me manque quelque chose, ou alors il me faut des solutions complexes qui me donnent plus envie de faire du développement sur mesure from scratch…

Et voilà que je découvre Crowdfusion, créé par Brian Alvey et son équipe (ils sont à l’origine de Blogsmith / Weblogs Inc entre autre).

L’avantage : on définit réellement son modèle de données presque comme on le ferait avec Rails… à part que là, on est sur un CMS, et donc, c’est du pain béni. On développe vite, bien, rapidement, on se focalise sur les fonctionnalités et surtout sur la facilité de prise en main pour le client final.

Pour preuve : un site avec gestion d’évènements complexe, zone membres, multilingue, élections de startup, annuaire, sidebars customizable par page, etc etc… développé en 4 jours.

Je n’en dis pas plus… je vous laisse aller sur http://www.crowdfusion.com et inscrivez vous à la beta pour télécharger le bijou.

NB : des sites comme TheDaily, TMZ, certaines properties MySpace etc… tournent sur Crowdfusion.

Bon, y’a pas eu de post depuis longtemps, il y a des commentaires qui se demandent quid de yesornow, d’autres sur les solutions de cms, etc…
J’en profite pour faire un petit update rapide sur mes activités, et sur le statut de certains projets.

YesOrNow

YesOrNow est un projet qui me tient à coeur. Comme je l’ai exposé à demi mots, la cause de l’arrêt de YesOrNow fut une dissenssion entre associés. La société et le produit se sont retrouvés paralysés. Pourtant l’idée en elle même est pour moi toujours aussi bonne. Si je devais le refaire, je le referais de manière beaucoup plus simple. Quand j’ai voulu reprendre le projet, je n’avais pas compté sur le fait que de nombreuses choses allaient changer dans ma vie professionnelle. Je suis toujours partant pour le relancer, je n’ai juste plus le temps de le programmer par moi même. Sinon, j’ai toujours le code source de YesOrNow…

Vision sur le dating aujourd’hui

Je suis sidéré par le nombre de sites de dating qui se montent, et au final, on a toujours les mêmes noms.
Le marché français est hyper saturé, en recherche de différenciation, et oublie parfois certains basics, le premier étant la concentration des utilisateurs. Un site de dating n’a de la valeur si il me permet de trouver quelqu’un près de chez moi. Quand je vois un site récent qui a levé plusieurs millions qui me proposent via une techno inspirée d’Amazon (les gens qui ont aimé ce profil on également aimé…) des femmes de 60 ans vivant au Texas, je me dis que soit ils ont rien compris au Dating, soit ils se moquent du user. Du coup, je repense à ces deux business models fondamentaux : business model de revenu ou business model de valorisation. D’un côté, du pérenne, d’un autre de la spéculation, du gonflement de base. Je crois qu’on arrive un peu au paroxisme du marché français où chacun veut devenir un nouveau Simoncini.

Nouveaux territoires

C’est un peu pour ça que mes vues s’orientent vers l’orient depuis quelques mois. Un projet va voir le jour en Asie du Sud Est. Je n’en dis pas plus…

Nouvelles activités

En parallèle, je développe mes activités avec deux boutiques. La première est The Tiny Transatlantic Web Company, une petite boutique de web design. Ca me permet de rester au contact des basiques du web, les problématiques techniques, l’évolution du HTMl et du CSS, des CMS, réfléchir design, etc… La deuxième qui est toute jeune est Producture, une boutique de consulting produit dont je crois réellement au concept. Et toujours plein d’idées de produit dans les tiroirs, dans le disque dur. Des specs, des photoshops s’empilent… Après c’est ce que j’appelle la sélection naturelle des projets.

Voilà c’était un petit point rapide. A bientôt ;)

Je profite de mon blog pour annoncer que je travaille en ce moment au retour de YesOrNow, car, comme je le disais dans un précédent post, le concept est à mon sens très bon et qu’avec la réflexion, j’ai compris ce qui n’allait pas.

Trop de complexité : le désir d’avoir un produit parfait nous a éloigné de l’essentiel, notre proposition de valeur : que les gens se rencontrent réellement, facilement, quand ils le désirent. Nous avions trop de fonctionnalités, le site était une « merveille » technologique, mais aussi une usine à gaz, qui rendait non évidente le processus de prise de rendez-vous, et également qui rendait le site trop lourd tant au niveau serveur que client (charger 70 000 lignes de javascript et 4Mo de sprites css png, ce n’est pas une mince affaire ;) ).

Trop de contraintes : à force de vouloir un produit parfait, un service parfait, nous avons présenté sur le marché un produit où peut-être il n’y avait pas assez de liberté.

Au final, c’est tout le flow de l’utilisateur qui est était revoir. Tout était à stream-liner.

J’y travaille donc, petit à petit, boosté également par des petites histoires qui m’arrivent.

Par exemple, je viens d’apprendre toute à l’heure celle d’un couple qui s’est formé grâce à YesOrNow pendant sa petite existence publique. Le retour de ce nouveau couple (qui a déjà trois mois) est plus que super positif.

D’autres couples se sont formés grâce à YesOrNow.

Et cela me plaît, que des histoires d’amours naissent grâce à des journées et des nuits de travail. La première histoire qui s’est créée depuis les débuts de cette aventure dans le dating, c’était sur Datingwatch. Un de nos premiers lecteurs a rencontré sa moitié sur ce blog, via les commentaires (j’avoue que nous n’avons jamais vraiment compris comment ils ont fait). J’ai cru comprendre qu’ils s’étaient fiancés, peut-être mariés aujourd’hui.

Et je trouve que c’est une très belle justification d’une démarche entrepreneuriale.

Car finalement, les relations amoureuses sont le ciment de nos vies, le ciment qui met du sens, de la joie, dans nos quotidiens où l’on court à droite et à gauche.

Et j’aime l’idée que YesOrNow propose un service de rencontre qui s’inscrit dans la vie. La vraie.

Le retour en ligne de YesOrNow ne se fera pas en un jour. Je suis actuellement tout seul à reprendre le navire, et je dois reprendre de A à Z toute la programmation du site, et cette fois-ci, avec mes petites mains, puisque notre développeur nous a quitté. Et, comme j’en parlais dans mon post ultra-geek précédent, j’ai envie de connaître mon produit de l’intérieur. Un peu une approche artisanale, somme toute.

Cela prendra quelques mois, je ne peux m’avancer sur une date de (re-)lancement. Surtout que je jongle avec les missions à droite et à gauche.

Tout ce que je peux dire, c’est que ce sera plus simple, plus léger, plus intuitif, et même plus joli ;).

Au final, je considère plutôt cet incident de parcours comme la chance de faire de YesOrNow ce que cela aurait dû être dès le début. Plus sur ce que j’entends par là très bientôt.

Attention, ce post est ultra-geek.

J’ai quelque peu fait allusion précédemment à ce langage un peu exotique. Il faut dire que mon côté geek aime bien tout ce qui est langages de programmations. J’ai très tôt apprécié Ruby et Rails, et l’approche agréable du «tout objet» de Ruby.

Mais l’aventure YesOrNow version 1, entièrement en Rails + JS, il m’est apparu des choses toutes bêtes, et j’ai cherché comment y remédier.

Ces «choses toute bêtes» sont à mon sens des facteurs clef de succès dans le web. Car c’est un chose d’avoir une bonne proposition de valeur, un bon marketing mix, une bonne interface. Il faut que derrière, cela tienne, et que cela soit performant.

L’approche Rails / 37 Signals / désinvolte, c’est en deux mots : si vous avez des problèmes de scaling, cool, c’est que ça cartonne ! En effet, mais autant ne pas avoir de problème de scaling, car préserver l’expérience en cas de forte exposition est justement primordiale : c’est tout d’un coup l’occasion de faire connaître ce que l’on fait à de nombreuses personnes… autant que la première impression soit bonne.

Aussi, pour 37 Signals, leur business model uniquement par abonnement, sans partage entre comptes clients, limite ces problème de scalabilité car le coût a moins à jouer.

L’argument, c’est aussi qu’une architecture scalable, c’est complexe. Cela veut dire systèmes de cache (mais cela, même quand on a pas à scaler, c’est nécessaire car améliore immensément les performances et soulage le server…. d’autant que NGinx l’intègre dans son coeur), systèmes genre memcached de distribution, cache et partage d’objets, réplication de bases MySql et structures Master-Slaves ou autre… Enfin, tout le tintouin.

PHP n’est pas bien différent. La seule différence avec PHP, c’est que ce language est tellement souple qu’il est un peu trop facile de mal coder… Et comme tous les développeurs web font du PHP, il est plus difficile de séparer le bon grain du mauvais grain.

Et donc… Erlang.

Erlang, c’est d’abord un monsieur, un mathématicien. Mais ça on s’en moque.

Erlang, c’est maintenant un language. Un truc un peu fou inventé chez Ericsson pour leurs besoins propres, afin d’avoir des PABX et autres machineries des telecoms qui soit stables, performantes, etc… Enfin, un truc pour gérer des telecoms au niveau d’un pays quoi.

Donc, quelques mecs se sont réunis, dont un certain Joe Armstrong, qui est un peu le DHH d’Erlang, version père de famille, je fais pas de surf des neiges, mais je suis brillant et marrant, et ont réfléchi.

Ils ont pondu Erlang, qui est un langage fonctionnel.

Pour ceux qui se demandent, un langage fonctionnel c’est ça (Wikipedia) :

La programmation fonctionnelle est un paradigme de programmation qui considère le calcul en tant qu’évaluation de fonctions mathématiques et rejette le changement d’état et la mutation des données. Elle souligne l’application des fonctions, contrairement au modèle de programmation impérative qui met en avant les changements d’état.

En gros, ici, pas d’objet, des fonctions. Que des fonctions, dans des modules. On ne partage aucune donnée, on se passe des messages entre fonctions. Moi, personnellement, ça me plaisait bien, parce que je codais intuitivement un peu comme cela : la programmation objet me faisait mal à la tête, car je savais jamais où en était mes objets à chaque moment. Là je sais.

Après, Erlang a d’autres caractéristiques, qui elles sont intéressantes pour nous, personnes du Web.

1. C’est un langage concurrent. C’est à dire que les process fonctionnent en même temps en utilisant toutes les ressources des processeurs multicoeurs. Cela est possible car la mémoire n’est pas partagée : les fonctions s’envoient des messages. Mais là où ça devient génial, c’est qu’Erlang fonctionne par noeuds : c’est à dire que ma fonction trucmuche, sur mon Mac, peut envoyer un message à la fonction bidule sur le PC de mon pote australien, qui à son tour envoie un message à machin etc… Scalabilité vous avez dit ?

2. C’est un langage rapide, qui se compile à la volée. En gros, plus de deux fois plus rapide que PHP5 et 4 fois plus rapide que Ruby.

3. C’est un langage qui supporte nativement le versionning. C’est à dire qu’on peut faire une rollout de nouvelles fonctionnalités ou corriger des bugs sans downtime, le language intègrera de lui même les nouvelles versions intelligemment.

4. C’est un langage qui incorpore sa base de donnée, Mnesia, elle même distribuée sur plusieurs noeuds, on peut fragmenter les tables, etc… et les performances sont excellentes.

5. Plusieurs serveurs web existent pour Erlang : Yaws, Mochiweb principalement. Les deux ont des performances superbes, surtout derrière un Nginx. Yaws est célèbre pour tenir à plus de 80 000 connexions simultanées quand Apache meurt à 4000….

6. Quelques frameworks web commencent à poindre leur nez, dont Nitrogen. Et aussi, niveau CMS, Zotonic apparaît. Au programme,… je vous laisse découvrir.

7. Dernier point : la possibilité de bundler son applicatif, erlang compris. Vous l’uploader sur le serveur, vous configurer votre NGinx pour qu’il pointe sur le bon port de votre mochiweb, vous faites un petit ./start.sh, et hop, c’est live, database incluse. C’est pas beau ça ?

Sinon, niveau syntaxe, au début, ça surprend…. Surtout quand on sait qu’une variable ne peut changer de valeur… mais son scope est limité à sa fonction. En fait, il faut vraiment plonger dedans pour comprendre (je commence à peine) comment ça marche, mais ça va assez vite.

En fait, ce qui me plaît dans ce langage, c’est qu’il semble résoudre la plupart des contraintes techniques du Web : performance, stabilité, scalabilité.

Petit détail en passant : 37 Signals, Facebook et Meetic utilisent Erlang pour leurs systèmes de chat.

Et bien sûr, le gros inconvénient d’Erlang c’est de trouver des développeurs en Erlang !

Donc voilà, c’était le post ultra-geek pour commencer février. Promis, je ne parlerai pas d’Haskell ni d’OCaml !

[UPDATE] Un article suit celui-ci annonçant que je relance le projet [/UPDATE]
Il y a maintenant presque deux ans, j’ai démarré avec mon acolyte Youri un projet, YesOrNow. Le site à été lancé en Novembre dernier, et au bout d’un mois d’existence, on a du fermer. Pourtant, beaucoup de choses étaient très très positives : nous arrivions à tenir notre promesse, ce qui n’était pas évident : organiser des rendez-vous entre célibataires. Le principe était simple :

1. 1 – Vous indiquiez qui vous plaisait.
2. 2 – Vous indiquiez quand vous étiez libre.
3. 3 – On vous réservait une table dans un bar (ça, c’était un tour de force), avec une personne qui vous plaisait et à qui vous plaisiez.

Le dating est un marché hyper concurrentiel. Toutefois, ce qu’on remarquait, c’était que l’offre de valeur était toujours la même : l’accès à une base de données et des fonctions de communication. Notre stratégie était donc d’élever fondamentalement la valeur de notre offre : ce que nous « vendions », c’était du rendez-vous.

Toutefois, il nous a fallu du temps pour arriver à ce concept. Et là, ce fut la première erreur.

Le développement a commencé alors que notre différenciation était classique : plus de sécurité, interface plus travaillée, fonctions de matching comportemental avancées, tarification permettant une segmentation à l’entrée. Rien de très excitant, le projet s’appelait alors Affinities (je possède toujours la marque d’ailleurs — c’est devenu drôle quelques mois après quand Meetic a lancé Meetic Affinity).

Et là, ce fut le premier problème et notre première erreur. Nous connaissions très bien le marché, mais trop bien (cf l’aventure DatingWatch). Prendre de la distance pour imaginer quelque chose de nouveau était difficile. En même temps, les lignes de code de notre développeur s’empilaient, nous avions des fonctions superbes (un messenger notamment avec archivage des discussion et recherche par mot clef, etc…). Tout cela intégré dans une interface 100% javascript.

Et quand l’idée est apparue, d’une manière simple en répondant à la question qu’on devrait tous se poser : « De quoi je rêverais pour faire des rencontres ? », et que la réponse fut simplement « Qu’on m’organise des rendez-vous avec des personnes que j’ai envie de rencontrer », ce fut un peu le branle bas de combat.

Branle bas de combat avec notre développeur : virer plein de choses, dont la gestion des contacts (on se basait désormais sur un tryptique Oui / Non / Pourquoi Pas) qui était un des coeurs du système. Passer des journées à faire des équations et des algorithmes pour aboutir à de nouveaux algorithmes de matching correspondant aux nouvelles interactions, mettre en place des API de géolocalisation, un moteur de réservation et de gestion de disponibilité des bars, prenant en compte la localisation de nos clients et leurs différentes adresses (personnelles, bureau, etc…), et surtout prenant en compte le fait que rien n’est sûr avec les bars jusqu’au moment où on a venant d’un bar un OK, c’est bon pour ce soir, deux tables, 20h30 et 21h15.

Cela a aboutit à une refonte du business model, en passant de l’abonnement au rendez-vous (changement de proposition de valeur oblige).

On a donc passé notre temps à essayer de mettre en place toute une nouvelle logique, qui n’existait nulle part, en faisant plier un code déjà existant pour le faire entrer dans un nouveau concept.

Et c’est là qu’on s’est planté.

On s’est planté car on a livré un produit qui était bon, mais pas totalement cohérent encore. Il nous fallait changer nos modèles d’interactions entre nos membres pour augmenter le nombre de rendez-vous ainsi que notre mode d’inscription, trop « dating classique ».

Et après beaucoup de conversations avec différents investisseurs, qu’on a toujours refusé, trop jaloux de notre capital que nous étions, on s’est retrouvé dans une situation où notre développeur ne pouvait plus survivre financièrement. Et les dernières modifications à apporter au site étaient trop lourdes, trop coûteuses tant en temps qu’émotionnellement.

Car c’est ici finalement que s’est situé notre « péché ».

C’était notre premier vrai projet entrepreneurial, le premier qui voit le jour. Et au final, ce fut une aventure romantique, presque épique. Tout devait être parfait, nous étions « trois frères de sang » à l’attaque du marché B2C le plus concurrentiel de l’internet français.

Nous avons mis toutes nos tripes dedans, et au bout d’un moment, à force de changer les choses, l’un de nous n’en pouvait plus. Malheureusement si près du but.

Aussi, c’était comme un bébé, ce site. On justifie ses choix de carrière par rapport à ce projet, on convainc son entourage de la viabilité, de l’innovation du projet. On en arrive à se définir par rapport à ce projet, par rapport à ces 100 000 lignes de javascript et 30 000 lignes de rails entreposées sur un serveur.

Et nos choix sont pas toujours les plus rationnels. Surtout à plusieurs.

Je discutais hier de la différence entre convaincre et persuader. Convaincre fait appel à la raison, persuader à l’émotion. On peut détruire un argumentaire raisonnable, mais jamais une émotion. Toutes nos levées de fonds doivent leur échec à l’attachement affectif à notre projet, à la peur de s’en voir expropriés, alors que rien n’était fait. Nous avions mis tellement de valeur dans le projet pour légitimer notre choix, que nous ne voyions pas que rationnellement, le projet n’avait pas de valeur tant qu’il ne dégageait pas un cash flow confortable.

Au bout d’un peu plus d’un mois, près de trois mille inscriptions, plus de 550 000 pages vues et 50 000 visites, avec des temps de connexion moyen de plus de 20 minutes par connexion, on a fait un ./stop_server entrée.

Voilà. YesOrNow n’est pas mort, mais cette aventure, comme elle le fut, est terminée. YesOrNow revivra un jour. Je l’espère, d’autant plus que je suis intimement convaincu du concept, et que je sais ce qui n’allait pas.

Le romantisme est mort. Vive la raison, animée de passion.

Juste pour finir, je me permets de citer mon ami Rupert Schiessl, un des fondateurs de Verteego :

« Ce que je trouve fascinant dans la création d’entreprise et que nous avons tous lus de nombreux ouvrages de créateurs d’entreprises approuvés témoignant de leurs erreurs pour ensuite refaire les mêmes. »



[UPDATE : dernier coup de coeur (Crowdfusion) ici]

C’est une question dont on discute souvent entre webmasters, webdesigners, webmarketers, etc… : l’architecture technique. Il faut que nos choix:

• répondent au maximum aux besoins du client en terme de fonctionnalité (pour éviter au maximum le développement sur mesure),
• qu’ils soient simples d’usage pour le client (même si facturer de la formation peut-être tentant, c’est un mauvais calcul, car ce sera un mauvais souvenir et pour le client qui se sent bête et ne sait pas s’il pourra se débrouiller tout seul et au final le site ne vivra pas, et pour vous, parce que la formation, c’est pas votre coeur de mêtier),
• qu’ils soit sur des plateformes génériques (PHP/MySql // même si je vais vous parler de quelques perles à la fin de l’article je pense)
• et que vous vous sentiez à l’aise à les manipuler.

En types de sites, je vais aborder les sites généralistes, les blogs, les sites e-commerce et les sites plus « sur-mesure ».

Je ne vais pas faire un tour de tout ce qui existe (il y en a trop). Je vais parler des principaux et de ceux moins connus qui ont retenus mon attention. En gros, je vais aborder :

• Joomla (ex Mambo), avec lequel j’ai commencé et que je connais bien, ainsi que son copain ecommerce Virtuemart
• WordPress, que je connais par coeur
• Drupal, incontournable
• Concrete5, pas très connu, mais je l’adore
• PrestaShop
• Magento
• OsCommerce

Ceux que je voudrais tester, mais pas eu l’occasion :

• Expression Engine,
• EzPublish

D’emblée, j’écarte les solutions pré-hebergées, courantes. Je pense qu’en tant que professionnel du web, notre devoir est de proposer du dur, c’est à dire du serveur + solution clef en main, et qu’on ait le loisir de toucher le code de la bête.

Je vais faire le tour par type de site / client.

Première Catégorie : Le site « je présente mon business » et le client « n’a pas trop le temps de s’y consacrer ».

Là, ma réponse est directe, rapide : Concrete5.

Pour plusieurs raisons : d’abord, le moteur de templating est un véritable régal, plus encore que WordPress, c’est dire. Faites votre HTML / CSS / JS, testez le en cross-browser, faites vos variantes, puis remplacez vos zones de contenu par des marqueurs que vous inventez, autant que vous voulez par page. L’édition, pour le client, se fait en wysiwyg, sur la page même. Un vrai régal et pour vous, et pour le client, et les performances sont correctes. Cela convient parfaitement pour le client qui se dit au bout de quinze ans, tiens, il me faudrait un site quand même.

Deuxième Catégorie : Le site d’entreprise avec de l’actualité fréquente voire un blog.

Réponse : WordPress.

WordPress est d’une souplesse impressionnante, et plus je l’utilise, plus je me rends compte que l’on peut presque gérer des catalogues de produits (sans vente bien sûr). De plus, c’est une véritable merveille en terme de référencement si on fait bien son template (je me souviendrai toujours avec émotion du jour où DatingWatch, le blog que je tenais à l’époque, s’était classé en troisième position sur le mot clef Meetic, juste après Meetic.fr et Meetic.fr).

Son moteur de template est super souple. Je lui reproche juste parfois, dans l’intégration des plugins, d’interférer avec les javascripts que l’on installe soi même. Donc, bien débugguer, surtout sous IE 6…

Troisième Catégorie : Le petit site e-commerce sympa et le web commerçant qui n’en veut.

Réponse : PrestaShop.

Simple d’utilisation pour le client, le templating est standard (Smarty). Un avantage, c’est qu’il est français, donc s’adapte à merveille à nos chers petits clients. Exemple, le module de paiement Atos est intégré. PrestaShop est souple et léger, et certaines des boutiques que j’adore tournent dessus, c’est ce qui m’a fait l’adopter.

Quatrième Catégorie : Le bon gros site e-commerce.

Réponse : Magento.

Une usine à gaz simple, mais la solution la plus puissante au niveau marketing. La référence, mais nécessite un hébergement à la hauteur (un dédié !). Il s’interface aussi désormais avec WordPress & Drupal. Je n’ai pas eu la chance pour l’instant de mener un projet en entier dessus, me suis contenté de le tester et le templater. Mais dieu, pour le marketing, que c’est beau (on peut créer des promotions complexes comme on aime)

Cinquième élement : Le big site.

Réponse : Drupal.

Et bien là, soit un développé totalement dédié, soit Drupal. Surtout qu’il s’interface avec Magento s’il faut de l’ecommerce en plus. Une usine à gaz modulaire… on peut juste tout faire avec Drupal, ou presque… Dans tous les cas, il faut pas mal de développement et de connaissances. Mais à vous la dimension communautaire sur votre site et les fonctionnalités avancées !

Le recalé n°1 : Joomla & Joomla/Virtuemart

Certes une référence, mais l’administration n’est pas du tout appréciée des clients, et personnellement, j’ai toujours trouvé ce package ni assez généraliste ni assez spécialisé, bien que très puissant. Mais c’est une affaire de goût, j’en conviens. De plus, le code source est un peu une usine à gaz à l’heure actuelle. Egalement, je n’ai jamais compris la gestion de l’arborescence chez Joomla (enfin, si, je l’ai comprise, mais dieu que ce n’est pas ergonomique — tiens, ça fait deux fois que je dis dieu dans cet article, bizarre ce lundi matin).

Le recalé n°2 : OsCommerce

Je travaille à la refonte d’un site OsCommerce depuis ce matin… et je m’arrache les cheveux, car il n’y a aucun moteur de templating… le code et la présentation sont totalement imbriqués, et TOUT est en table… une HORREUR à fuir absolument…

Ceux qui m’ont tapé dans l’oeil (mais pas forcément gratuits) :

Expression Engine : à priori pour du bon gros site, un peu moins riche que Drupal, mais avec une interface d’admin ma-gni-fique et apparemment des super performances et super puissant. J’ai hâte.

EzPublish : a l’air d’être la référence en terme de fonctionnalités. Il faut que j’aille jeter un oeil.

Les Atypiques

Là dedans, je vais vous parler de choses qui ne sont pas en PHP MySql, mais qui semblent prometteur.

En fait, je ne vais vous parler que d’un seul.

C’est du early-stage (0.2), mais juste un petit tour de ce qui m’a fait flasher :

• 10x plus rapide qu’un CMS php.
• Comet included
• Le modèle de donnée est totalement flexible (catégories de données & relations)
• Template en ETL
• Orienté évènement

Ca s’appelle Zotonic, c’est en Erlang + Postgres. Et en plus l’admin est magnifique… Je parlerai bientôt de pourquoi Erlang me fascine.

Petit Tableau Récapitulatif.

Conclusion Importante

Ce qu’il faut noter, c’est que si on est là pour faire des sites, conseiller en tant que performances, optimiser, nous avons surtout un rôle de diagnostic humain. Trop de fois, j’ai vu des clients me demander un site e-commerce, pour au final qu’ils n’aient pas le temps de s’en occuper, à part deux trois fois par an pour changer les produits. Plus le site est complexe, important, plus le client doit s’y impliquer. N’hésitez jamais à prévenir qu’un site ne vit pas seul, il faut un travail quotidien pour le faire vivre et pour que ça marche.

Non, je n’ai pas vu Avatar. Et de toute manière, ce n’est pas le sujet, car je ne vais pas parler du film en lui même. Le maximum dont je vais parler concernant le dernier Cameron sont les raisons pour lesquelles des milliers de personnes l’ont vu et le verront.

Mais d’abord le contexte.

Le contenu n’a plus de valeur. Je ne vais pas vous refaire le topo, mais tout ce qui est numérisable est duplicable gratuitement à l’infini, et donc tout ce qui est numérisable n’a plus de valeur. Voilà le constat apocalyptique que l’on dresse pour l’industrie du contenu.

En fait ce constat n’est réel que pour l’industrie du contenu sur support.

Il y a à mon sens 2 éléments principaux qui maintiennent de la valeur au contenu face au piratage.

• L’Execution : que la chose s’exécute devant moi, pour moi. Cela vaut aussi bien pour le concert, que pour un software on demand.
• La Catharsis : que la chose soit un expérience sociale (la catharsis est avant tout sociale si on relit la Politique d’Aristote). L’expérience de l’oeuvre ne peut se faire totalement qu’en groupe, qu’au sein de la société, car l’oeuvre a un rôle de purgation et de réhabilitation de l’être ensemble. Cette expérience, faite en solitaire, aura une profondeur, une valeur bien moindre, voire nulle.

Ainsi, les concerts ne connaissent pas la crise du piratage. Ainsi, le cinéma va logiquement se tourner (et dieu sait que les scénaristes d’Hollywood sont des experts en catharsis, en morphologie du conte & en mythologie) vers des « oeuvres » (oui ces guillemets sont snobs) qui ont une dimension sociale, où c’est l’expérience commune qui prime.

C’est à dire que, logiquement, le rapport support enregistré (disque, dvd) — expérience commune (concert, cinéma) sera plus complexe.

Déjà, je voyais de plus en plus le disque comme un support marketing pour le concert.

Mais aussi le disque ou le dvd sert de symbole de l’expérience commune. J’ai vécu l’expérience cathartique Star Wars au cinéma. Par le DVD, je m’y replonge et revis les émotions que j’ai vécu une première fois (parce que j’étais dans l’être ensemble). Le « Collector » est là pour cela.

Voilà, c’est court, je sais, mais ce sont des petites idées qui me trottent dans la tête depuis quelque temps. J’y reviendrais sûrement pour étayer tout cela.

Le titre de ce post peut paraître paradoxal, mais cela n’est pas.

L’apparition de l’iPhone a changé la manière dont nous voyons le téléphone mobile. Ou plutôt nous percevons désormais notre téléphone mobile comme nous avons toujours voulu le percevoir, depuis les livres d’anticipation scientifique : un petit appareil qui nous permet de communiquer, consulter de l’information, agir (réserver un hôtel, se repérer dans l’espace, …) en permanence, ou plutôt n’importe quand, n’importe où.

C’est ici un glissement complet de définition entre le téléphone et le terminal numérique de poche.

Et l’iPhone et les téléphones Androids sont cela : des terminaux numériques de poche très puissants.

L’iPhone devance toute la concurrence : 77% des ventes de mobiles à Noel par Orange furent des iPhones. 45% du trafic 3G aux Etats Unis est du trafic iPhone. Et la question toute techcrunchienne apparaît : qui sera le iPhone Killer ? La réponse est simple : aucun téléphone ne tuera l’iPhone. Mais il est logique que la plateforme Android sera rapidement majoritaire.

Pourquoi Android est une idée de génie ?

Il y avait une place à prendre : celle de la plateforme technologique ouverte de terminal numérique. C’est à dire de profiter de ce qu’Apple avait mis en place comme attente (le terminal numérique simple, l’intégration réelles d’une interaction avec l’environnement — le toucher, le son, l’image, la localisation, la direction – et l’extensibilité aisée par la centralisation de l’offre applicative), et en faire une plateforme ouverte pour les fabricants et les développeurs.

L’idée est donc simple : une technologie excellente, une ouverture totale. C’est un magnifique choix stratégique et industriel, mais aucunement un acte marketing. Car il n’y a pas de produit derrière, mais des produits. Si on regarde la liste des membres de l’Open Hanset Alliance, on note juste l’absence de Nokia parmi les fabricants (et cette position est difficile pour le fabriquant nordique). Cela signifie qu’à court terme, la vaste majorité de l’offre de téléphone sera sous Android. Android devient donc le standard. C’est une stratégie brillante à la Microsoft, avec la culture technologique web de Google (le parcours d’Andy Rubin, l’homme derrière Android, est d’ailleurs interessant, puisqu’il est passé par Apple, Microsoft, avant de fonder Android racheté par Google.).

Aussi, petit point intéressant, c’est le statut Open Source d’Android, totalement conforme avec le constat actuel que le « platform software » ne peut fonctionner qu’en Open Source — et de préférence sous licence Apache, comme c’est le cas ici.

Le Produit reste roi.

Face à la stratégie, il y a le marketing, et donc le Produit. Le Droid, puis le Nexus One, sont présentés tour à tour comme des iPhone Killers. Mais ce sont plus des instanciations de la plateforme Android, des étapes de maturation, que des Produits avec un grand P. Car qu’est ce qu’un Produit ?

C’est d’abord une identité, dont le nom devient un référentiel produit. C’est à dire que le produit n’est pas la somme de fonctionnalités, d’intérêts, mais c’est un tout qui dépasse cette somme. Quelque chose qui véhicule une signification, une culture, une vision du monde, et qui est un objet. On peut l’imiter, on peut faire objectivement mieux, mais ce qui manquera, c’est le sens.

Le sens, c’est la direction, la signification, et c’est l’interaction sensible/sensuelle que l’on a avec un objet.

L’iPhone, de génération en génération, reste l’iPhone. Il ne change pas de nom. Après il y a des modèles d’iPhone : le 3G, le 3GS, etc… mais l’objet est un iPhone. En face, j’ai un téléphone, dont le modèle est un Droid qui a comme caractéristique d’être sous Android. D’un côté, un objet lambda (un téléphone, modèle Droid), de l’autre, un iPhone, modèle 3GS.

La définition basique d’un produit est celle ci : « Un produit est un bien ou un service associé à une production et censé satisfaire un besoin, généralement moyennant un prix à payer par l’utilisateur ».

Une phrase de Nietzsche me vient alors à l’esprit : « L’Homme est le seul animal qui a besoin de sens pour vivre ».

Steve Jobs, en introduisant l’iPhone, avait un discours de création de sens (comme dans tous ses discours d’ailleurs):

« We gonna make some History together today »

Ici c’est la création de sens au plus fort : l’Histoire

« We’re introducing three revolutionnary products : a widescreen iPod with touch control, a revolutionnary mobile phone, a breakthrough internet communicator. »

On continue sur l’Histoire avec deux fois le mot révolutionnaire, le mot avancée / percée (breakthrough).

L’iPhone n’est pas un téléphone, mais contient un téléphone… nuance.

L’iPhone n’est pas non plus la somme de ces trois éléments : c’est trois éléments qui, une fois réunis, changent l’Histoire.

Ainsi l’iPhone restera l’étalon du marché et restera sûrement le téléphone le plus vendu. Mais la plateforme Android va sûrement remporter la majorité du reste du marché, pour une expérience rationnellement similaire, mais émotionnellement plate.

Mais attention, même si je suis un mac user invétéré, et que je possède un iPhone, je ne veux pas dire que ce soit le meilleur terminal numérique de poche du marché. Il est simplement un rouleau compresseur marketing, quand Android est un rouleau compresseur stratégique. Nous vivons une époque formidable.