Chronique : Interview de Peter Norvig, directeur de la recherche chez Google

Slate a réalisé une interview de Peter Norvig, directeur de la recherche chez Google, au sujet des erreurs, des avantages à échouer rapidement, et de la raison pour laquelle Google n’achète que des ordinateurs peu coûteux.

Comment caractériseriez-vous l’attitude globale par rapport aux erreurs chez Google ?

L’histoire remonte à la fondation de Google : l’un des investisseurs est allé voir les deux fondateurs Larry Page et Sergey Brin et leur a demandé « Ok, la première chose que vous devez décider est, est-ce que le moteur de cette entreprise sera les ventes ou le marketing ? » Ils ont répondu « nous pensons que ce seront les ingénieurs ». Il a rigolé, et a dit « Oh, vous êtes des étudiants naïfs, c’est pas comme ça que le vrai monde fonctionne ». Ce à quoi ils ont répliqué « Et bien, nous voulons essayer ». Dix plus tard, cette expérience est toujours en cours; les ingénieurs sont toujours le centre de l’entreprise. Et il semble que cela ait fonctionné.

Cette philosophie engendre une approche totalement différente des erreurs. Si vous êtes un politicien, admettre que vous avez tort est une faiblesse, mais si vous êtes un ingénieur, vous voulez avoir tort la moitié du temps. Si vous testez et que vous ne vous trompez jamais, vous ne tirez pas suffisamment de leçon de ces expériences. Vous voulez que votre expérience ne soit pas parfaite : vous n’avez aucune idée des résultats. Vous ne voulez pas savoir si les résultats vont être bon ou mauvais.

Et par rapport aux erreurs qui ne découlent pas des expérimentations mais de l’implémentation ou de l’exécution ? Que faites-vous de ces erreurs là, qui peuvent potentiellement compromettre votre produit ?

En tant qu’ingénieur, vous vous êtes fait à l’idée qu’il y a des erreurs. Peu importe vos compétences, si vous écrivez 100 lignes de code, il va sans doute y avoir une erreur dedans. Vous devez donc construire l’intégralité de votre système sur cette hypothèse. Nous avons établi un ensemble de procédures autour de l’idée que les erreurs existent, et sur les besoin de minimiser leurs impacts.

A quoi ressemblent ces procédures ?

Il y a deux sortes d’erreurs à traiter. Premièrement, il y a les erreurs inhérentes au code : le programme est supposé faire quelque chose alors qu’il faut autre chose. Dans ce cas, vous savez tout de suite si vous vous trompez de voie, et vous saurez lorsque vous serez sur la bonne. Deuxièmement, quels sont les résultats ? Disons que vous effectuiez une recherche et que des liens s’affichent ; il n’y a pas de réponse claire à la question « est-ce que ça a marché ? », mais vous pouvez dire « bon, cette version a mieux marché que la précédente ».

Que faites-vous au sujet des échecs techniques ? Je suppose que parfois ce n’est pas le logiciel qui pose problème mais le matériel, et le prix de ces problèmes peut être assez élevé.

Je pense que Google a rapidement accepté les erreurs techniques. D’autres entreprises ont essayé de dire « si vous pouvez acheter des ordinateurs chers et plus fiables, alors vous aurez moins de problèmes et vous serez plus performants ». Google a au contraire décidé d’acheter une grande quantité d’ordinateurs à bas prix qui plantent sans arrêt, mais grâce aux coûts peu élevés, vous pouvez concevoir un système avec de multiples backups et moyens de contourner les problèmes. L’architecture du système est faite pour accepter les problèmes. Google a beaucoup innové dans ce domaine, et a économisé beaucoup d’argent grâce à cela.

Comment cette innovation a-t-elle vu le jour ?

Je pense qu’elle est en partie visionnaire. Mais d’un autre côté, le problème que nous avions l’a rendu plus simple à aborder. Si vous effectuez une requête, que certains des ordinateurs plantent en plein milieu du traitement, et que vous n’obtenez pas les mêmes résultats que quelqu’un d’autre, ce n’est pas si grave. Le premier résultat doit rester le même, si je recherche « New York Times », je veux tomber sur nytimes.com en premier résultat. Mais que devrait être le 10è résultat ? Il n’y a pas de réponse parfaite. Si une erreur matérielle entraîne la disparition d’un résultat à la 10è place, vous ne pouvez pas affirmer qu’il y a eu une erreur. Tandis que si je suis une banque, je ne peux pas dire « Oh, à chaque million de transactions, je vais perdre de l’argent ». Je ne peux pas me permettre ce niveau d’erreur. Un moteur de recherche est plus tolérant à ce genre d’erreur.

J’ai été des deux côtés. J’ai travaillé pour la NASA, et vous ne tenez pas à ce que les navettes explosent trop souvent. Ils dépensent donc des millions de dollars pour protéger la vie de leurs astronautes. Chez Google, c’est tout l’inverse. L’échec est toujours une option chez Google.

Je veux parler de l’innovation, car il me semble que le prix à payer pour essayer de nouvelles choses est que la plupart sont un échec. Comment établissez-vous une tolérance envers ce genre d’échec dans le cadre d’une entreprise publique qui doit réaliser des bénéfices ? Se tromper est sans doute essentiel avant de sortir le bon produit, mais cela peut être très cher à payer.

Nous essayons d’échouer plus rapidement et en moindre mesure. Le cycle moyen de production chez Google est plus trois mois que trois ans. La taille des équipes est également réduite, afin de pouvoir éviter les débats inutiles du genre « pouvons-nous avoir 50 personnes pour travailler sur ce projet ? ». Chez nous, deux ou trois personnes font équipe et testent tous les projets qu’ils ont en tête. Ils n’ont pas besoin de la permission de supérieurs hiérarchiques pour se lancer car ce ne sont que deux ou trois employés.

Deux ou trois mois ne me semble pas beaucoup. Comment déterminez-vous à cet instant si une idée va réussir ou échouer ?

Lorsque vous parlez d’échec, je sous-entends d’un point de vue statistique, et au sein de l’entreprise nous sommes très bons pour prendre des décisions basées sur des statistiques. Si nous avons une idée — « voilà un moyen d’améliorer cet outil » — nous sommes en mesure de répondre « et bien faisons une expérience. Comparons l’actuel et l’idée sur un échantillons de recherches ». Après avoir collecté suffisamment de données, nous pouvons en déduire si c’est mieux, beaucoup mieux, etc. C’est notre pain et notre beurre.

Ok, mais qu’en est-il des aspects que vous ne pouvez pas mesurer ?

C’est bien la question. Lorsqu’une idée nous est proposée mais qu’elle ne peut pas vraiment être jugée statistiquement, c’est plus délicat pour nous. Prenez par exemple le lancement de Gmail, où la question n’était pas « pouvons-nous réussir un tel produit ». La question était plutôt « qui sont les autres acteurs du marché ? ». Il s’agissait de  Microsoft, Yahoo et AOL, des rivaux ou des partenaires, donc la question est devenue « comment vont-ils réagir si nous faisons ça ? ». Nous avions aussi l’idée d’offrir le service gratuitement et d’ajouter des publicités sur les côtés, la question qui se posait était « est-ce que les gens ne vont pas trouver ça repoussant ? ».

Vous ne pouvez pas vraiment faire des expérimentations pour ce genre de projet ; tout n’est pas que statistique. Je suppose que vous pouvez mettre en place des groupes de test, mais ces groupes ne sont pas réellement importants; ce qui compte vraiment c’est ce que la presse va en penser. Ce genre de décision doit plus être pris à l’instinct, et en tant qu’entreprise, c’est plus compliqué pour nous.

Pouvez-vous expliquer l’idée d’instinct pour moi ? Qu’est-ce que c’est ? Sur quoi vous basez-vous lorsque vous lorsque vous prenez ce genre de décision ?

Bonne question. Je suppose que c’est l’expérience. On se projette dans le futur selon ce que l’on a fait par le passé. Cela va-t-il marcher ? Allons-nous être en mesure de terminer le projet à temps ? Est-ce que cela va fonctionner comme prévu ? Vous pouvez anticiper ce type de question en ayant développé des projets similaires.

La partie la plus délicate, à mon sens, est d’anticiper les réactions. Oui, nous pouvons le faire, mais les utilisateurs vont-ils apprécier ? Ou est-ce que quelqu’un d’autre va sortir un meilleur service en premier ? Ou comment est-ce que les autres entreprises vont-elles réagir à cela ? Je pense que c’est aussi lié à l’expérience, mais c’est beaucoup plus compliqué car cela ne prend pas uniquement en compte ce que nous pouvons réaliser, mais aussi la réaction d’autres personnes.

Pensez-vous que votre instinct est bon ? Lorsque vous tombez amoureux d’une idée ou d’un projet, lorsque vous pensez que ce projet va fonctionner, est-ce que vous avez habituellement raison ?

Je pense que nous avons souvent de bonnes intuitions sur la direction générale d’un projet. En tant qu’entreprise, nous avons énormément misé sur le mobile et sur la plate-forme Android car nous pressentions que les gens allaient davantage utiliser leurs téléphones que leurs ordinateurs, et ce pari a payé. Par contre, en ce qui concerne les détails, est-ce que créer la plate-forme était la meilleure façon de nous y prendre ? Aurions-nous du nous associer avec d’autres acteurs ou créer un système différent ? C’est plus difficile à dire. La plupart du temps, les idées stratégiques sont claires, mais comment nous y prendre l’est moins.

Qu’en est-il pour le genre d’expérimentations que vos utilisateurs voient, comme tout ce qu’il y a dans Google Labs ? Ces projets rencontrent-ils souvent le succès, ou est-ce plus souvent du style « et bien, c’était une bonne idée » ?

La plupart des projets que vous voyez dans Google Labs sont là car nous ne savions pas vraiment quoi en faire, donc probablement moins de la moitié deviennent des gros succès. Je ne connais pas le nombre exact. Certains d’entre eux sont déjà abandonnés avant d’atterrir dans Labs ; si nous avions pensé qu’ils étaient excellents, ils seraient sur le site principal plutôt que sur Labs. Certains autres sont là parce que ce n’était pas évident ; il peut y avoir des problèmes de sécurité ou d’image de marque, nous ne voulons pas traiter ces problèmes si nous n’avons pas à le faire. Au lieu de cela, nous le lançons au sein de Labs, et si le projet devient vraiment populaire, il sera temps de réfléchir à comment l’intégrer.

Malgré tous les projets innovant initiés par Google depuis le début, la très grande majorité de vos bénéfices — j’ai entendu entre 97 et 99% — proviennent d’une seule chose : la publicité liée à la recherche. J’en déduis donc que la génération de revenus n’est pas la mesure utilisée pour décider si un produit est bon ou pas. Qu’utilisez-vous dans ce cas ?

Vous avez raisons, la plupart de nos revenus proviennent de la publicité. Mais vous pouvez considérer tous les autres produits comme des moyens d’emmener le client à cliquer sur les pubs. Nous connaissons la valeur d’un nouveau client, et nous pouvons voir ce que font les internautes sur nos sites. Nous pouvons donc dire « cette fonctionnalité est populaire, notre taux d’utilisation grimpe, et parce qu’il grimpe, nous générons plus de revenus ». Nous faisons des choses pour améliorer Google afin que les internautes nous rendent davantage visite et cliquent sur les pubs.

Ce qui est intéressant, c’est que nous avons atteint une telle échelle que nous pouvons maintenant nous permettre de développer des projets qui bénéficient seulement au Web. Nous publions souvent nos projets en Open Source, car si nous publions du code et qu’une autre entreprise l’utilise pour faire quelque chose de vraiment cool, Internet y gagne, et nous y gagnons aussi. A peu près la moitié des internautes utilisent la recherche Google, donc si une autre entreprise créé quelque chose et que deux personnes commencent à utiliser Internet grâce à ça, nous allons en récupérer un des deux.

Google réussi remarquablement bien à créer des projets populaires. Comment est-ce l’entreprise parvient-elle à créer une culture encourage les nouvelles idées ?

Nous avons d’excellents employés, et c’est en grande partie grâce à eux. Mais je pense que la cause principale est que nous essayons beaucoup d’idées. Nous avons construit le système ultime pour lancer des démos en interne. Si une startup a une idée, ils doivent passer des mois voire des années à soulever des fonds et à construire l’architecture.

Nous avons déjà tout ceci. Quelqu’un peut apprendre à utiliser ce système durant son premier jour et dire « Ok, j’ai une idée, et ces morceaux sont déjà en place, je peux simplement les connecter entre eux et voir si ça fonctionne ». Et si ça ne fonctionne pas aujourd’hui, j’aurai une meilleure idée la semaine prochaine. Et je n’ai pas passé un mois à suivre une piste.

Je suis impressionné par la durée de la phase bêta de certains produits chez Google. Gmail, par exemple, a été lancé en 2004 mais n’a quitté la bêta qu’en 2009, alors que le service avait déjà 146 millions d’utilisateurs. Quelle est le raisonnement ?

Il y a deux raisons, l’une technique et l’autre marketing. D’un point de vue technique, vous définissez un projet est vous dites « il y a des fonctionnalités que le produit doit avoir, et jusqu’à ce qu’il les possède, il reste en bêta ». Il suit une autre décision : quand doit-on lancer le service ? Il peut manquer quelques fonctions mais quant même valoir la peine d’être lancé, nous avons choisi cette méthode, alors que d’autres entreprises semblent moins enclines à le faire. Je ne sais pas vraiment pourquoi les gens du marketing aiment les bêta. Cela donne peut-être l’impression que Google est en constant changement et que les produits ne sont jamais terminés. Ils veulent peut-être donner cette impression.

La semaine dernière je me suis entretenu avec le co-fondateur de Wikipédia Larry Sanger sur notre utilisateur du Web pour organiser, valider et disséminer l’information. La mission avouée de Google est d’organiser les informations du monde entier. L’entreprise fait-elle quoi que ce soit pour avantager les résultats les plus précis ou crédibles dans les résultats de recherche ?

En un sens, l’innovation clé derrière Google — la notion de Page Rank, qui calcule combien d’autres personnes pointent vers votre contenu — est une mesure basique de la crédibilité. Cette idée est venue suite à la frustration ressentie par rapport à la qualité des résultats donnés par les autres moteurs de recherche. Les premiers moteurs de recherche ont été construits sur une technologie « de bibliothèque » : pour effectuer une recherche, vous rassemblez tous les documents contenant le terme recherché et vous comptez le nombre d’occurrences dans chaque. Vous obteniez donc des résultats hors sujets mais contenant souvent le terme recherché. Le Page Rank dit que si beaucoup de liens pointent vers cette page, alors elle doit être de qualité.

C’est encore comme cela que ça marche, mais beaucoup de choses se sont passées depuis. Il y a par exemple en ce moment une guerre entre les gentils et les spammeurs — les gens qui essayent de gonfler artificiellement leurs performances en trompant notre système en construisant des pages revendiquant une fausse crédibilité. Nous devons surveiller ce phénomène. Un paramètre de l’équation repose sur la « fraîcheur » des pages. Une nouvelle page, aussi intéressante soit-elle, ne peut pas obtenir instantanément de la crédibilité, il nous faut donc faire la part des choses entre un nouveau résultat et l’accumulation de la crédibilité avec le temps. Mais oui, nous gardons toujours un oeil sur la qualité, la crédibilité et la pertinence.

Quelles ont été les plus grosses erreurs de Google d’après vous ?

Je ne peux pas parler pour toute l’entreprise, mais je pense que nous avons loupé notre entrée sur les aspects sociaux. Facebook est arrivé et a rencontré énormément de succès. Il y avait ce sentiment selon lequel « nous sommes sur les informations réelles, valides, alors que Facebook est plus sur les potins de star ». Je pense avoir loupé le fait qu’il y a une réelle importance à avoir un réseau social et que les recommandations des amis pèsent lourd dans la balance. Je me suis peut-être trop concentré sur les faits et les chiffres — pour la requête « quelle caméra numérique devrai-je acheter ? », malgré les meilleures critiques et faits, certains pourraient préférer savoir ce que leurs amis leurs conseillent.