Cela fait un moment que j’hésite à me désinscrire de Facebook, tant je trouve ce service inutile et tant la question des données personnelles m’est sensible. Et là, suprise : impossible de se désinscrire. Non seulement Facebook se garde le droit de conserver toutes les versions des informations personnelles saisies, mais en plus il n’est pas possible de se désinscrire, seulement “désactiver le compte”. En gros, le compte n’est plus visible par les autres, mais Facebook conserve toutes les données. Sur un service où la problématique des données personnelles est si importante, je suis sidéré qu’on ait pas le droit de désinscrire en étant certain que les données précédemment saisies ont bien été supprimées. Cela me reste vraiment en travers de la gorge, je regrette de m’être inscrit, et si vous ne l’êtes pas encore je vous conseille d’y réfléchir à deux fois.

Pour le reste, je reste sur ma position : je ne vois pas l’utilité de Facebook, et tout ce que Facebook ou les autres réseaux/services permettent de faire techniquement, le Web en lui-même permet de le faire, avec l’avantage que VOUS contrôlez vos données personnelles. Nous sommes amis et vous souhaitez rendre cet info publique ? Eh bien échangeons un lien entre nos blogs. Un ancien ami d’école souhaite me retrouver ? Il a juste à taper mon nom dans Google pour trouver mon blog et me contacter. Je crois qu’on oublie trop que des services comme Facebook ne font que formaliser dans un système d’information propriétaire ce qui existe déjà dans le vie réelle et sur le Web avec des outils personnels comme le blog.

C’est un choix personnel à faire : dans quelle mesure vous souhaitez exposer votre vie sur le Web, et dans quel mesure vous souhaitez contrôler ces informations et l’usage qui en est fait par les tiers (à des fins publicitaires notamment). Pour ma part, le fait de savoir d’avoir donné à Facebook des informations et de n’avoir aucun moyen de dire à cette entreprise “Maintenant vous cessez d’utiliser mes informations personnelles et vous les effacez”, ça me gène vraiment et j’ai l’impression de m’être fait avoir.

Toujours concernant Facebook, un article du Guardian : With friends like these…. Un peu long, à prendre avec des pincettes je pense sur certains points, mais très intéressant pour nourrir la réflexion sur le cas de Facebook.

Je viens de découvrir OpenId via les prédictions de Fred Cavazza, et je suis plutôt satisfait et enthousiaste vu ce que cela apporte.

Il s’agit d’un système d’identification décentralisée à l’aide d’une URL où se trouve un serveur permettant de saisir son login et mot de passe. Concrêtement, je m’identifie en tant que kiad.org (je suis kiad.org !). Dans la section head de l’URL http://kiad.org se trouvent deux liens indiquant l’adresse du serveur d’identification. Ainsi, un service Web tiers peut me demander mon OpenId. Je suis alors redirigé vers l’URL du serveur où je saisis mon identifiant et mot de passe, puis redirigé à nouveau vers le service tiers. Simple comme bonjour.

Des services proposent de se créer un OpenId comme MyOpenId, et les plateformes de blog vont sûrement bientôt proposer ce service pour en simplifier encore l’utilisation. Pour les geeks, vous pouvez aussi installer votre propre serveur (j’utilise par exemple phpMyId).

À mon avis, cette techno est promise à un bel avenir. Plusieurs raisons à cela :

• suite à mes réflexions sur le contrôle de nos données personnelles, il me semble évident qu’avant d’imaginer un contrôle sur les données personnelles, il faut déjà disposer d’un système de contrôle de son identification.
• je ne supporte plus que des sites stockent mes mots de passe en clair, voire me les renvoient par mail comme si de rien n’était
• j’adore mémoriser des mots de passe compliqué de 8 caractères, j’en ai en permanence une demi-douzaine en utilisation. Mais j’en connais qui s’en porterait pas plus mal si il n’avait qu’un seul mot de passe à retenir pour toutes les utilisations de services Web. C’est ce que devrait permettre OpenId
• s’identifier personnellement à son URL est devenu presque naturel. Les blogs poussent à se construire une identité virtuelle, et l’URL est le meilleur moyen de la représenter
• OpenId peut permettre de résoudre le problème de l’usurpation d’identité, notamment dans les commentaires de blog par exemple

OpenId me semble être la techno qui va amorcer une vraie décentralisation des services Web. Si je contrôle mon identification, il ne sera plus très difficile de contrôler aussi les données personnelles que l’on souhaite communiquer. Et à partir du jour où ce ne seront plus les services Web qui contrôleront nos données, mais l’inverse, alors on pourra travailler à un Web décentralisée.

Reprenons l’exemple de last.fm, ce n’est pas excessivement compliqué en utilisant Amarok par exemple d’envoyer sur son site perso ses statistiques de musique. À partir de là, peut-on imaginer de reproduire de manière décentralisée, où chacun contrôle ses informations, les fonctionnalités de suggestions et de voisinages utilisateurs de last.fm ? Je ne pense pas que ce soit impossible.

Cela fait longtemps que j’en rêve (j’en parlais en 2004 à propos de la recherche), mais je suis persuadé qu’un jour on saura construire des last.fm ou des flickr complètement décentralisés, avec les mêmes fonctionnalités communautaires. Je ne crois pas à l’avenir des sites communautaires centralisés, du moins à long terme. Si on commence à vouloir contrôler son identité, on voudra contrôler nos données personnelles, puis nos services en ligne. Ça ne se fera peut-être pas rapidement, mais ça se fera. J’espère que ce sera ça le Web 3.0 !

Pour la première fois j’ai pu assister au Forum PHP organisé par l’AFUP (sauf jeudi après-midi hélas, rendez-vous important pour Olient, j’en reparlerai !). Dans l’ensemble je suis plutôt satisfait, les conférences étaient intéressantes ! C’est sympa de voir tant de gens connus (Rasmus Lerdorf, Zeev Suraski, Derick Rethans et Andrei Zmievski pour ne citer qu’eux). Voilà un petit résumé.

Rasmus et les performances

Tout d’abord, la conférence de Rasmus jeudi matin était excellente ! Le personnage est vraiment intéressant à écouter, ses slides très vivantes (sympa les démos utilisant flickr en live). J’ai adoré l’exercice consistant à réduire le nombre de serveurs sur son benchmark, très simplement en fait. Rasmus n’a qu’une chose en tête : les perfs. Les questions qui lui ont été posées à propos des frameworks ou solutions de templates étaient intéressantes de ce point de vue là. Concernant les templates, je m’attendais à sa réponse (PHP est une solution de template en soi), un peu moins concernant les frameworks. Il ne recommande pas l’usage d’un framework généraliste en l’état pour des raisons de performances. Deux solutions selon lui : soit vous écrivez le vôtre adapté pour votre projet, soit vous partez d’un framework et vous faites le ménage et l’optimisez pour votre projet.

Zeev et les chiffres

L’intervention de Zeev Suraski dans la conf pour Zend était intéressante aussi, notamment l’explication du récent accord entre Microsoft et Zend. Microsoft souhaite tout simplement qu’à défaut d’utiliser leur solution ASP/.net, vous utilisiez en production PHP sous Windows et IIS. Cela dit, le sondage à mains levées dans l’audience (~180 personnes) fut révélateur : la moitié utilise Windows pour développer en PHP, mais aucune main levée pour l’utilisation en production !

On notera que Zeev a soigneusement esquivé la question du taux de pénétration de PHP 5. Celui-ci tourne autour de 10% selon les stats de Nexen, ce qui est très loin d’être une réussite, je parlerais plutôt d’échec. Je suis étonné que personne n’évoque ce sujet : même dans les commentaires sur ces stats tout le monde semble satisfait. Sachant que PHP 5 est sorti il y a plus de deux ans, il y a de quoi se poser des questions. C’est d’autant plus inquiétant que de nombreux hébergeurs ont mis du temps à mettre en place PHP 5, et surtout beaucoup l’ont fait à moitié si j’ose dire, en mettant en place une extension .php5, ce qui ne facilite guère la migration (quelle regression par rapport au changement en .php lors de PHP4). Bref, au lieu de ça on eu droit au chiffre de 70% des nouveaux projets des clients de Zend écrits en PHP 5. Bon après tout, c’était une conférence décisionnelle et surtout commerciale.

Conflits de qualité !

L’autre conférence que j’ai adorée est celle de Miguel Lopez à propos de la qualité de code et de son outils PHP Meter. D’abord, car mon stage de 3e année à Thales était similaire, mais avec le langage Ada 95 et l’outil gnatmetric, et je trouve le sujet très intéressant. Ensuite, parceque le bonhomme assez atypique m’a bien fait rire pendant une heure. Mais au delà de ces détails, j’ai trouvé son propos très pertinent, surtout à propos des codes producteurs ou consommateurs en fonction de leur couplage. Il en résulte différents types d’architectures quand on analyse un projet, des projets à fort couplage type spaghettis pour reprendre son terme, au projet idéal en terme de génie logiciel avec un micro-kernel pour reprendre là aussi son image. Mais ce qui était vraiment intéressant, c’est qu’il n’était pas là pour dire que l’un était bien et l’autre mal ou que l’objet est mieux que le procédural. Non, le message qu’il voulait faire passer était qu’il y avait nécessairement des conflits de qualité, dans le sens où les projets peuvent avoir des objectifs différents et donc la manière de juger la qualité sera différente. J’ai trouvé le propos bien venu, surtout après la conférence et le discours très pragmatique de Rasmus sur les performances, et la présentation très orientée génie logiciel à propos des designs patterns en PHP5.

Et aussi….

Enfin, j’ai apprécié la présentation sur les tests unitaires, même si je n’ai pas trouvé les chiffres si impressionnants que ça finalement. Avec Vincent on se souvient qu’on avait plus de 1000 tests unitaires début 2005 sur hariCow (entre temps Equideo et Olient sont passés par là et il y a eu du laissez-aller, mais c’est une autre histoire…). Les 400 tests du Zend framework me semble donc pas exceptionnels. Par contre, j’ai été bluffé par la démo de couverture de code ligne par ligne avec XDebug. Il faut absolument qu’on essaye ça sur Equideo et hariCow !

Conférence sympa aussi sur ezComponents par Derick, j’aime bien le principe de composants utilisables séparément à sa guise, pas de framework ou de structure lourde derrière. J’en connais un que cela fait réfléchir…. Et enfin, conférence d’Andrei assez technique mais agréable à suivre à propos d’Unicode dans PHP 6. On voit bien que c’est un gros chantier, mais le résultat est très convaincant !

Voilà pour le tour d’horizon et mes impressions. Merci à l’AFUP pour l’organisation, c’était pas mal !

Suite à une discussion où on m’a encore sorti que PHP était un langage pour les étudiants/universitaires, j’ai ressorti les slides d’un ingénieur de Yahoo! qui présentait la migration de Yahoo vers les technos open-source.

C’est assez intéressant de voir les contraintes qu’ils ont, leur tour d’horizon des différentes technos envisageables et leurs critères de sélection, ainsi que l’évolution de leur architecture. Parmi les critères, je retiens entre autre l’apprentissage et la prise en main rapide et facile, ainsi que la communauté. J’ai le sentiment aussi que l’interfacage entre PHP et leurs applis C/C++ semble assez aisé, qu’en est-il avec d’autres langages comme Python ou Ruby ?

Cela dit cette présentation date de 2002, qu’en est-il aujourd’hui ? Eh bien le même ingénieur de chez Yahoo! a fait une présentation en 2006, faisant le point 4 ans après la migration. On y trouve entre autres des conseils sur PHP (performance, sécurité), un peu plus de détail sur leur architecture et un peu d’info sur un des apports majeur de PHP6, à savoir Unicode.

Cette semaine, on vient aussi d’apprendre que le nouveau Yahoo! Bookmarks utilise Symfony, un framework pour PHP 5 développé par une agence française qui semble être le plus proche de Ruby on Rails.

Vous me direz, il ne s’agit que de Yahoo!, mais tout de même cela reste un site de référence, on est loin du langage d’universitaire ou de pages persos ! Voilà qui rétablit un peu mon impression négative sur PHP ces derniers temps… Et pour alimenter le débat, rien de tel qu’un PHP Eats Rails for Breakfast

A défaut d’avoir eu un professeur digne de ce nom, je dois avouer que nos cours d’IHM l’année dernière nous ont sensibilisé sur ces problématiques axées autour de l’expérience de l’utilisateur (je rejoins Gmooron sur ce sujet). Quelques reflexions intéressantes à ce sujet ces derniers temps :

Vitres de voiture

On s’est retrouvé à débattre du sens des boutons de vitres électriques sur les portières. Lorsque ceux-ci sont horizontaux, vous parait-il plus logique de soulever ou d’appuyer sur le bouton pour faire monter la vitre. Il m’a toujours semblé cohérent de soulever pour monter la vitre, mais on m’a fait remarquer qu’il est beaucoup plus naturel d’appuyer que de soulever un bouton (tout comme on s’attend à pousser une porte de sortie et non la tirer). La question est restée ouverte, il semblerait que c’est surtout une question d’habitude entre les différentes marques…

Ajax et Web 2.0

Plusieurs refléxions à ce sujet avec Nicolas, à propos des nouvelles interfaces ajaxisées. A ce propos, le nouveau webmail de Yahoo! me plait beaucoup, bien plus que GMail. La page d’accueil personalisable proposée par Netvibes aussi. Ces trois services ont en point commun d’utiliser à fond AJAX et de proposer des interfaces nouvelles.

On lit d’ailleurs souvent qu’AJAX augmente l’expérience de l’utilisateur en apportant des interfaces bien plus riches que du classique HTML. Cependant, celui-ci a un avantage : c’est le même pour tout le monde ! Comprendre par là, les interfaces classiques à base de HTML sont uniformisées, dans le sens où lorsqu’on clique sur un lien, on s’attend à l’ouverture d’une nouvelle page (le grand débat il y a un an ou deux sur l’attribut target de la balise a est un exemple du souci d’uniformisation). Les internautes se sont habitués à ces interfaces, et le moins que l’on puisse dire, c’est que les nouvelles interfaces riches à base d’AJAX sont souvent non seulement déroutantes pour l’utilisateur labmda, mais surtout non uniformisées entre tous les services 2.0.

Exemple dans Netvibes que j’utilise au quotidien. Je n’ouvre jamais un billet directement dans Netvibes, car cela m’ouvre un nouveau widget Netvibes que je trouve vraiment déroutant, au point que 2 fois sur 3 je veux revenir à mon onglet de fils RSS en faisant Précédent, et du coup je perd tout le chargement de Netvibes (qui, il faut bien le dire, est assez long quand on a de nombreux fils). Au lieu de ça, j’ouvre les liens dans un nouvel onglet (aussi parceque j’apprécie de voir le site de l’auteur en lisant le billet). Et encore, je me considère comme un geek, mais je pense aux internautes non-informaticiens qui doivent complètement perdus sur ces interfaces : comprennent-ils la distinction entre une "fenêtre" dans la page Web et une fenêtre de leur système d’exploitation ? Je doute, cela porte vraiment à confusion.

Mon propos n’est pas de critiquer les interfaces en AJAX, car il y a clairement du bon. Par contre, il va clairement se faire sentir un besoin d’uniformisation, de la même manière que les interfaces des environnements graphiques sont relativements uniformisées, ou tendent à l’être (je pense à l’initiative Free Desktop par exemple, ou aux efforts entre Gnome et KDE).

Serveurs vocaux

Alors là, on atteint le summum en terme d’interface. Je parle des serveurs où on vous demande de parler à haute voie pour faire un choix dans le menu, plutôt que d’appuyer sur 1 pour telle action comme l’annonce classiquement la voix féminine. Sur France Télécom, vous aller devoir prononcer "déménagement" pour un changement de ligne. Alors comme vous avez pas envie de vous faire remarquer dans la rue ou dans les couloirs au boulot, vous le dites pas trop fort quand même, parcequ’on à l’air bête quand même à prononcer un mot dans le vide. Résultat : le serveur vous demande de répéter, et vous êtes obligé d’épeler "dé-mé-na-geu-ment" à haute voix. Du coup vous passez pour le dernier des idiots. Niveau expérience client, c’est réussi ! Je sais pas si cela se répand, mais j’ai du utiliser ces système pour France Télécom (1014) et le support Darty aussi. J’espère qu’ils se rendront compte de la gène occasionnée à l’utilisateur…

Suite au succès du jeu Equideo.com, Olient recrute des développeurs PHP 5 / MySQL pour le lancement de nouveaux jeux en ligne.

Profil recherché : bac+2/+4 ou plus, disposant d’une expérience professionnelle. Rigueur et sérieux sont indispensables pour cette application Web complexe mais riche et intéressante. La pratique d’un framework de développement Web et l’expérience d’un site à forte fréquentation sont des atouts.

Vous serez amené à travailler dans une équipe jeune et motivée. Le poste est à pourvoir
dès le 1er septembre, dans nos locaux à Gif sur Yvette (RER B, 1mn de la station Courcelle).

Contrat de type CDI, pour une rémunération de 24 k€ à 36 k€, à négocier. Merci d’envoyer vos CV et lettre de motivation au format PDF à
recrutement at olient point fr.

Olient est une jeune entreprise en forte croissance qui conçoit, développe et exploite des jeux en ligne d’une nouvelle génération. Plus d’info sur http://www.olient.fr

Le but de ce billet n’est pas de lister toutes les incohérences dans PHP, on s’en sortirait pas. Mais il y en a une qui m’a toujours dérangé. Et on m’a encore assuré cette semaine que c’était normal ! Je tairais le nom de la personne

Donc ce qui me gène, c’est la fonction isset. Je comprends pas qu’on passe à cette fonction une variable, alors que justement on veut en tester l’existence. Cela n’a pas de sens d’utiliser une variable ou un objet alors qu’on ne sait justement pas si cet objet ou cette variable existe. Cela reviendrait à écrire object.isset() pour savoir si object existe, alors que potentiellement on va appeler une méthode sur un objet qui n’existe pas…

Le comportement de la fonction define me semble à ce titre cohérent : on passe une chaine pour le nom de la constante à définir, et pas la constante directement, puisqu’elle n’est pas encore créée. Mon propos est donc que la fonction isset devrait prendre comme premier argument une chaine. Si on veut tester que la variable foo existe, on devrait écrire isset(’foo’).

J’en dormirais mieux la nuit….

Dimanche midi j’ai eu l’occasion de manger à Paris avec Leanne Markus, la tutrice de mon stage à Auckland en Nouvelle-Zélande. Ce fut l’occasion de discuter sur sa companie qui produit un logiciel de gestion de ressources humaines assez innovant, et de lui raconter où j’en suis de mon côté avec Olient et Equideo (elle attend impatiemment la version anglaise…).

La discussion en est venu au brevet qu’elle a obtenu pour son application, applicable en Nouvelle-Zélande notamment, en m’expliquant que ce brevet courait pour 20 ans. Et on est donc venu à parler propriété intellectuelle… Leanne m’expliquait alors qu’il lui avait fallu 5 ans pour développer le logiciel, et ensuite trouver les clients à qui le vendre, puisqu’elle vise les grands comptes. Plusieurs grosses companies néozélandaises l’utilisent, mais plus récemment c’est surtout l’hôpital de Singapour qui est venu compléter les références, ouvrant les portes de l’Asie du Sud-Est. Pour elle, le brevet est nécessaire vu toutes ces années d’efforts avant de commencer à en récolter les fruits.

J’ai quand même réussi à lui faire reconnaître que 20 ans, même dans son cas, c’est trop long, et que peut être 10 suffisent. Car c’est bien là (avec l’étendu) le point le plus important du brevet : la durée d’application. Reprenons depuis le début.

Le rôle d’un brevet est de favoriser l’innovation. La finalité, c’est l’innovation. La durée d’application n’est qu’un moyen pour atteindre cette finalité. En accordant un monopole limité dans le temps, le brevet doit inciter la personne à exploiter son innovation. Limité dans le temps, pour la simple et bonne raison que toute idée nouvelle est toujours plus ou moins basée sur une idée déjà existante. Si le brevet est trop long, il nuit à l’innovation en empêchant d’autres innovateurs d’améliorer l’idée originale. Si il est trop court, le créateur n’aura pas assez d’assurance qu’il arrivera à vivre de son innovation avant d’être à la merci de concurrents. Toute l’efficacité d’un brevet pour favoriser l’innovation et l’intérêt général réside dans la juste mesure de sa durée.

Leanne me disait donc qu’on aurait tout intérêt à protéger notre concept de jeu en ligne. Ce que ne cesse de me répéter ma mère, qui a peur qu’on nous vole notre idée. Et ce à quoi je réponds : "mais nous aussi on a commençé en repiquant le concept à quelqu’un d’autres !". Le concept de jeu en ligne existait depuis longtemps, et nous avons repris celui du jeu d’élevage de chevaux. Nous l’avons considérablement amélioré, tant le jeu que le modèle économique, preuve en est la réussite d’Olient. Et si quelqu’un venait à faire mieux que nous, je considère que ce serait à nous de reprendre au mieux son amélioration, et de faire à nouveau mieux que lui. C’est le jeu, saine émulation.

Je ne peux pas dire objectivement qu’on aurait eu besoin d’un brevet sur 20 ans. D’autant plus que je ne considère pas vraiment un brevet trop long comme une aide pour l’entreprise, les ardents défenseurs d’une propriété intellectuelle très forte étant souvent ceux qui ont un intérêt à se reposer sur leur laurier et relacher l’effort…

Cependant, si la durée était suffisament courte, je pense qu’un brevet logiciel sur un concept pour le Web pourrait être utile pour inciter plus de monde à se lancer dans l’aventure. A mon avis, une durée de 6 mois à 1 an maximum pourrait être bénéfique pour les innovateurs qui seraient assurés qu’on leur laisse quelques mois pour faire leurs preuves. Ce n’est pas de trop pour lancer un site ou un service sur le Web. Mais le Web évolue tellement vite, trop vite pour accepter des verrous sur certains concepts pendant plusieurs mois. Ce qu’on gagnerait en initiatives d’un côté qui ne serait pas parues sans l’incentive d’un brevet, on le perdrait largement de l’autre : alors que chaque semaine apparait un nouveau service innovant sur le Web, cette durée serait probablement rallongée à quelques mois… Et si le Web était la preuve que le monde des idées n’a pas besoin d’une forte propriété intellectuelle ? Vraiment, je pense que c’est un précieux équilibre qu’il ne faut surtout pas bouleverser avec ce genre de mécanisme qui, si il s’avère efficace dans le monde réel (personne n’a remis cela en question), pourrait s’avérer dévastateur sur le Web.

Alors qu’on commence le développement d’un nouveau jeu en ligne, j’ai décidé de reprendre les bonnes habitudes : on fait des tests unitaires ! Et pas après avoir codé, avant !

Si il y a un truc que j’ai retenu de mon expérience du Test Driven Development, c’est qu’il faut jamais arrêter. C’est dur de s’y remettre après, voir impossible sur un même projet. Sur Equideo, pris par le temps on avait décidé de ne pas en faire, et je pense qu’il y en aura jamais maintenant.

L’argument du temps revient souvent… En fait je me rend compte qu’il est surement moins important que ce qu’on pense. Les tests, au début on a l’impression que ça va nous prendre deux fois plus de temps (écrire le code, et les tests qui vont avec). Ce qui est pas loin d’être faux. Mais si on y regarde bien, de toute manière on est très souvent obligé de passer du temps à tester, de manière informel. Qui plus est, quand on accumule les fonctionnalités, il faut retester les anciens codes, vérifier qu’on a rien cassé. Avec une batterie de tests unitaires, on vérifie très simplement que tout fonctionne.

Vient le temps de la mise en production. Et c’est là qu’on apprécie le plus les tests unitaires : à chaque modification, vous pouvez vous assurer tout aussi aisément que vous n’avez rien cassé ailleurs. Au final, entre le temps gagné à ne pas tester en bricolant de manière informel, et vu le gain en confiance lors de changement sur le site en production, je pense qu’on a largement regagné le surplus d’effort initial.

Le jeu qu’on prépare se prête assez bien aux tests unitaires, donc le choix est vite vu, je pense pas que je le regretterai.

Pour ceux que ça intéresse, j’avais écrit un petit papier sur les tests unitaires.

J’ai fini de lire le livre The Innovator’s Dilemma de Clayton Christansen dont je parlais il y a quelques temps. J’y abordais le secteur de la téléphonie via Internet. Mon avis s’est trouvé conforté à la lecture de ce bouquin. Et ce n’est pas les dernières nouvelles de Free et Neuf Cegetel annoncant des communications gratuites vers la plupart des pays d’Europe, d’Amérique du Nord ou meme d’Asie qui vont me faire changer d’avis.

Mais ce n’est pas cet exemple auquel j’ai immédiatement pensé après avoir fini le livre. C’est la situation de MySQL sur le marché des bases de données qui m’est venue à l’esprit. C’est frappant à quel point l’émergence de MySQL rentre exactement dans le schéma que décrit Christansen à propos des innovations dites disruptives.

Pourtant, on ne peut pas dire que MySQL soit une révolution technique en soit dans le domaine des bases de données. En fait, dans les exemples que donne Christansen, on trouve bien sûr des vrais révolutions techniques (dans le domaines aussi variés que les différentes tailles de disques dur, les pelleteuses à cable vs hydrauliques ou le commerce de détail vs la grande distribution), mais on trouve aussi un certain nombre d’innovations qui sont en fait des simplifications de l’offre du marché. C’est dans cette catégorie que je range MySQL. Alors, ça marche comment ?

Typiquement, ça commence avec un produit simplifié et moins cher. Exactement ce qu’était MySQL 3. Imaginez, une base de données sans vues, sans clefs étrangères, sans procédures stockées, qui aurait voulu faire tourner une entreprise avec ça ? Probablement aucun ou peu d’utilisateurs d’Oracle ou de SQL Server n’était intéressé quand MySQL est apparu sur le marché. Mais MySQL avait déjà d’autres qualités : le prix (en l’occurence, la gratuité), la simplicité et le peu de ressources nécessaires pour faire tourner le serveur. Exactement ce dont avait besoin le marché des petits et moyens sites Web lorsque les sites "dynamiques" ont émergé et sont devenus légions.

C’est là un des points importants du livre. Beaucoup d’innovations disruptives commencent dans des petits marchés à part du marché principal, les deux ayant deux visions différentes des qualités nécessaires pour un SGBD afin d’etre utilisable. Ici, le marché des sites Web et celui des gros comptes clients d’Oracle ou de SQL Server ont clairement des besoins différents, et ce que eux jugent comme des défauts est exactement ce pourquoi le marché des sites Web apprécie MySQL. Chaque marché à ses propres valeurs et dans le schéma que décrit The Innovators Dilemma, le marché principal et le marché restreint dans lequel évolue au début l’innovation disruptive ont souvent des valeurs diametralement opposées : ce que l’un juge comme un défaut est jugé comme une qualité par l’autre.

Ces différences de valeurs sont très importantes, et dangereuses pour les leaders du marché. Car c’est justement en appliquant les meilleurs techniques de management, à savoir surtout en écoutant de très près et en suivant ce que leurs disent leurs clients qu’ils ratent ce genre d’innovations, puisque ces clients en général jugent comme des défauts ce qui fait la force de ces innovations. La stratégie de défense du leader est donc souvent de continuer à écouter leurs clients et de compléter leurs produits en fonctionnalité.

Comment la situation évolue alors pour passer d’un marché restreint dans lequel évolue MySQL à un statut de leader ? L’explication que livre Christansen se base sur l’étude des courbes de fonctionnalités de l’innovateur (A), de la demande du globale du marché (B) et des leaders (C). Deux conditions sont alors nécessaires pour qu’un petit innovateur vienne renverser les leaders :
- la courbe A progresse plus vite que la courbe B,
- la courbe C évolue au dessus de la courbe B.

C’est éxactement ce qui se passe ici :
- MySQL a considérablement rattrapé son retard avec les versions 4 et 5, rejoignant ce qu’attend le marché comme standard pour un SGBD (vues, procédures stockées, clefs étrangères entre autre)
- Oracle est probablement dans une situation où leur produit surpasse de loin ce qui est demandé par le marché de manière globale, ne satisfaisant efficacement qu’une petite partie du marché, les très grands comptes. Ce faisant, ils glissent vers le haut du marché, laissant un vide où MySQL peut s’engouffrer et sortir de son marché niche.

Pourquoi Oracle ne s’est-il pas lançé sur le marché qu’occupait MySQL dès le départ ? Probablement, comme l’explique le livre, qu’il s’agissait d’un marché trop petit pour répondre à ses besoins de croissance, en plus du fait qu’il répondait à un système de valeurs complètement différent. Une bonne partie du livre s’attache à expliquer comment gérer au sein de l’organisation ces différences de valeurs.

Le jeu se termine quand la courbe A croise la courbe B. Celui qu’on considérait comme un petit est alors en mesure d’innonder le marché principal et de combattre les leaders. Ces derniers se retrouvent alors au pied du mur : soit ils continuent à se déplacer dans le haut du marché (et bien souvent c’est la porte de sortie), soit ils arrivent à descendre dans le marché, exercice très difficile même si l’entreprise en a les ressources, car cela implique un changement profond dans les valeurs de l’organisation.

Mon interrogation est donc de savoir si MySQL 5 n’est pas le produit qui vient croiser la demande du marché, car en terme de fonctionnalité, il semblerait bien que ce soit le cas. L’autre indice qui me fait penser cela, est la sortie par les grands éditeurs de version light de leur produit afin de contrer MySQL, comme le signale Nexen. Cela sonne comme un aveu que MySQL répond à la demande de leur marché à eux et qu’il est temps de réagir. L’avenir nous dira si leurs réactions est trop tardive ou pas…