Comment Google parvient à obtenir le meilleur de ses ingénieurs grâce au peer reviews ?

Cet article est un extrait du livre « Une Révolution du Management : le modèle Google » écrit par M. Bernard Girard

« Je continue mon tour d’horizon des stratégies de management que Google a su mettre en place. Après avoir parlé de quelles manières 3 personnes dirigent cet empire, je voudrais aujourd’hui vous présenter comment les deux fondateurs de Google ont mis en place un système de peer reviews.
Ce système est moins connu que la célèbre liberté des 20% qui permet à chaque employé (non administratif) de conserver 20% de son temps de travail soit un jour par semaine pour développer son propre projet (j’en reparlerai lors d’un prochain billet). Nénamois, ce système de peer reviews a su s’imposer comme un concept gagnant pour la firme de Moutain View. Mais alors de quoi s’agit-il ?

Le peer reviews chez Google, kesako ?
Lorsqu’une équipe de Google a commencé à développer un projet, elle le présente pour validation à
des collègues d’autres départementsa lors que d’habitude, dans des entreprises traditionnelles, cette tâche est dévolue à la hiérarchie, au service marketing ou à un comité exécutif. Ce groupe de collègues, qui se réunit très régulièrement, prend la décision de sélectionner les nouveaux projets, d’interrompre les projets en cours ou de les poursuivre. Ces réunions sont rapides, intensives. Il parait que le vendredi après-midi en générale, Marissa Mayer et une cinquantaine d’ingénieurs se rencontrent. Pour ceux qui ne la connaitraient pas,  Marissa Mayer (Première femme ingénieur chez Google) dirige la stratégie de gestion des produits de recherche de Google : recherche sur le Web, recherche d’images, groupes, actualités, Froogle, barre d’outils Google, Google Desktop, Google Labs, etc.  Lors de ces réunions, elle parle vite, prend des notes à toute vitesse tandis que les ingénieurs se précipitent pour expliquer et défendre les idées nouvelles qu’ils ont postées sur un site Intranet. Au bout d’une heure de réunion, six, sept  et parfois huit nouvelles idées sont sélectionnées pour être poursuivies. Certaines deviendront de nouvelles fonctionnalités sur GCoogle, d’autres du code, de nouveaux algorithmes.

D’où vient ce concept ?
Cette méthode s’inspire librement du modèle académique. Avant de prendre une décision de publication, les revues scientifiques adressent les articles qui leur sont proposés à des experts reconnus du domaine auxquelles elles demandent un jugement qui est en général sans complaisance. Lorsque le comité de rédaction se réunit, ces experts confrontent leurs opinions et prennent une décision. Ici, on s’adresse à des pairs, des ingénieurs de haut niveau que l’on respecte pour leurs réalisations, leur connaissance du domaine. Leur opinion compte, et parce qu’elle compte, chacun fait des efforts pour mériter leur approbation.

Comment Google l’applique-t-il ?
Appliquée au monde de l’entreprise, cette méthode oriente les échanges sur le contenu: on parle de code, de programmation et de cela seulement. EI les meilleurs, les plus brillants dans ces échanges ne sont pas les plus élevé dans la hiérarchie, mais les plus savants, les plus compétents, ceux qui maitrisent le mieux le langage informatique, ceux qui savent le mieux lire une page de code, qui savent le mieux discerner ses faiblesses.

Plus qu’un modèle, une nouvelle hiérarchie
Ces peer reviews aident à la création d’une hiérarchie parallèle basée sur Ia performance technique et la réputation dont Eric Schmidt soulignait l’importance alors qu’il était encore à la tête de Novell : «Si vous ne voulez pas perdre vos geeks, disait-il dans une interview au magazine Fast Company en 1999, il faut trouver un moyen de leur offrir des promotions sans en faire des managers. La plupart d’entre eux feraient de mauvais cadres dirigeants, beaucoup seraient en fait des catastrophes. Mais il faut leur offrir des perspectives de carrière et des augmentations.  Créer une échelle technique est une première étape. Mais il est très important d’avoir d’autres sortes d’incitations, comme des prix, des actions et des récompenses non financières. Chez Novell, nous avons créé le titre d’ingénieur émérite. Pour devenir un ingénieur émérite, il faut être élu par pairs »

Cette logique de l’honneur  apporte une solution élégante au problème que rencontrent toutes les entreprises qui emploient beaucoup de main d’œuvre très qualifiée. Comment offrir des perspectives à des ingénieurs de haut niveau sans multiplier les positions de management qui les éloignent de ce qu’ils savent le mieux faire et qui multiplient les dirigeants en réduisant les équipes techniques ?

Plus que motivant, ce concept est aussi gage de qualité
Ce contrôle par les pairs est, également, un formidable vecteur de qualité. Il favorise  le développement de la normalisation et des méthodes de qualité. Les échanges répétés, les discussions approfondies entre collègues sur des programmes favorisent naturellement l’émergence d’un langage commun. Toute tentative de développer en dehors des standards maison est immédiatement bloquée : on ne s’y risque pas, sachant que l’on ne passera pas l’épreuve, car les pairs refuseront un programme qui ne respecte pas la langue que tous parlent. Or, l’un des risques majeurs que courent les entreprises de logiciels qui innovent beaucoup est, justement, le développement de tours de Babel, de produits (qui ne communiquent pas entre eux avec tout ce que cela suppose de coûts supplémentaires).  Propriétaires de leur programme, jaloux de leur connaissance, les auteurs deviennent vile indispensables : eux seuls peuvent le faire évoluer et l’entretenir en cas défaillance. D’où des difficultés lorsque l’on veut modifier des équipes, lorsque l’on veut se séparer d’un collaborateur ou, plus simplement, lorsque l’on veut négocier des
augmentations de salaires.

Ce système implique une communication sans faille
Les peer reviews incitent également à développer de la documentation technique. Qui n’est pas informaticien ne mesure pas l’importance de ce travail : il consiste à décrire ce que l’on a voulu faire, à accompagner le code de commentaires. Traditionnellement, les programmeurs boudent cette activité qui prend beaucoup de temps (moi le premier ^_^). Ils en renvoient l’écriture à plus tard, ce qui signifie souvent à jamais. L’obligation que l’on a, dans une peer review, de montrer l’algorithme ou les programmes que l’on a écrits à des collègues impose de préparer cette documentation en même temps qu’on écrit le code. Ce qui est vrai de la documentation l’est des tests et de tout le processus de contrôle qualité: il n’est plus confié à des spécialistes, dans le cadre d’une division traditionnelle du travail, mais pris en charge par la communauté de travail elle-même.

Une organisation des projets corrigés
L’utilisation des peer reviews présente un autre intérêt: elle modifie la structure et l’organisation de manière subtile: elle force à simplifier, à découper le projet en segments de petite taille. Jamais des pairs n’accepteront d’examiner un programme trop long, qui leur prendrait trop de temps et leur demanderait un investissement trop lourd. On observe, dans le monde de l’édition scientifique, que cette technique est bien plus utilisée pour les articles que pour les livres. Cela pour un motif tout simple : l’investissement en travail de la part des réviseurs est plus faible. Incitant à découper le programme en lots de petite taille, ce mécanisme d’évaluation permet de mieux suivre son développement et de l’interrompre plus tôt s’il apparaît que le programme n’est pas satisfaisant.
Ce modèle a donc de sérieux avantages en termes de qualité, d’échange entre spécialistes et de gestion des produits. Il est très motivant. En effet et à l’inverse, ne plus être invité à participer à ces réunions est vécu comme l’annonce d’un prochain licenciement L . Ce système n’est cependant pas sans défaut, Il prend beaucoup de temps et d’énergie. Et il n’est pas à l’abri de dérives. Le système de Google se distingue du système en place dans le monde universitaire sur deux points  clefs : d’une part, il n’est pas anonyme et d’autre part,  les réviseurs, ces experts auxquels on confie l’évaluation des projets, se connaissent, travaillent souvent ensemble. Ce qui pourrait perturber les évaluations de chacun et empêcher des jugements complètement objectifs et impartiaux. « 

Article adapté d’un chapitre de : Une Révolution du Management : le modèle Google, MM2 Editions, 2006.

Découvrez aussi les sous-titres à télécharger

Télécharger le sous-titre français pour The 100. Le meilleur moteur de recherche de sous-titres disponibles en français et en anglais.
7 Commentaires (ajouter le vôtre)
  1. Bravo pour cet article intéressant et bien écrit, ça m’a donné bien envie d’acheter le bouquin. Si je le fais je passerai par ta boutique Zlio c’est promis! Vivement la suite …

  2. Excellent article tres complet. Tu évoques en fin d’article la notion de licenciment … on n’entend peut parler des licenciments de google mais ils doivent exister je pense …

  3. Je pense qu’il y en a aussi forcément. Je reviendrai prochainement sur les méthodes de recrutement de Google. Elles sont si complexes et pointues qu’elles doivent réduire le nombre de mauvaises embauches et donc de potentiels futurs licenciments…

  4. J’admire l’ingénuïté avec laquelle vous encensez tout de Google sans vous interroger sur ce que la constitution de cet empire représente comme menaces pour les libertés individuelles. Il ne s’agit pas de dire que les services de google sont mauvais, ni d’inviter à une posture réactionnaire anti-technologies. C’est évidemment une révolution impressionnante, que l’on ne peut négliger aujourd’hui.

    Mais tout de même, le développement de toute une batterie de services, requérant de la part de l’usager la remise à google de données de plus en plus systématiques et diverses sur sa personne (nom prénom, mail avec gmail, numéros de compte avec g-checkout, vie privée avec g-calendar et blogger, ses photos et vidéos avec picasa et youtube etc etc). D’autre part, le fait que ces données sont stockées presque ad vitam aeternam, et qu’elles sont convoitées par le gouvernement américain (cf. les recherches sur la pédophilie sur internet et les 50 000 url livrés par google aux autorités américaines, cf. l’affaire AOL des 600 000 listes de mots clés, cf. les liens avec la NASA pour G-earth, G-Moon, G-Mars), et déjà (cf. google et la CHine) ou bientôt d’autres, cela présente de réels problèmes pour la protection de la vie privée de l’individu, et par conséquent pour sa liberté. Mais ça, la "science" néopavlovienne du management n’en a pas grand chose à faire, n’est-ce pas ?

    En ce qui concerne ces "techniques de management"… je pourrais m’étendre sur des paragraphes et des paragraphes sur le déficit poétique et éthique d’une telle vision du monde, mais je n’imagine guère que ça aurait un quelconque écho sur ce site…

    Je vous invite à découvrir une prose un tout petit peu plus joyeuse et politique (c’est-à-dire, pardon éthique) sur notre site : agitlog.zeblog.com – la rubrique "geek empire / ubu web".

  5. je voulais savoir comment créer une unité de confection (céation de l’entreprise) avec l’un de vous ingénieur . merci

  6. comment créer une unité de confection. merci

  7. je veux devienne une ingenieur de google

© 2006-2017 Frédéric Cozic  
Propulsé par Wordpress sous licence Creative Commons