De la différence entre innovations

J’aimerais distinguer dans cet article deux types d’innovations en partant de l’exemple de Google, histoire de ne pas prendre toujours les mêmes. A partir de cette séparation en deux catégories je vais présenter des conclusions de management et de paradigme de développement.

Les deux catégories que je vais dégager vont se baser sur deux produits principaux de Google :

  • d’une part le moteur de recherche en lui-même ;
  • d’autre part le gestionnaire de mail GMail (et un peu Google Chrome).

Le premier est issu d’une recherche en Computer Science durant un PhD qui a duré, en comptant la maturation de l’idée et l’implémentation de la solution, entre 2 et 3 ans.

Cette idée a germée tout d’abord dans l’esprit de Larry Page alors qu’il étudiait les liens entre pages dans la représentation sous forme de graphe d’Internet. Il a été encouragé dans cette voie par son directeur de thèse de l’époque Terry Winograd et Sergey Brin l’a rejoint après coup dans ce projet.

Je vais passer sous silence le côté aléatoire de la chance et des heureuses rencontres qui vont avec cette histoire, pour faire un constat simple. Il est difficile d’aboutir à ce genre d’innovation sans un environnement adapté :

  • la possibilité de ne pas se disperser intellectuellement sur d’autres problèmes ;
  • un environnement académique avec des gens brillants ET POSITIFS ;
  • de grandes connaissances théoriques et la capacité de voir des applications pragmatiques à ce savoir.

Pour résumer, il faut du temps (peut-être le temps d’une thèse), le bon environnement et les bonnes personnes.

Le deuxième, en revanche, part d’une simple « bonne » idée, ici la représentation sous forme de « fils de discussion » d’une série d’échanges de mails.

Il y a peu de sources sur quand est-ce que le projet a été initié en interne chez Google, principalement parce que GMail a été utilisé en premier lieu comme messagerie interne à la société pour finir par être rendu publique le 1er Avril 2004.
Néanmoins on peut considérer qu’au delà de la création de l’interface AJAX (novatrice pour l’époque), le temps nécessaire pour transformer cette idée en Proof Of Concept, voire en Beta utilisable, fut assez court.

Pour moi ce projet, au contraire du précédent, correspond à ce que j’appellerai une innovation de deuxième type. Une innovation plus basée sur une nouvelle expérience utilisateur que sur une percée scientifique. Car en somme, si on caractérise l’expérience utilisateur du premier et du second projet, on trouve d’assez grandes différences :

  • Google n’a pas révolutionné la façon d’utiliser un moteur de recherche (frontend),
    • il a révolutionné le moteur de recherche (backend).
  • GMail n’a pas amélioré les envois d’emails à travers Internet (backend),
    • il a révolutionné la façon d’envisager la gestion de ses emails (frontend).

Si on y réflechit, l’expérience utilisateur autour de la recherche web n’a été vraiment modifiée que récemment avec Google Instant.
Avant Google Instant, tout ce que Google avait amélioré était la qualité des recherches et leur réactivité, nous avons arrété d’être frustrés devant AltaVista chargeant ses centaines de publicités pour nous calmer devant une interface au design épuré et dépourvue de toute publicité (ce qui était nouveau à l’époque… et l’est encore).

Je conclus deux choses de cette petite histoire, que nous ne parlons pas du même type d’innovation, et qu’en terme de temps de développement et de maturation, il y a des différences.
Pour approfondir ce point j’aimerais faire une petite digression la loi d’itération de Boyd  (« Boyd’s Law of Iteration« ), je trouve cette approche d’itération rapide assez intuitive et proche des concepts agiles devenus maintenant monnaie courante.
Mais, au contraire de l’équipe de StackOverflow, je ne pense pas qu’elle s’applique dans tout les cas et c’est pour cela que je trouve important cette distinction entre innovations.

J’aurais besoin de la confirmation d’amis faisant plus de Computer Science que moi, car il faut bien le dire qu’en tant que développeur Java mon travail reste plus proche du Software Engineering, pour confirmer/infirmer ce que je vais enoncer :

  • Une innovation scientifique en Computer Science a besoin d’un contexte académique et d’un temps de maturation de quelques années (2-3 ans) pour batir son fond théorique ;
  • tandis qu’une innovation de workflow, améliorant l’expérience utilisateur, a besoin d’être développée rapidement, de manière itérative et agile pour avoir le plus de feedback possible et s’améliorer en continue.

Je pense pouvoir dire que Google est bien parti sur ce principe, car si on regarde le cycle de développement de Google Chrome (cf. Go That Way Really Fast), les versions se sont enchaînées bien rapidement :

  • 1.0 December 11, 2008
  • 2.0 May 24, 2009
  • 3.0 October 12, 2009
  • 4.0 January 25, 2010
  • 5.0 May 25, 2010
  • 6.0 September 2, 2010

Les releases ne sont jamais séparées de plus de 6 mois, loin des (très probables) deux ans de développements de IE9.

Je respecte cette approche et je ne vais pas encore tirer de conclusions sur la pérennité d’une structure en fonctions du types d’innovations qu’elle choisit. Je pense qu’une société doit savoir allier les deux formes :

  • une forme itérative et rapide pour profiter au mieux de sa crédibilité ;
  • et une forme calme et réflechie pour créer de la valeur scientifique.

Ce n’est qu’une idée que j’espère pouvoir tester grandeur nature un jour, en attendant

Vale

Publicités

6 Commentaires

  1. En effet, Google n’a pas beaucoup modifié l’UX de la recherche à son lancement. La 1e grande modification avait eu lieu lors du passage des moteurs personnels (temps réel) inclus dans les navigateurs aux moteurs centralisés accessibles par une page web.

    Concernant Instant, je ne suis pas enthousiasthmé. Je ne pense pas que ça va révolutionner la manière dont les gens cherchent. Je pense même que la plupart des recherches ne l’utiliseront pas… C’est rare que j’aille sur google.*, à part pour voir les logos, c’est bien plus simple d’utiliser les fonctionnalités de recherche intégrées au navigateur.

    Pour revenir au sujet principal, ce qu’il faut pour innover en Computer Science, je ne pense pas qu’il faille nécessairement un milieu académique. On voit encore pas mal d’innovations de cet ordre chez Google, entre autres Go, MapReduce, etc. Ce qu’il faut, c’est surtout des idées, et un peu de temps libre pour implémenter les prototypes.

    Le problème, c’est que je pense que la principale condition pour avoir des idées, c’est d’avoir du temps libre. Beaucoup de temps libre. plus quelqu’un (qui a le background suffisant et de l’intérêt évidemment) a de loisirs, moins il a de soucis, plus il a de trous dans son emploi du temps et plus il sera productif. En clair : un bon chercheur est un passionné qu’on laisse glander.

    Comme les entreprises n’aiment pas payer les gens à ne rien faire, oui, les bonnes idées naissent dans des labos. Mais ce n’est pas parce qu’on laisse aux gens le temps pour lez développer ensuite : en entreprise, les bonnes idées n’apparaissent juste pas, parce que quand on bosse plus de 40 h par semaine dans un domaine on perd l’ouverture d’esprit suffisante pour le faire évoluer.

    Oui, RH, si tu me lis, je suis en train de t’expliquer que tu fais des bêtises depuis des années dans tes recrutements de chercheurs : plus ils ont d’expérience professionnelle et *moins* ils sont bons.

    1. C’est pas une mauvaise idée  » pour être innovant scientifiquement, il suffit d’un passionné, doctorant en maths appliqués, qu’on laisse glandé », je vois juste mal une startup qui « compte ses mois des financements » et sa deadline pour être rentable avoir les moyens de se payer un doctorant…
      D’autant plus que c’est certainement pas nos grandes entreprises qui vont permettre ce genre de liberté, pour la raison que tu as évoqué : « les entreprises n’aiment pas payer les gens à ne rien faire ».
      C’est d’ailleurs marrant de voir le nombre de glandeur qui font 3 tonnes d’heures pour compenser… mais c une autre histoire

  2. Puisqu’on parle d’innovation dans les moteurs de recherche : http://www.wordstream.com/articles/internet-search-engines-history

  3. Je sais bien que les grosses boites ne vont pas se permettre ça. Elles ont juste tort, ça leur rapporterait probablement plus.

    Les startups, c’est autre chose, mais elles ne sont pas si short budgétairement que tu sembles le penser. Et je ne propose pas de payer les gens à glander en permanence, plutôt de les payer pour être bons entre 20 et 35 heures par semaine plutôt que mauvais pendant 50.

    Bon, ça sous-entend aussi que quand ils ne sont *pas* bons ils doivent dégager rapidement…

  4. C’est clair que pour l’instant ma meilleure équipe était une équipe qui savait dire « ok on continuera demain » ou « on doit finir ça now, on assume ».
    Et pas comme j’ai entendu récemment « on assure un ‘service’ entre 8h et 18h30″…
    On sait ce qui nous reste à faire 😉

  5. Un peu en retard sur les commentaires mais tant pis…

    1. On l’oublie souvent, mais je pense qu’une des raisons du succès de Google au début fut leur page d’accueil. Alors que sur les autres moteurs avaient des pages d’accueil et de résultats remplies de publicités, de menus et d’autres choses inutiles, google a su créer des pages de résultats et de recherche simples. Au début, j’allais sur google parce que la page ne mettait pas 3 ans à se charger, et non pas parce que les résultats étaient meilleurs.

    Tout cela pour dire que des fois, le succès est dû à une raison qui n’est pas forcément celle à laquelle on pense (autre exemple au début j’utilisais Firefox pour les onglets, et non pas parce que les standards étaient mieux supportés)

    2. Chez Google, ils avaient un truc qui s’appelait le « Thanks god it’s Friday ». Cela signifiait que pendant une journée (le vendredi), les ingénieurs de la boite pouvaient travailler sur des projets personnels ou qui leur tenaient à coeur. Cela permettait donc d’avoir des gens qui « glandouillent » sur des projets pas forcément viables.

    J’avais vu dans un reportage sur France 5 (qui doit dater de 2006), je ne sais pas si c’est encore le cas aujourd’hui, mais je trouve que c’est un bon moyen de créer de l’innovation, sans perte incommensurable pour l’entreprise (1/5 du temps de travail de l’ingénieur).

    3. Pour être actuellement en Master d’informatique en Chine, et donc devant faire un travail de recherche d’un an à un an et demi, on constate les ravages du « publish or perish ». Les tuteurs et les étudiants préfèrent travailler sur quelque chose qui n’est pas transcendant mais qui fera facilement l’objet d’un papier que de travailler sur quelque chose de totalement neuf qui peut ne pas marcher (et donc ne pas pouvoir être publié).

    La première chose que l’on m’a demandée lorsque j’ai présenté mon projet de recherche, c’est « est-ce que cela marche ? » (j’ai eu envie de répondre « ben je sais pas, si je le savais je ne ferais pas une recherche là-dessus »).

    Les contraintes du monde de l’entreprise (recherche de résultats) se retrouvent donc aussi dans les laboratoires de recherche (dans une moindre mesure, certes, mais elles existent).

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :