Amazon, Google, Facebook : l’art de la guerre à l’âge de la multitude

J’ai traduit, à l’attention des lecteurs de ce blog, un texte lumineux de Steve Yegge sur les stratégies de plateforme. Comme nous le relatons dans L’Âge de la multitude (p. 133),

Le 11 octobre 2011, Steve Yegge, ingénieur informatique, ancien collaborateur d’Amazon désormais employé par Google, publiait par erreur sur son compte Google+ un billet passé depuis à la postérité sous le titre Stevey’s Google Platforms Rant – ou « La harangue de Stevey sur Google et les plateformes ». Vite retiré par son auteur, dont l’intention n’était que de haranguer ses collègues chez Google et non le monde entier, le billet est néanmoins demeuré accessible à tous car il avait entretemps été reproduit et partagé par des centaines d’experts et de développeurs, instantanément passionnés par la discussion ébauchée.

Le texte de Steve Yegge, apparemment une discussion pointue d’architecture logicielle (…), est en réalité une lumineuse leçon de stratégie industrielle. Il nous permet de mieux comprendre comment, à partir d’une exécution parfaite du geste du designer, une stratégie adaptée permet d’établir durablement une position dominante sur tout un marché. »

Le texte de Steve Yegge a été pour moi une révélation. Il éclaire de façon limpide les stratégies respectives de Google, Amazon, Facebook, Apple et Microsoft. Il permet de deviner les règles d’engagement que suivent ces champions du numérique pour défendre leurs invraisemblables positions sur des marchés gigantesques.

Il nous introduit surtout à la notion de plateforme : une notion qui fait écho à des débats déjà anciens dans le secteur de l’informatique, mais qui prend une nouvelle dimension à l’heure où des applications s’étendent à un marché trop large pour pouvoir continuer à séduire toute la multitude. Ce point au-delà duquel tous les utilisateurs ne peuvent plus être servis par une seule application, c’est celui que choisissent ces entreprises pour devenir des plateformes, pour mettre leurs ressources à la disposition des tiers afin que se multiplient les applications.

Facebook est une plateforme, Zynga et bien d’autres, comme nos amis de Tigerlily, développent des applications par dessus cette plateforme. Amazon est une plateforme, d’innombrables vendeurs peuvent venir y présenter leurs produits et des milliers d’entreprises utilisent ses ressources de cloud computing. L’iPhone est une plateforme, des centaines de milliers d’applications sont proposées dans l’App Store sans qu’Apple n’ait eu à financer leur développement. Aujourd’hui, la notion de plateforme commence à émerger dans le secteur du conseil. Demain, elle servira pour restructurer nos vieilles industries et les adapter, enfin, à la nouvelle donne : celle d’après la révolution numérique.

Voici le texte de Steve Yegge. L’original en anglais est consultable en suivant ce lien. Nous vous en proposons ci-dessous la traduction, assez libre, en français (les soulignés sont de moi).

J’ai travaillé six ans et demi chez Amazon. J’ai maintenant la même ancienneté chez Google. Une chose m’a immédiatement frappé à propos de ces deux entreprises et cette impression n’a fait que se renforcer de jour en jour : Amazon fait tout mal et Google fait tout bien. Bien sûr, c’est une généralisation abusive. Elle n’en reste pas moins vraie. C’est frappant. Probablement y a-t-il à peu près une centaine de manières différentes de comparer les deux entreprises : Google est supérieure à tous points de vue à l’exception de trois, si je ne m’abuse. J’ai même réalisé un jour une feuille de calcul à ce sujet, mais le service juridique de Google m’a interdit de la montrer à qui que ce soit – en revanche, le service des ressources humaines l’a adorée.

Pour vous donner ne serait-ce qu’un aperçu : le processus de recrutement d’Amazon est fondamentalement vicié par le fait que chaque équipe recrute elle-même ses propres collaborateurs, de sorte que les exigences de recrutement sont incroyablement hétérogènes d’une équipe à l’autre, malgré divers efforts pour harmoniser tout cela. La conduite des opérations est chaotique : il n’y a pas de services généraux chez Amazon et les ingénieurs doivent tout faire eux-mêmes, ce qui ne leur laisse quasiment pas de temps pour programmer – même si, à nouveau, la situation est différente d’une équipe à l’autre, donc c’est au petit bonheur la chance. Amazon n’a que faire des oeuvres de charité, de l’aide aux plus démunis, de la vie de la communauté ou de quoi que ce soit de cet ordre.  Il n’est jamais question de ça chez Amazon, sauf peut-être pour s’en moquer. Leurs installations sont des entrepôts cubiques maculés de poussière, sans aucun moyen alloué à la décoration ou à des espaces collectifs agréables. Les salaires sont bas, les avantages sociaux inexistants, bien que des progrès aient été faits récemment du fait de la concurrence avec Google et Facebook sur le marché du travail. Mais les gens d’Amazon n’ont rien qui ressemble à nos avantages en nature ou autres bénéfices – Amazon se contente de payer à peu près autant que ses concurrents, rien de plus. Enfin, le code informatique chez Amazon est un désastre, aucun standard de qualité ne s’applique à l’ingénierie, sauf si une équipe décide de s’en doter elle-même.

Pour être honnête, Amazon a quand même un système sympathique de gestion des versions de bibliothèques logicielles que nous ferions bien d’imiter, ainsi qu’un système tout aussi sympathique de publication et d’abonnement dont il n’existe pas d’équivalent chez Google. Mais, pour l’essentiel, l’informatique d’Amazon, ce ne sont que quelques outils de piètre qualité qui permettent de lire et écrire des informations relatives aux états des systèmes dans des bases de données relationnelles. Nous n’utiliserions aucun de ces outils ici chez Google, même s’ils étaient gratuits.

Je pense que le système de publication et d’abonnement et le système de gestion des versions sont deux parmi les trois choses qu’Amazon fait mieux que Google.

Evidemment, vous pourriez faire valoir que l’approche consistant à lancer vite et à itérer comme des fous est aussi quelque chose qu’Amazon fait bien. Mais la médaille a son revers. Chez Amazon, lancer vite est une priorité par rapport à tout le reste, y compris retenir les meilleurs éléments, imposer une discipline aux ingénieurs ou tout un tas d’autres choses qui sont importantes sur le long terme. Du coup, même si cela leur a donné un avantage comparatif sur le marché, le fait de lancer vite leur a causé suffisamment d’autres problèmes pour nous inspirer des conclusions pour le moins mitigées.

Tout cela étant dit, il y a une chose qu’Amazon fait très bien et qui rattrape à peu près tous leurs errements politiques, philosophiques et techniques.

Jeff Bezos est un micro-manager notoire. Il micro-manage chaque pixel du site Web de vente de détail d’Amazon. Il a recruté Larry Tesler, le scientifique en chef d’Apple et probablement le plus connu et le plus respecté des spécialistes des interactions homme-machine du monde entier, puis il a méthodiquement ignoré chacun des conseils que Larry lui a donnés pendant trois ans, jusqu’à ce que Larry, finalement – et sagement –, quitte la société. Larry réalisait ces études ergonomiques détaillées et démontrait sans l’ombre d’un doute que personne ne comprenait rien au foutu site Web d’Amazon. Pourtant Bezos ne cédait rien sur ces pixels, ces millions de pixels chargés de sémantique sur la page d’atterrissage d’Amazon. Ces millions de pixels étaient comme ses enfants. Ils sont donc toujours là – et Larry, lui, est parti.

Je précise que le micro-management n’est pas la troisième chose qu’Amazon fait mieux que Google. Evidemment, ils micro-managent très bien chez Amazon, aucun doute là-dessus. Mais je ne considérerais pas cela comme une force. Je suis juste en train de poser le contexte, de vous aider à comprendre ce qui s’est passé. Il est question d’un type, Jeff Bezos, qui a déclaré sérieusement, lors de nombreuses prises de parole en public, qu’il devrait être payé pour travailler chez Amazon. Il distribue sans cesse des petits autocollants jaunes avec son nom dessus pour rappeler aux gens « qui dirige la société » quand ils ne sont pas d’accord avec lui. Ce type est une sorte de… Steve Jobs, j’imagine. Sauf qu’il n’a aucun sens ni de la mode ni du design. Bezos est très intelligent, comprenez-moi bien. Son problème est que, comparés à lui, les autres obsédés du contrôle ressemblent à des hippies sous LSD.

Donc, un jour, Jeff Bezos a édicté un ordre. Il fait ça tout le temps, bien sûr, et les gens s’activent alors comme des fourmis après un coup de pied dans leur fourmilière. Mais, en une occasion, vers 2002 il me semble (ou 2003), il a édicté un ordre qui était si fort, si retentissant, si massif que tous ses ordres passés ressemblaient à de gentilles suppliques.

Les termes de cet « ordre de tous les ordres » étaient à peu près les suivants :

  1. Toutes les équipes exposeront dorénavant leurs données et fonctionnalités par l’intermédiaire d’API.
  2. Les équipes ont l’obligation de communiquer les unes avec les autres à travers ces API.
  3. Aucun autre mode de communication entre équipes ne sera autorisé. Pas de liens directs, pas d’accès direct en lecture à l’entrepôt de données d’une autre équipe, pas de modèle de partage de mémoire, aucune porte dérobée d’aucune sorte. La seule communication autorisée est à travers des appels à ces API via le réseau.
  4. Peu importe la technologie utilisée. HTTP, Corba, Pubsub, protocoles spécifiques – peu importe, Bezos n’a que faire de cela.
  5. Toutes les API, sans aucune exception, doivent être conçues dès le départ pour être rendues accessibles de l’extérieur. Cela signifie que chaque équipe doit planifier et concevoir de façon à pouvoir exposer son API à des développeurs du monde extérieur. Aucune exception ne sera tolérée.
  6. Quiconque ne se conformera pas à ces ordres sera renvoyé.
  7. Merci, bonne journée !

Ah ah ! Vous autres, les quelque 150 employés de Google qui avez travaillé chez Amazon par le passé, savez très bien que le point 7 est une petite plaisanterie de mon fait : Bezos se fiche complètement de votre journée.

Le point 6, en revanche, était si vrai que tout le monde s’est mis au travail. Bezos avait désigné quelques chiens de garde pour superviser l’effort et s’assurer des progrès, eux-mêmes supervisés par le chien de garde en chef Rick Dalzell. Rick est un ancien ranger de l’armée de terre, diplômé de la West Point Academy, ancien boxeur, ancien bourreau en chef / CIO chez Wal*Mart. Un type à la fois chaleureux et effrayant, allant et répétant sans cesse le mot « interface renforcée ». Rick était lui-même une interface renforcée marchant et douée de parole, donc vous imaginez bien que tout le monde fit BEAUCOUP de progrès et s’assura que Rick en était bien informé.

Dans les quelques années qui ont suivi, Amazon s’est transformée en une architecture orientée services. Ils ont beaucoup appris en menant à bien cette transformation. Il existait beaucoup de documentation et de préceptes à propos des architectures orientées services, mais exploiter tout cela chez Amazon était aussi vain que de demander à Indiana Jones de regarder de chaque côté avant de traverser la route. Les équipes de développement d’Amazon ont appris beaucoup de leçons tout au long du chemin. Voici un petit échantillon de ces leçons :

  • L’acheminement est compliqué, car une information peut rebondir au fil de 20 appels de service avant que son destinataire ne soit identifié. Si chaque rebond immobilise l’information pendant 15 minutes, il peut se passer des heures avant que la bonne équipe reçoive l’information, à moins de mettre en place beaucoup d’optimisation, d’indicateurs et de rapports d’activité.
  • Chaque autre équipe dans l’organisation devient potentiellement aussi nuisible qu’un DOS attacker. Aucun progrès ne peut être accompli à moins de mettre en place des quotas et des goulets d’étranglement au sein de chaque service.
  • Le suivi et la démarche qualité finissent par se confondre. Impossible de s’en rendre compte à moins de déployer une grande architecture orientée services. Quand une API déclare « tout va bien », il est possible que la seule chose qui fonctionne sur le serveur soit ce petit composant programmé pour déclarer que « tout va bien, c’est à vous », avec sa petite voix enjouée de robot. Pour s’assurer que l’API est bien opérationnelle, il faut lui formuler chaque appel individuellement. Le problème devient récursif à moins que le système de suivi soit capable de réaliser une vérification sémantique exhaustive sur tout le périmètre des données et des services. A ce point, le suivi devient impossible à distinguer de la démarche qualité. Il y a donc un continuum.
  • S’il existe des centaines d’API, et que votre code doit communiquer avec le code des autres équipes par l’intermédiaire de ces API, alors il est impossible de les trouver sans un mécanisme de recensement des autres API. Et il est impossible de disposer de ce mécanisme sans un autre mécanisme de déclaration de chaque API, qui est lui-même une API ! Donc Amazon a mis en place une API universelle de déclaration et de recensement qui vous permet d’accéder à la liste de tous les autres services, de leurs API, de leur état, de leur localisation.
  • Corriger des bugs dans du code est beaucoup plus dur si ce code a été partiellement développé par d’autres – c’est même impossible à moins de disposer d’un standard universel pour accéder à un bac à sable pour la correction de bugs.

Il ne s’agit que d’un aperçu pour fixer les idées. Tout au long du chantier, Amazon a mis à jour des dizaines, peut-être des centaines de leçons qu’il a fallu apprendre et intégrer. Certaines, relatives à l’externalisation d’API, confinaient au délire – mais pas autant que vous pouvez le penser. S’organiser en API a appris aux équipes à se vouer une défiance mutuelle supérieure encore à celle qu’ils éprouvent envers les développeurs de l’extérieur.

L’effort de transformation était toujours en cours quand j’ai quitté Amazon pour rejoindre Google à la mi-2005, mais il était bien avancé. Entre le moment où Bezos a édicté son ordre et le moment où j’ai quitté la société, Amazon s’était transformée culturellement en une entreprise qui pense tout en termes d’API. Les API sont maintenant au fondement de tous leurs travaux de conception, y compris pour des chantiers internes qui ne seront probablement jamais accessibles de l’extérieur.

Au point où ils en sont maintenant, les gens ne font plus des API par crainte d’être renvoyés. Bien sûr, ils craignent toujours d’être renvoyés, ça fait partie du quotidien là-bas, puisqu’on y travaille pour le grand méchant Bezos, etc. Mais à présent, ils font des API parce qu’ils ont compris que c’était LA chose à faire. Il y a bien sûr des avantages et des inconvénients à opter pour une architecture orientée services, et certains inconvénients ne sont pas une mince affaire. Mais dans l’ensemble, c’est la chose à faire car seule l’option pour une architecture orientée services permet d’opérer des plateformes.

C’est bien sûr ce que Bezos avait en tête quand il a édicté son ordre. Il n’avait et n’a toujours que faire du bien être de ses équipes, des technologies utilisées, ni d’aucun détail de quelque sorte que ce soit sur la façon dont elles conduisent leurs activités – sauf si elles donnent l’impression d’échouer sur toute la ligne. En revanche, Bezos a réalisé bien avant la majorité de ses collaborateurs qu’Amazon devait devenir une plateforme.

Vous ne penseriez pas, vous, qu’une librairie en ligne doit devenir une plateforme logicielle universelle et programmable. Le penseriez-vous ?

Eh bien, la première chose qu’a réalisée Bezos est que l’infrastructure qu’Amazon, construite pour vendre et expédier des livres et autres, pouvait être transformée en une plateforme logicielle servant bien d’autres activités. C’est pourquoi Amazon propose à présent des services aussi divers qu’Amazon Elastic Compute Cloud, Amazon Elastic MapReduce, Amazon Relational Database Service et tout un tas d’autres services que vous pouvez découvrir sur aws.amazon.com. Ces services hébergent l’infrastructure de nombreuses entreprises couronnées de succès – reddit est celle que je préfère.

L’autre chose qu’a réalisée Bezos est qu’il lui était impossible d’avoir toujours raison. Je pense que Larry Tesler a touché un point sensible chez Bezos quand il lui a dit que sa mère ne savait pas utiliser ce maudit site Web d’Amazon. Personne n’a bien compris de quelle mère il parlait, et cela n’a aucune importance, parce qu’aucune mère au monde ne sait utiliser ce maudit site Web. Moi-même, je trouve qu’utiliser ce site est intimidant, pourtant j’ai travaillé là-bas pendant plus de cinq ans. J’ai juste appris à cesser de fixer le site du regard et à me concentrer sur les quelques millions de pixels au centre de la moitié supérieure de la page.

Je ne suis pas certain de la façon dont Bezos a fini par réaliser cela – l’idée selon laquelle il lui est impossible de concevoir une application et que celle-ci plaise à chacun. Mais peu importe, car il y est parvenu. Il y a d’ailleurs un mot pour désigner ce phénomène : on appelle ça l’accessibilité, et c’est probablement la chose la plus importante dans le monde de l’informatique.

La chose la plus importante !

Vous pensez sûrement, comme beaucoup d’autres, à l’accessibilité pour les personnes aveugles ou malentendantes. J’ai fini par comprendre qu’il y a beaucoup de gens comme vous : des gens pour lesquels cette idée d’accessibilité est inaccessible, elle n’est donc pas encore parvenue jusqu’à vous. Ce n’est pas votre faute, ce n’est pas que vous ne puissiez pas comprendre, de même qu’il ne serait pas votre faute d’être aveugle ou malentendant ou handicapé moteur ou affecté d’un quelconque autre handicap. Quand un logiciel – ou une idée, puisque c’est ce dont il s’agit – échoue à être accessible à quelqu’un pour quelque raison que ce soit, c’est de la faute du logiciel ou du porteur du message. C’est un problème d’accessibilité.

Comme toutes les grandes choses importantes en ce monde, l’accessibilité a un double maléfique qui, parce qu’il a moins été aimé par ses parents dans son enfance, a grandi jusqu’à devenir une puissante Nemesis : ce double maléfique, c’est la sécurité. Mon Dieu, comme elles s’opposent ces deux-là, l’accessibilité et la sécurité !

Mais pour ma part je défends l’idée selon laquelle l’accessibilité est dans les faits plus importante que la sécurité. Annuler l’accessibilité veut dire que vous n’avez plus d’application du tout, tandis qu’annuler la sécurité vous laisse avec une application à peu près satisfaisante, ainsi du réseau PlayStation.

Donc oui. Au cas  où vous n’auriez pas remarqué, je pourrais écrire un livre entier à ce sujet. Un gros livre, bourré d’anecdotes amusantes à propos des fourmis et des coups de pied dans la fourmilière dans toutes les sociétés où j’ai travaillé. Mais je ne publierai jamais cette harangue, et vous ne la lirez pas, si je ne commence pas par conclure celle-ci.

La dernière chose que Google fait moins bien qu’Amazon, ce sont les plateformes. Nous ne comprenons pas les plateformes. Nous ne les saisissons pas. Certains d’entre vous le font, mais vous êtes la minorité. J’ai réalisé cela non sans douleur au long des six dernières années. J’espérais que la pression concurrentielle de Microsoft, d’Amazon et, plus récemment, de Facebook provoquerait une prise de conscience collective et nous inciterait à réaliser des API universelles. Non à notre façon, ni avec modération, mais de la même façon qu’Amazon : d’un coup, pour de vrai, sans tricher, en faisant de ce chantier notre priorité numéro 1.

Mais non. Non, c’est notre priorité numéro 10 ou 11. Ou numéro 15, je ne sais pas trop. Loin du numéro 1 en tout cas. Il y a quelques équipes ici qui prennent cette idée très au sérieux, mais la plupart des équipes soit n’y pensent pas, jamais, soit y pensent un tout petit peu.

C’est déjà beaucoup d’obtenir de la majorité des équipes une API rudimentaire ménageant un accès à leurs données et à quelques ressources logicielles. Nombre d’entre elles pensent qu’elles développent des applications. Et une API rudimentaire est assez pathétique. Lisez plus haut, regardez la liste des leçons apprises par Amazon dans sa grande transformation, et dites-moi à laquelle de ces leçons votre API rudimentaire vous permet directement de parvenir. En ce qui me concerne, c’est zéro. Une API rudimentaire, c’est bien, mais c’est comme un ensemble de pièces détachées quand vous avez besoin d’une voiture.

Une application n’a aucune utilité sans une plateforme. Ou, pour être exact et plus précis, une application sans plateforme sera toujours supplantée par une application similaire adossée à une plateforme.

Google+ est un exemple éloquent de notre échec total dans la compréhension des plateformes, depuis le sommet de l’organisation (salut Larry, Sergey, Eric, Vic, ça va ?) jusqu’au plus modeste de ses collaborateurs (salut toi). Aucun d’entre nous ne saisit les plateformes. La règle d’or des plateformes, c’est « Mangez comme votre chien« . La plateforme Google+ est un pathétique rattrapage. Nous n’avions pas d’API du tout lorsque Google+ a été lancé. La dernière fois que j’ai vérifié, nous ne proposions qu’un unique pauvre appel API. L’une des membres de l’équipe est venue et me l’a mentionné quand ils ont lancé Google+. J’ai demandé : « Est-ce l’API pour espionner les autres ? ». Confuse, elle m’a dit « Oui ». Bien sûr, moi je plaisantais, mais non ce n’était pas une plaisanterie… le seul et unique appel API proposé par Google+ était bien celui pour accéder au fil de quelqu’un d’autre. Donc j’ai dû garder ma plaisanterie pour moi.

Microsoft connaît la règle de la nourriture pour chiens depuis au moins vingt ans. Elle fait maintenant partie de leur culture depuis une génération. Vous ne devez pas vous réserver la bonne nourriture pour humains et donner aux développeurs de l’extérieur de la nourriture pour chiens. Faire cela, c’est faire une croix sur la valeur de long terme que crée une plateforme pour privilégier des succès de court terme. Les plateformes, c’est de la pensée sur le long terme.

Google+ est une réaction de faiblesse, un exemple éloquent de pensée de court terme, fondé sur l’idée erronée selon laquelle Facebook a du succès parce qu’ils ont réalisé une belle application. Or ce n’est pas la raison pour laquelle ils ont du succès. Facebook a du succès parce qu’ils ont réalisé une constellation d’applications en laissant les autres faire le travail. De sorte que Facebook est différent pour chaque utilisateur. Certains passent leur temps sur Mafia Wars. D’autres passent leur temps sur Farmville. Sur Facebook, il y a des centaines, peut-être des milliers d’agréables façons de perdre son temps. Chacun y trouve son compte.

Notre équipe Google+ a jeté un oeil sur le marché et s’est dit : « Mon Dieu, il semble qu’il faille proposer des jeux dans Google+. Trouvons vite un sous-traitant qui pourra développer quelques jeux pour nous. » Commencez-vous à comprendre à quel point cette vision est incroyablement erronée ? Nous sommes en train d’essayer de prédire ce que les gens veulent et de le réaliser pour eux.

Or c’est impossible. Impossible de le faire vraiment. Impossible de le faire de façon fiable. Il y a eu quelques personnes dans le monde, dans toute l’histoire de l’informatique, qui ont réussi à le faire de façon fiable. Steve Jobs était l’une d’entre elles. Nous n’avons pas de Steve Jobs ici chez Google. Je suis désolé, mais nous n’en avons pas.

Larry Tesler pourrait avoir convaincu Bezos qu’il n’était pas Steve Jobs. Mais Bezos a réalisé tout seul qu’il n’avait pas besoin d’être Steve Jobs pour proposer la bonne application à chacun – des interfaces et des activités que chacun aime et avec lesquels chacun se sent à l’aise. Il lui était juste nécessaire de donner à des développeurs tiers les moyens de faire ces applications, et tout s’enchaînerait automatiquement.

Je m’excuse auprès de ceux d’entre vous pour qui tout ce que je raconte est incroyablement évident, car, oui, c’est incroyablement, abominablement évident. Sauf que ce n’est pas ce que nous faisons. Nous ne comprenons pas les plateformes, nous ne comprenons pas l’accessibilité. Les deux signifient la même chose, parce que les plateformes résolvent l’accessibilité. Une plateforme, c’est l’accessibilité.

Donc, oui, Microsoft l’a compris. Et vous savez aussi bien que moi à quel point c’est surprenant, parce qu’ils ne comprennent pas grand chose, vraiment pas grand chose. Mais ils comprennent les plateformes : c’est la conséquence fortuite d’avoir amorcé leur activité, à l’époque, comme fournisseur de plateformes. Donc ils ont trente ans voire plus d’apprentissage dans ce domaine. Et si vous allez sur msdn.com, que vous passez un peu de temps à explorer et que vous n’y êtes encore jamais allés, préparez-vous à être émerveillés. Car c’est absolument spectaculaire. Ils proposent des milliers, des milliers et des MILLIERS d’appels API. Microsoft est une immense plateforme. Trop grande, en réalité, car ils n’arrivent pas à la maintenir. Mais au moins ils l’ont faite.

Amazon l’a compris aussi. Amazon Web Services (aws.amazon.com) est incroyable. Allez y jeter un oeil. Cliquez ici et là. C’est embarrassant. Nous n’avons rien de tel ici.

Apple l’a compris, sans aucun doute. Ils ont fait des choix fondamentaux de fermeture, notamment sur leur plateforme mobile. Mais ils comprennent l’accessibilité et ils comprennent la puissance des développements faits par des tiers et ils mangent comme leurs chiens. Et vous savez quoi ? Leur nourriture pour chiens est assez bonne. Leurs API sont infiniment plus propres que celles de Microsoft, depuis très longtemps.

Facebook l’a compris. C’est ce qui me préoccupe. C’est ce qui m’a fait sortir de ma torpeur pour écrire tout cela. Je déteste blogguer. Je déteste… plusser ou quelle que soit la façon dont vous appelez écrire une longue harangue dans Google+. Google+ n’est pas du tout adapté à ça mais je le fais quand même car, l’un dans l’autre, je veux que Google réussisse. Je le veux vraiment ! Facebook me courtise, il me serait très facile de les rejoindre. Mais je me sens chez moi chez Google, donc j’insiste pour que nous ayons cette petite discussion de famille, même si c’est désagréable.

Quand vous aurez été émerveillés par les plateformes de Microsoft et Amazon, et de Facebook aussi j’imagine (je n’ai pas été voir de peur d’être trop déprimé), rendez-vous sur developers.google.com et explorez un peu. Vous voyez la différence, hein ? C’est un peu ce que votre neveu, qui est en CM2, rendrait comme copie si on lui donnait comme devoir d’expliquer ce qu’est une puissante société opérant une plateforme mais ne disposant pour seule ressource que d’un élève de CM2.

Comprenez-moi bien. Je sais à quel point l’équipe de développement a dû se battre pour parvenir jusqu’à ce point. Ils sont formidables, si vous voulez mon avis. Ils comprennent les plateformes. Et ils se battent avec héroïsme pour essayer d’en créer une dans un environnement qui est au mieux indifférent aux plateformes, au pire ouvertement hostile à l’idée même de plateforme.

Je suis juste en train de décrire franchement ce à quoi ressemble developers.google.com pour quelqu’un de l’extérieur. C’est de la gribouille. Où est donc l’API de Google Maps ? Certaines choses ici sont des projets de laboratoires. Et toutes les API sur lesquelles j’ai cliqué étaient de mauvais goût. De la nourriture pour chiens. Pas du tout de la bonne nourriture bio. Comparé à nos API internes, c’est all snouts and horse hooves.

Et aussi comprenez-moi bien au sujet de Google+. Les gens de Google+ sont loin d’être les seuls coupables. C’est culturel. Ce que nous vivons en interne, c’est une guerre, avec une minorité de rebelles défendant les plateformes et forcément perdants face à l’empire des développeurs d’applications, bien mieux armés.

Toutes les équipes qui ont intégré l’idée selon laquelle elles devraient développer dès le départ des plateformes programmables sont des rebelles – je pense à Google Maps ou Google Docs, et je sais que Gmail fait des avancées dans cette direction. Mais c’est difficile pour elles d’obtenir des ressources car ça ne fait pas partie de notre culture. Les ressources allouées à Maestro ne sont rien en comparaison des ressources gargantuesques à la plateforme de programmation de Microsoft Office : c’est un petit lapin fragile face à un tyrannosaure. L’équipe Google Docs sait qu’elle ne peut pas être compétitive vis-à-vis d’Office à moins d’être aussi performante en matière de scripts. Mais elle n’inspire aucune affection et n’obtient aucune ressource. En tout cas j’imagine que c’est le cas car, à ce jour, Apps Script ne fonctionne que pour les feuilles de calcul, et aucun raccourci clavier n’est disponible via l’API. Cette équipe me semble bien délaissée.

Non sans ironie, Google Wave était une belle plateforme – paix à son âme. Mais faire une belle plateforme ne suffit pas. Une plateforme a besoin d’une application pour se lancer. Facebook – l’application qui vous permet de faire des choses avec votre wall, vos amis et tous ces trucs –  est l’application qui a permis de lancer la plateforme Facebook. Et c’est une grave erreur de considérer que l’application Facebook pourrait avoir rencontré un aussi grand succès s’il n’y avait eu, en dessous, la plateforme Facebook.

Vous vous souvenez à quel point les gens disent toujours que Google est une entreprise arrogante ? Je suis un Googler, donc ça m’irrite autant que vous quand les gens disent ça. Nous ne sommes pas arrogants, loin s’en faut. Nous sommes non-arrogants à 99%. J’ai débuté ce billet – si vous vous en souvenez – en écrivant que Google faisait tout bien. Nous sommes pétris de bonnes intentions. La plupart du temps, les gens disent que nous sommes arrogants parce que nous avons refusé des les embaucher, ou encore ils sont mécontents de nos pratiques, ou quelque chose comme ça. Ils concluent à l’arrogance parce que ça les fait se sentir mieux.

Mais quand nous expliquons que nous savons concevoir des applications pour satisfaire tout le monde, et croyez-moi j’entends ça beaucoup par ici, nous nous méprenons complètement. Vous pouvez attribuer ça à l’arrogance, à la naïveté, à plein de choses – peu importe car, au final, c’est bien de stupidité qu’il s’agit. On ne peut satisfaire tout le monde avec une seule application.

Par exemple, nous proposons un navigateur, Chrome, qui ne permet pas de paramétrer une taille de police par défaut. Si ce n’est pas un affront à l’idée d’accessibilité ! En vieillissant, j’y vois moins bien. Pour de vrai : j’ai été myope toute ma vie, mais quand vous passez les 40 ans il devient plus difficile de voir de près. Du coup, la taille de la police devient une question de vie ou de mort : quelque chose qui peut vous fâcher complètement avec une application. Or l’équipe Chrome fait preuve d’arrogance dans ce cas : ils veulent réaliser une application sans paramétrage, ils sont radicaux dans cette approche, et allez vous faire foutre si vous êtes aveugle, malentendant ou quoique ce soit d’autre. Tapez Ctrl-H à chaque page pour le restant de votre vie. Merci bien.

Ce n’est pas eux le problème. C’est tout le monde. Le problème est que nous sommes une société spécialisée dans les applications, du sol au plafond. Nous avons un jour conçu une application couronnée de succès à une très très grande échelle – je parle de notre moteur de recherche – et cet impressionnant succès nous a aveuglés.

Amazon était aussi spécialisée dans une application, donc il a fallu une force hors du commun à Jeff Bezos pour comprendre qu’il avait besoin d’une plateforme. Cette force, il l’a puisée dans ses marges de plus en plus faibles : Bezos était piégé par ces marges, il lui fallait trouver une issue. Or tout ce qu’il avait sous la main, c’étaient ces ingénieurs, ces ordinateurs… si seulement il pouvait les monétiser d’une manière ou d’une autre… chacun peut voir, avec le recul, comment il est parvenu à l’idée d’Amazon Web Services.

Microsoft était une plateforme dès le départ, donc ils étaient déjà très entraînés.

Facebook m’inquiète beaucoup plus. Je les connais mal, mais je suis à peu près sûr qu’ils ont commencé avec une application et qu’ils ont longtemps avancé comme ça. Du coup, je ne suis pas tout à fait sûr de comment ils ont réalisé la transition vers la plateforme. C’était il y a relativement longtemps, car Facebook devait être une plateforme avant l’apparition de choses aussi anciennes que Mafia Wars.

Peut-être ont-ils simplement jeté un oeil chez nous et se sont-ils demandés : « Comment pouvons-nous battre Google ? Quel est leur point faible ? »

Le problème auquel nous sommes confrontés est considérable, car il faudra une profonde transformation culturelle pour reprendre le train en marche. Nous n’avons pas de plateformes orientées services en interne, nous n’en avons pas plus pour l’extérieur. Cela veut dire que l’incapacité à saisir la notion de la plateforme est endémique au sein de l’entreprise: les responsables d’applications ne saisissent pas, les ingénieurs ne saisissent pas, les équipes ne saisissent pas, personne ne saisit. Même si les individus comprennent, y compris vous, ça n’a pas aucune espèce d’importance sauf à traiter tout cela comme une situation d’urgence exigeant l’attention de tous. Nous ne pouvons continuer à lancer de nouvelles applications et faire semblant de vouloir les transformer en plateformes magiques plus tard. Nous avons essayé cela, ça ne marche pas.

La règle d’or des plateformes, « Mangez comme votre chien », peut être reformulée ainsi : « Commencez avec une plateforme, puis utilisez-là pour faire tout le reste ». Vous ne pouvez pas la remettre à plus tard. A moins d’être prêts à le payer très cher – demandez à quiconque a travaillé à transformer MS Office en plateforme, ou à quiconque a travaillé à transformer Amazon en plateforme. Si vous remettez à plus tard, cela représentera dix fois plus de travail que de le faire tout de suite. Hors de question d’aménager des portes dérobées pour des applications internes, ne faites cela à aucun prix. Il faut vous affronter dès le départ aux problèmes les plus difficiles.

Je ne dis pas que c’est trop tard, mais que plus nous attendons, plus nous nous approchons du moment où il sera trop tard.

Honnêtement, je ne sais pas comment conclure. J’ai dit à peu près tout ce que j’étais venu vous dire aujourd’hui. Ecrire ce billet m’a pris six ans. Pardonnez-moi si je n’ai pas été très gentil, ou si j’ai fait des erreurs en évoquant certaines applications, certaines équipes ou certaines personnes, ou encore si, en réalité, nous faisons plein de choses en matière de plateformes et que le seul problème est que ni moi ni personne parmi les gens que je connais n’en ont entendu parler. Je suis désolé.

Il faut nous mettre au travail dès à présent, et faire les choses bien.

Vous êtes la multitude !
    Ce contenu a été publié dans Uncategorized. Vous pouvez le mettre en favoris avec ce permalien.

    Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /home/colinver/www/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1044