fbpx

Pénurie de développeurs ?

Derrière la mode des startups technologiques, le pari politique est souvent celui de résoudre la pénurie d’emploi en orientant de plus en plus de jeunes (et de moins jeunes) vers une carrière de développeurs en informatique. Les chiffres montrent en effet clairement qu’il existe de nombreux emplois dans « la tech » qui ne sont au final jamais pourvu, faute de candidat pertinent.

L’équation semble donc extrêmement simple : on a un secteur en tension avec de la pénurie de main d’oeuvre, et de l’autre côté un chômage qui reste pesant. La solution est simple : on va former « au code » !

Malheureusement, les choses sont, comme souvent, bien plus complexes dans la réalité, et il me semble important de faire un peu d’ordre dans ce gloubi-boulga idéologique.

Apprendre « le code », c’est important, mais…

Ce mouvement d’apprentissage du métier de développeur commence très tôt dans l’esprit des décideurs : il faut apprendre à coder dès l’école primaire, pour en faire une discipline aussi importante que le français, les maths, l’anglais…

Il est d’autant plus facile de souscrire à ce mouvement qu’il a l’appui de grandes sommités du numérique. Apprendre à coder est très structurant pour l’enfant, il y apprend la rigueur, l’esprit d’analyse, etc… tout en surfant sur un environnement qui peut apparaître plus attractif que les mathématiques. Et en plus on a une promesse de métier à la sortie !

Il me parait très important de bien dissocier :

  • d’un côté les bienfaits de l’apprentissage du code, qui effectivement apporte de grands bénéfices dans la capacité à analyser une situation, la structurer, y apporter de manière créative une solution, etc…
  • de l’autre côté la capacité de faire de ces « codeurs en herbe » des informaticiens qui vivront de leur travail

Mélanger ces deux aspects très différents est à mon sens aussi biaisé que le raisonnement (absurde) qui consisterait à se dire qu’on enseigne systématiquement les mathématiques pour pouvoir faire de la France un pays de mathématiciens. Dans les faits, très peu de gens font des mathématiques leur métier, et on croise souvent des discussions où les anciens écoliers restent très perplexes, en se demandant « à quoi ça m’a servi ? ».

Dans les faits, effectivement, 99% des gens n’auront jamais l’usage d’une bonne partie des notions mathématiques qu’ils auront appris à l’école. Et pourtant, cet enseignement reste indispensable, pas tant par ce qu’il apporte directement, mais par les effets beaucoup plus difficilement quantifiables dans la capacité de raisonnement, la possibilité qu’à l’être humain d’acquérir des savoirs-faire très subtils mais qui feront toute la différence entre un être complètement inculte et quelqu’un qui aura la « tête bien faite », et qui pourra s’en servir pour se sortir dans bien des situations.

On pourrait facilement rétorquer, à juste titre, que ce « savoir faire » et ce savoir-être n’est pas uniquement forgé par les mathématiques, mais également par bien d’autres disciplines, du français au sport en passant par l’histoire, et que de laisser « en silos » ces disciplines est une grande bêtise puisque l’humain va tirer profit de ces différents savoirs de manière bien plus transverses. C’est tout l’intérêt du paradigme des « arts libéraux » anglo-saxons (« libéraux » étant ici à prendre au sens « libérateur »), qui voient les choses de manière bien moins cloisonnée. Mais c’est un autre débat.

Pour en revenir à notre notion de code appris dès le plus jeune âge, il me semble important de ne pas le voir d’une manière « utilitaire » : peut-être que ces quelques sessions d’initiation permettront de faire naître quelques vocations, si ces initiations sont faites de manière correcte. Mais ça ne doit pas être l’objectif premier de ces moments, d’autant plus qu’il y aura vraisemblablement un fossé entre ce qu’on pourra apprendre aux jeunes enfants en 2020, et ce qu’utiliseront les informaticiens de 2040.

C’est donc l’esprit du code, bien plus que la lettre, qu’il faut maintenir à l’école, tout en se positionnant en fervents défenseurs de ce qu’il est possible d’amener aux enfants par ce biais.

(Cette façon de voir les choses aura également pour vertu de maintenir à l’écart certaines firmes commerciales, qui, de Apple à Microsoft, cherchent à refourguer leurs solutions payantes dans un système éducatif qui peut très bien s’en passer si l’on se souvient que l’important est d’apporter une logique aux enfants, pas une formation professionnalisante).

Pénurie de développeurs ? Oui, mais pas n’importe lesquels

Quiconque est un peu du métier ne peut que réaliser que le métier de l’informaticien se complexifie de plus en plus. Le développeur d’aujourd’hui, s’il utilise fondamentalement les mêmes notions qu’il y a 20 ans, a aujourd’hui besoin d’infiniment plus de savoir pour pouvoir proposer une prestation au niveau des besoins des employeurs. L’industrie amène d’ailleurs à se spécialiser de plus en plus, car il est tout simplement impossible à un unique bonhomme de maîtriser toutes les notions indispensables à un tel travail.
On va tout droit vers un système de spécialisation qui ressemble pas mal à ce qu’on connaît depuis longtemps en médecine : certes, il reste des médecins généralistes, donc le rôle est de servir la proximité avec le patient, régler les problèmes les plus courants, et le rerouter vers le spécialiste le plus pertinent en fonction des problèmes plus pointus à régler. Mais on n’irait certainement pas confier son oeil à un dentiste, ou un problème cardiaque à un ORL.
L’informatique du point de vue de la main d’oeuvre s’organise de plus en plus de cette manière là, et les spécialités sont de plus en plus pointues et nécessitent des compétences qui sont rares, en particulier dans les nouvelles spécialités créées autour de technologies récentes (au hasard et pour rester dans des domaines très tendances, les « data analysts » et experts en big data qui s’appuient souvent sur des technos en pleine évolution).
Le constat est donc le suivant, et il n’est malheureusement pas très compatible avec les actions actuellement en place : oui, de nombreuses entreprises cherchent des recrues et ne les trouve pas. Mais si elles ne les trouve pas, ça n’est pas parce que le marché manque d’informaticiens employables. Elle ne les trouve pas parce qu’elle ne trouve pas de développeurs suffisamment pointus dans un domaine très précis.
C’est ainsi qu’on se retrouve avec, dans le même temps, des postes non pourvus de plus en plus nombreux, et de l’autre côté des informaticiens débutants, qui ont un savoir généraliste et qui font ce qu’ils peuvent en tant que débutants, mais qui ne répondent en rien aux besoins pointus des offres non pourvues.
Ainsi, tenter de résoudre le problème de l’emploi en formant à la va-vite des chômeurs en reconversion, dans la promesse de les amener « au code » qui va résoudre leurs problèmes, ne peut amener que pas mal de déceptions. Le métier est exigeant, et nécessite une adaptation et un investissement qui très souvent dépasse le simple fait de suivre une formation de quelques semaines.
N’interprétez pas mal mes propos : je ne dis en aucune manière que la piste de l’emploi par le biais de l’informatique est une mauvaise piste. Mais il faut sans cesse rappeler que la problématique est complexe, et que le chemin pour parvenir à l’emploi par ce biais nécessite un investissement très important, et quelque part une passion pour la discipline, sans laquelle on risque de se heurter à pas mal de murs, ou a être très malheureux dans son emploi.

L’informatique peut être une discipline très exaltante pour quiconque s’y trouve une passion, tout en étant dans le même temps une activité horrible pour celui qui n’y trouve pas le feu sacré. De la même manière que si avoir des bases mathématiques est très structurant pour tous, envisager le métier de mathématicien pour tous serait être très méprisant pour la personnalité de chacun.

La vague de fond du freelance

A peu près tous les recruteurs en informatique que j’ai pu rencontrer se heurtent de plus en plus à un problème qu’ils n’avaient pas prévu : trouver la compétence rare est une tâche ardue. Mais les vrais ennuis démarrent lorsqu’ils réalisent que les « perles rares » ont de plus en plus souvent une exigence inattendue : celle de pouvoir travailler « en remote », en télétravail donc, ou, encore pire, celle de n’être pas salarié mais d’intervenir en tant que travailleur indépendant.

Ces discussions sont souvent suivies d’une certaine condescendance pour cette démarche : la génération qui vient est bien capricieuse, on leur propose sur un plateau un poste dans un job qui les passionne, avec des missions bien adaptées, souvent un bon salaire et de bonnes conditions de travail (et même parfois un baby-foot !), et ils ne sont pas contents !

On peut épiloguer sans cesse sur la génération X, Y ou Z ou je ne sais quelle lettre, ou encore tenter de théoriser cette tendance au « slash » (tous ces gens qui ont plusieurs activités, par exemple « développeur/entrepreneur »). Mais les faits sont là, et n’ont rien d’un scoop ; c’est même une redite de ce qui se fait depuis toujours : les moeurs évoluent, les tendances aussi, et le positionnement de l’entreprise par rapport à sa main d’oeuvre est sans cesse à réinventer. Comme on a dû le faire à plusieurs reprises ans le passé. Comme l’ont fait nos anciens à l’issue de la 2ème guerre mondiale, ou à l’ère de la révolution industrielle. Est-ce une bonne, une mauvaise chose ? Je ne le sais pas. Mais tenir compte des envies de chacun et avoir la capacité de s’y adapter me semble un facteur indispensable pour pouvoir constituer sa « dream team » de barbus, l’équipe qui permettra de relever les défis du numérique.

On fait quoi chef ?

Comme d’habitude, ne pas rentrer dans des clichés. Ne pas chercher à simplifier à outrance une situation qui est nuancée, et qui nécessite une connaissance un peu poussée du secteur. Ne pas croire aux solutions miracles. Ne pas jeter le bébé avec l’eau du bain, et rejeter ce qu’on a encensé : le plus souvent, les deux réactions sont équitablement insensées. Et, malgré tout, se souvenir que le code peut être une activité passionnante et formatrice, dès lors qu’elle est exécutée dans le bon contexte, avec le bon entourage et des objectifs à la fois ambitieux et réalistes !

Pourquoi Yahoo avait stoppé toute expérimentation de télétravail (et pourquoi c’était une connerie)

Lorsque Marissa Mayer, une ancienne de Google, a repris les rennes du vaisseau Yahoo, elle a lancé toute une série d’actions, certaines pertinentes, d’autres beaucoup moins, pour restructurer à son idée la firme historique du web.

Une de ses premières actions a été d’auditer les « remote », ces salariés qui travaillaient de chez eux, à temps plein ou à temps partiel. Bref, en bon français des « télétravailleurs ».

Et elle s’est rendu compte que ces salariés là interagissaient beaucoup moins avec leurs collègues pendant ces périodes à distance. Les échanges mail ou messagerie instantanée étaient bien moins nombreux, et on prenait le risque de laisser ces acteurs là dans l’isolement. L’analyse était claire : ces gens là travaillaient moins, et étaient bien moins efficace, puisque les chiffres montraient de manière limpide qu’ils intervenaient moins.

La sanction fût immédiate : ordre a été donné de rapatrier ces troupes bien peu actives à la maison mère, pour qu’ils puissent réintégrer les équipes.

Cette action est l’exemple parfait d’une erreur d’interprétation grave, et aussi l’illustration que la mesure étalon du travail en entreprise devient de moins en moins le travail accompli, mais plutôt le nombre des contributions dans les échanges entre collaborateurs. Quelqu’un qui envoie peu de mails devient suspect. Quelqu’un qui participe à peu de réunions encore plus.

Qui n’a pas connu ça : le meilleur moyen, dans une entreprise, de calmer une frustration ou une culpabilité de type « il faut agir » reste encore d’envoyer un mail, ou, encore mieux, d’amorcer une réunion.

Le vrai secret du télétravail, c’est qu’il permet de se concentrer sur ce qui devrait être la vraie valeur ajoutée d’un collaborateur d’entreprise : ce sur quoi il est capable de se concentrer, d’exécuter par lui-même. Quelque chose qui vienne de lui, et pas d’un échange.

Je ne dis certainement pas là que l’échange est inutile, ou que le travail collaboratif n’apporte rien. Mais force est de constater que la force centrifuge d’une entreprise va vers un fonctionnement où parvenir à se concentrer, se fixer un focus sur une tâche, exécuter quelque chose d’un point A à un point B, devient de plus en plus une activité que l’on doit presque exécuter « malgré » l’entreprise, quasiment de manière clandestine, en venant plus tôt le matin, en créant des rendez-vous bidon sur son emploi du temps pour se préserver du temps, ou… en travaillant de chez soi.

Bien sûr que le télétravail amène quelques complications sur les interactions entre collaborateurs, et qu’il n’est pas toujours facile de maintenir un lien fort entre des troupes dispersées géographiquement – même si de plus en plus d’outils et de méthodes permettent de faire ça efficacement. Mais permettre à un salarié de pouvoir se concentrer sur les tâches qu’il a à accomplir, lui donner la possibilité de travailler confortablement pour exécuter quelque chose sans être sans cesse interrompu, doit être considéré comme une des grandes vertus du télétravail, et pas comme l’a fait Marissa Meyer comme un signe de manque de productivité ou d’inclusion dans l’entreprise.

Le miracle de l’effet démo

Notre monde professionnel vit dans un monde “co-” : la co-construction, le collaboratif, l’idéal d’une entreprise plus humaine passe aujourd’hui par un travail commun, où chacun collabore avec son voisin pour obtenir des projets où “le tout est meilleur que la somme des parties”. Mais peut-être a t’on oublié dans toute cette vague de bons sentiments que la stimulation intellectuelle, la motivation, la créativité, passe parfois plus par la mise en concurrence que par une démarche où l’on travaille main dans la main, certes avec de très belles valeurs humaines, mais aussi avec des nécessités de compromis, de gestion de groupe pas forcément compatibles avec la démarche créative de chacun. Et si l’on réintégrait des notions de compétition, de concours, où l’esprit de conquête, les conditionnements de survie, le réflexe presque reptilien de l’humain, jouent un rôle de puissant moteur ?

Vers un process de sélection créative

J’ai dévoré récemment un livre découvert complètement par hasard : “Creative Selection : inside Apple design process during the golden age of Steve Jobs“. Il ne s’agit pas du tout d’une n-ième biographie de Jobs, où l’on détaille son caractère de cochon et son éventuel génie, mais d’un témoignage de l’intérieur, très opérationnel, d’un développeur logiciel ayant travaillé chez Apple durant la période 2000-2010. Et c’est passionnant.

Passionnant car on découvre le dessous de la création de certains des outils que l’on a sous la main au quotidien aujourd’hui. De longs chapitres sont par exemple consacrés à la conception du clavier de l’iPhone. Cela pourrait paraitre complètement anodin et peu excitant, mais c’est le mode opératoire qui a permis d’inventer cette fonction qui est très intéressant à étudier.

Une utopie plus qu’une vision

Première leçon : la démarche commence sans génie visionnaire, mais une vision stratégique pas forcément très maîtrisée. La démarche ayant amené à concevoir un tel clavier a été stimulée par deux paramètres :

  • Tout d’abord, le constat que les claviers de smartphone étaient très peu pratiques. Le Blackberry, qui dominait à cette époque, permettait une saisie via un clavier physique qui nécessitait pas mal de technicité pour pouvoir l’utiliser correctement
  • Ensuite, le design : la décision de passer par un objet qui serait essentiellement un grand écran tactile, sans boutons physiques, a été prise très tôt. S’il y a une “vision” de la part de Jobs et Jonathan Ive, son designer, c’est celle-ci : l’utopie d’un écran interactif, comme on peut en voir dans 2001 l’Odyssée de l’Espace. Mais cette utopie n’est malheureusement pas fournie avec sa solution technique !

Un management minimaliste

La seconde leçon apprise dans l’ouvrage est la façon dont l’équipe en charge de la conception de l’iPhone était constituée, et gérée :

  • l’équipe était minuscule : on est très loin ici d’un projet éléphantesque, et les managers avaient en réalité plus en charge de synchroniser les différentes tâches que de “manager” de l’humain : d’après le récit qui est ici fait, on constate que le seul moment où l’humain est “géré” est au moment du recrutement : qui est choisi pour intégrer l’équipe, selon des critères assez nébuleux par ailleurs
  • Les personnes sélectionnées pour intégrer ce style d’équipe le sont pour un point commun : leur capacité a explorer, à creuser des pistes, de manière très autonome. L’auteur du livre avait fait ses preuves chez Apple en concevant quasiment seul la première version de Safari, le navigateur web sorti sur Mac au début des années 2000. Pour ce projet de navigateur, l’équipe ne s’était étoffée qu’après avoir atteint la capacité de faire une démonstration en interne du produit
  • Plus surprenant, le sens de l’empathie est très clairement mis en avant, largement au delà des capacités techniques des membres de l’équipe. On pourrait imaginer qu’avec le caractère dictatorial d’un Jobs, la valeur même d’empathie soit fort éloignée des développements, elle était au contraire au cour du projet : toujours se mettre à la place de l’utilisateur, et tout faire pour qu’il ait l’expérience la plus agréable, la plus simple, la plus valorisante possible.
  • La conduite de projet est ensuite largement informelle. Quasiment aucune réunion formelle, pas vraiment de cahier des charges, juste le souhait de satisfaire une vision, avec des temps forts cruciaux : les démonstrations (on y reviendra plus tard).

Tâtonnements et compétition

La troisième leçon est celle des tâtonnements, et de l’esprit de compétition en interne, qui ont permis ensuite d’amener le vrai caractère “génial” de l’outil.

Quand Ken Kocienda, l’auteur de l’ouvrage, a intégré l’équipe en charge de la conception de l’iPhone, ou plutôt du “project Purple” comme il s’appelait à l’époque, il n’avait pas d’idée précise de comment gérer une interface tactile. A vrai dire, personne n’avait cette compétence à l’époque, et personne n’avait encore vu de clavier suffisamment “smart” pour pouvoir être utilisé au quotidien.

Lorsqu’il est clairement apparu que le clavier constituait le problème le plus complexe à résoudre, la petite équipe a eu pour ordre de se focaliser entièrement sur cette problématique.

“A partir de cet instant, vous êtes tous les ingénieurs en conception de clavier”.

En effet, il était clairement apparu que le projet n’avait aucun sens d’un point de vue utilisateur s’il ne parvenait pas à résoudre la contrainte extrêmement forte donnant le ton du projet : parvenir à fournir une expérience utilisateur supérieure aux téléphones avec clavier, sans fournir aucun clavier physique, ni périphérique de saisie autre que le doigt.

Brainstorming vs compétition interne

Un des témoignages les plus surprenants dans ce livre est l’absence quasi systématique de “brainstorming” chez Apple : l’auteur explique qu’il n’a quasiment jamais vécu de telles réunions pendant toute sa carrière dans la firme. La “sélection créative”, titre de l’ouvrage et leçon principale décrite par l’auteur, passe par une vraie mise en compétition des différents membres de l’équipe, sous forme d’échéance forte : celle d’une démonstration à faire devant le top management, et en particulier devant Steve Jobs.

La compétition par la démonstration

Les geeks des années 90 se souviennent sans doute du phénomène des “démos” : ces compétitions, en temps limité, étaient des événements où chaque équipe devait faire la preuve de ses capacités techniques et créatives, en développant en quelques heures une “démo”, qui n’avait pas vraiment d’utilité, mais qui devait être l’occasion d’explorer, d’expérimenter, et ce dans un esprit de compétition assumé puisque ces événements amenaient ensuite des vainqueurs, des prix, etc… Pour autant, cet esprit de compétition était largement complété par une “fraternité” de la communauté des démo-makers, qui prenaient ensuite plaisir à expliquer leurs “trucs” et s’échanger les astuces qui permettaient ensuite de réhausser encore le niveau lors de l’événement suivant. Cette façon de faire, qui s’appuie sur des stimulis humains très proches de la compétition sportive, a permis d’amener ces communautés dans de très hautes sphères techniques : des concepts incroyables sont apparus lors de ces événements, poussant le matériel à l’extrême, et contribuant largement à la création de jeux et de technologies extrêmement innovantes.

Aujourd’hui, la façon de faire au sein des entreprises passe beaucoup plus par ces concepts issus du collaboratifs : on met des têtes bien faites dans une pièce, et on leur demande “d’être innovants”. Mais ce témoignage de l’Apple des années 2000 m’a rappelé que d’autres modes de fonctionnements, plus liés à la compétition interne, existaient, et pouvaient être des plus fertiles.

Lors de la conception du clavier de l’iPhone, chacun amenait son idée, mais aussi sa réalisation ; et les différents concepts ainsi réalisés étaient ensuite tout simplement présentés successivement, comme autant de candidats, à la personne tenancière de la “vision” produit, à savoir Jobs lui même. Qui, lors de ces présentations, était finalement assez éloigné de l’image qu’on se fait de lui : certes impitoyable dans ses jugements, mais aussi calme, ouvert aux suggestions, concentré, focus dans un unique but : celui de se mettre à la place de l’utilisateur.

Plusieurs éléments clés étaient réunis pour que ce mode de fonctionnement puisse aboutir :

  • une personne clé ayant le pouvoir d’arbitrer entre les différentes solutions proposées, et ayant l’aura d’une crédibilité sans faille pour le faire (personne ne se serait amusé à contester les choix finaux du grand chef)
  • une grande ouverture d’esprit de la part de toute l’équipe, y compris du décideur : avoir la capacité d’une lucidité permettant d’accepter un arbitrage plutôt que de défendre jusqu’à l’absurde un postulat de départ
  • un processus itératif et une grande disponibilité de chacun : il n’y avait pas une grande démo unique, mais plutôt toute une séquence de démonstrations successives, espacées de quelques jours, pour converger vers une solution validée
  • un focus absolu : tous les autres sous-projets ont été gelés tant que cette problématique de clavier n’avait pas été résolue
  • et, sans doute le point le plus important : chaque ingénieur ainsi mis en situation de compétition est amené à ensuite passer sur une phase beaucoup plus collaborative, où chaque bonne idée d’un projet est reprise dans une version future hybride d’un autre projet.

Fusion de concepts et itérations

La deuxième version du clavier, avec dictionnaire intégré mais répartition des touches un peu déconcertante… l’exploit technologie n’est pas encore passé au crible de l’élégance du design

Les différentes phases de conception du clavier de l’iPhone sont décrites en détail, et c’est complètement passionnant. Je ne vais pas pouvoir paraphraser toutes ces étapes ici, mais en voici les grandes lignes :

  • Le premier clavier de Ken était une sorte de “clavier blob”, où chaque touche était en forme de blob et permettait de choisir entre plusieurs touches, un peu comme les claviers T9 des premiers téléphones. Cette version était très laborieuse et peu utilisable
  • La deuxième version introduisait la notion de dictionnaire : chaque “touche” représentant plusieurs lettres, mais des suggestions étaient ensuite affichées, en devinant à partir des différentes combinaisons de lettres quels mots étaient tapés au clavier. Cette version avait enthousiasmé le VP tech (Scott Forstall), mais beaucoup moins le VP marketing, qui trouvait ce clavier à plusieurs lettres par touche peu intuitif
  • Une troisième version permettait d’avoir un vrai clavier QWERTY, familier pour l’usager, en y associant des prédictions sur les zones tapées par l’utilisateur. Cette version était un hybride avec un autre développement, un “jeu” ayant pour but de faire des statistiques entre ce que l’usager pensait “toucher”, et ce qu’il touchait vraiment à l’écran.
  • Les itérations suivantes ont surtout concerné la qualité du dictionnaire, et la mise en place de notion de priorité : le mot “egg” par exemple doit être proposé prioritairement au mot “eff”, qui utilise les mêmes zones de touches, mais qui est beaucoup plus rare.

Toutes ces étapes peuvent apparaître évidentes aujourd’hui. Mais il ne faut pas oublier que l’on partait d’une situation où personne n’avait vu fonctionner un clavier complètement tactile, ni même imaginé que cela puisse être possible.

Le courage de jeter

La dernière grande évolution a été la plus spectaculaire, et pourtant n’a nécessité que quelques minutes de développement. En discutant avec un de ses collègues (être focus permet d’avoir une forme d’obsession sur un sujet, remplissant ainsi toutes les discussions, et comme souvent, les meilleures idées émergent au détour d’une discussion à la machine à café), Ken a tenté une expérimentation : supprimer la barre de suggestions de mots, pour la remplacer par l’insertion automatique du mot à priori le plus pertinent. A la grande surprise de Ken et de son collègue, cette simple modification a permis d’obtenir immédiatement une expérience utilisateur parfaitement fluide, avec une saisie très naturelle et sans aucune interruption, telle qu’on la connait aujourd’hui.

Avant cette modification, il était nécessaire de sélectionner manuellement chaque mot parmi une barre de suggestion. Cette barre de suggestion avait fait l’objet de nombreux développements, et avait nécessité beaucoup d’efforts. La supprimer était une opération très simple, mais qui nécessitait beaucoup de courage : cela impliquait de faire son deuil de tous les efforts consacrés à cette fonction, et aussi de la lucidité : parvenir à repérer les fonctions qui se justifiaient dans le passé, mais qui n’avaient plus de sens.

Focus et cloisonnement

Apple est connu pour sa culture du cloisonnement : les ingénieurs du software de l’iPhone ne connaissaient quasiment rien du hardware qui allait être utilisé au final, et découvrirent le nom du produit que lors de la keynote de présentation. Quant à la majorité des employés Apple, ils n’avaient tout simplement aucune idée de la nature du projet ainsi porté, n’ayant comme seule information, ou plutôt rumeur, que “quelque chose de grand” était en préparation dans des quartiers hautement sécurisés.

Au sein de l’équipe même, ce cloisonnement était appliqué sous forme de focus en très petites équipes : une fois le brouillard levé autour de cette problématique de clavier, et la meilleure solution choisie, Ken, son principal concepteur, fût désigné comme allant porter jusqu’au bout la conception du clavier, et il allait le faire… seul. Chaque membre de l’équipe était ainsi assigné à un sous-ensemble du projet Purple de manière très précise, les cadres du projet étant en charge d’orchestrer les différentes équipes, et d’amener le projet vers une phase finale dite “de convergence”, où les briques étaient assemblées entre elles. Cette façon de faire, jouant sur la capacité à chacun de s’approprier un sujet jusqu’à l’obsession, a permis d’avoir des briques extrêmement peaufinées, même si cela amenait de gros problèmes lors des étapes de fusion techniques entre ces différentes briques.

L’obsession de la simplicité

On l’a vu, le rôle des ingénieurs en charge du projet est déterminant : si la vision d’origine, et le choix final parmi les options proposées relève des dirigeants, et de Jobs en particulier, tout ce qui fait la différence entre un concept utopique et un outil cohérent et peaufiné dans les moindres détails relève des contributions de chacun des membres de l’équipe, stimulés et motivés par ces fameuses sessions de démonstration. Mais si un point est typiquement “Jobsien”, c’est l’obsession de la simplicité.

Au début du livre, Ken parle d’une autre expérience de conception de clavier, cette fois-ci pour l’iPad. Deux concepts s’opposaient :

  • Un clavier complet, avec les symboles, fonctions, etc ; c’était rendu possible par la taille de l’écran de l’iPad
  • Un clavier simplifié, avec des touches plus grosses

Les deux usages avaient du sens, et Ken avait conçu, en pleine coordination avec Bas Ording, le principal designer d’interface du projet, une animation sophistiquée permettant, en un bouton, de passer d’un clavier à l’autre. Lors de la démo, cette animation donnait un cachet tout particulier à cet écran, et Jobs passa de longues minutes avec le bouton permettant de passer d’un clavier à l’autre.

Son intervention à l’issue de cette démo se limita à deux phrases, dites très calmement et avec une interaction très forte avec le démonstrateur, les yeux dans les yeux :

  • “bon, j’imagine qu’il serait mieux de choisir entre ces deux claviers”
  • “vous qui avez conçu ces claviers et qui les utilise au quotidien, lequel utilisez-vous de préférence ?”

Ken pensait avoir la solution avec ce bouton permettant de “switcher” avec élégance, et ainsi de contenter deux types d’utilisateurs. Mais Jobs ne l’entendait pas ainsi. Ken utilisait plus naturellement le clavier simplifié, et c’est ainsi que tout le reste fût jeté à la poubelle.

Cette démarche est très “Jobsienne” au sens où elle caractérise tout ce qui fait qu’un produit Apple est cohérent : la simplicité extrême, assortie d’une absence de choix. C’est à la fois la plus grande force et le plus grand reproche fait aux produits Apple ; une simplicité poussée à l’extrême jusqu’à l’obsession, et l’abandon de nombreuses fonctionnalités, et en particulier de fonctions de personnalisation, au profit de cette simplicité. Et c’était ainsi que Jobs voyait son rôle dans le projet : à être l’infatigable avocat de cette simplicité.

Autres temps…

Ken présente cette démarche comme étant la représentation de l’intersection entre la technologie et les arts libéraux, un des mantras de Jobs (il présenta ce concept lors de la keynote présentant l’iPad) : il ne s’agit pas de simplement faire des outils technologiques, mais de les placer à la parfaite intersection entre ce qu’il est possible de faire techniquement, et ce qui est le mieux pour accompagner une démarche où l’on se “libère” de la technologie pour ne la mettre qu’au service de l’accession à la culture, à la créativité, etc. On pourrait également évoquer la loi de Pareto des 80/20, où, appliqué à l’informatique, 80% des utilisateurs n’utilisent que 20% des fonctions : l’idée est donc ici de s’adresser à ces 80% d’utilisateurs, quitte à se faire détester des 20% autres, mais pour que le façon dont est conçu le design d’un produit ne soit pas alourdi par ces 80% de fonctions qu’on va mettre à la poubelle avec cette démarche.

(A noter que cette démarche d’une simplification à l’extrême a largement été amendée après la mort de Jobs : que celui qui maitrise parfaitement toutes les gestuelles de l’iPad pour le multitâches me contredise…).

Une conduite de projet radicale, mais fertile

Toute la démarche de créativité sélective présentée dans cet ouvrage est une source d’inspiration immense, ne serait-ce parce que les concepts qui y sont présentés vont souvent à contre-courant de ce qu’on pratique habituellement de nos jours.

Mais le plus impressionnant reste encore l’impact que peut avoir ce genre de démarche, finalement très artisanale, sur un projet immense : Ken explique que son principal motif de fierté est à moment de vie très précis : lorsqu’un avion atterrit, et que les passagers dégainent leur téléphone pour envoyer à leurs proches quelques mots pour les assurer que tout s’est bien déroulé pendant le vol. Certes, un simple objet conçu comme un projet purement technologique permettrait de faire ce genre d’opération, mais quiconque travaillant sur l’expérience utilisateur sait que c’est sur ce travail d’intersection entre la technologie et l’humain, l’empathie, les sciences heuristiques, qu’un bon outil peut devenir un objet prenant toute la place dans la vie des gens.

Comme du sucre dans le lait chaud

Le numérique se décline à toutes les sauces (ne me dites pas digital !). Sans numérique, pas d’innovation. Fracture numérique, source de tous les maux. Startup du numérique, qui ringardise l’entreprise. Enfin, c’est ce que l’on se dit.

Cette obsession pour le numérique n’est (presque) pas injustifiée, tant l’impact est fort. Jamais une révolution ne s’est diffusée aussi rapidement. Rares sont les métiers qui ne sont pas concernés. Et nombreuses sont les étapes à franchir pour moderniser usages, organisations et process, grâce à l’informatique, à Internet.

Un réflexe me semble toutefois antiproductif : traiter le numérique comme un nouveau dossier, un silo supplémentaire.

J’aime beaucoup proposer l’exercice suivant à mes interlocuteurs : lorsque l’on parcoure un document listant les grands projets que l’on va accomplir dans le domaine du numérique, je suggère de remplacer le mot « numérique » par « électricité ». Car, pour moi, le numérique a destination à devenir aussi courant, aussi banal, et aussi indispensable que l’est l’électricité. Et de la même manière qu’il ne viendrait plus à l’idée de personne de parler d’un projet comme étant lié à l’électricité, il faut faire en sorte que le numérique infuse partout, dans tous les services et dans toutes les cultures.

Il serait par exemple stupide de traiter les nouveaux usages amenés par le numérique comme n’impactant que l’avant-vente : lorsqu’un client attend de votre entreprise qu’elle réagisse avec la même souplesse et la même rapidité que les services qu’il utilise au quotidien sur Internet, il serait vain de ne changer les modes de fonctionnement d’un seul service de votre entreprise.

De l’avant-vente à l’après-vente, de la production jusqu’au marketing, c’est partout que le numérique et ses usages doit prendre sa place. Sans dogme, sans excès ou délire utopique. Mais partout. On le perçoit à tout moment, sans forcément pouvoir l’identier clairement. Comme l’électricité. Comme le sucre dans le lait chaud !

L’effectuation dans la pratique

Cet article est la suite d’un premier article qui vous présentait le principe d’effectuation. Si vous ne l’avez pas encore lu, je vous conseille de commencer par celui-ci.

Résumons : nous avons donc posé les bases de la philosophie même de l’effectuation : ne pas attendre que le projet parfait vous tombe entre les mains, mais tirer profit de ce que l’on a sous la main pour pouvoir explorer des terrains jusqu’aux plus inattendus…

Accueillir les surprises

Vous commencez à le comprendre, cette façon de fonctionner fait beaucoup pour agrandir l’étendue du possible, et faire en sorte que des choses surprenantes puissent survenir. De toute manière, soyons honnêtes, n’importe quel projet apporte son lot de surprises. La différence est qu’ici elles sont non seulement bienvenues, mais même attendues. De la même manière que les méthodes agiles font en sorte d’intégrer l’impondérable, on va travailler ici de manière empirique :

pourquoi se raconter la fable d’un projet qui se déroulera sans accroc, et baser sa conduite de projet sur cette pensée magique, alors qu’il est finalement bien plus logique et sain de conduire dès le premier jour son projet en anticipant que ça va être le bazar.

Mais, on l’a vu, l’effectuation va quelque part encore plus loin que le lean puisqu’il n’y a pas ici vraiment de projet initial, mais plutôt une exploration de l’étendue du possible. Et c’est pourquoi les surprises sont particulièrement bienvenues, car ce sont finalement elles qui vont impulser vos actions. Les théoriciens de l’effectuation résument cette étape clé par cet exemple : “si on vous donne des citrons, vendez de la limonade !”.

Une opportunité inattendue, un feedback client, un accident de parcours, n’importe quel élément peut nourrir cette sérendipité !

Le chaos ? Oui, mais organisé

Tout ce qui a été décrit précédemment peut faire peur : on part sans projet, la fleur au fusil, on se laisse guider par des feedbacks qui peuvent être des plus inattendus, difficile au premier abord d’imaginer quelque chose de cohérent, de solide en faisant cela.

Et pourtant… cherchons à comparer une démarche classique, et la démarche d’effectuation :

  • dans une démarche classique, on part d’un projet, qui quelque part s’apparente à une vision : on émet des hypothèses de succès à long terme, puis on jalonne les étapes permettant d’y parvenir
  • avec l’effectuation, on part du recensement des forces en présence, et on se met de manière intense à l’écoute de son environnement pour “prendre la vague” d’une opportunité
  • dans un projet classique, on passe beaucoup de temps et d’énergie à résoudre les problèmes permettant d’accéder à l’objectif final, en particulier lorsque le projet a été imaginé sans tenir compte de ce que vous avez déjà à disposition
  • avec l’effectuation, l’énergie passée l’est pour nourrir des partenariats et accrocher des opportunités plutôt qu’à résoudre des problèmes pour parvenir à un objectif
  • gros point positif d’un projet “classique” : partager une vision permet de fédérer une équipe, de la motiver dans un but commun
  • dans le cadre de l’effectuation, le flou peut décourager ou faire peur. Mais l’adrénaline d’exécuter rapidement une action relative à une opportunité est le vrai carburant d’une équipe ainsi formée

Pour être clair : l’effectuation n’est pas une façon de procéder adaptée à toutes les situations.

Pour des projets lourds, les conduites de projet classiques sont robustes et ont fait depuis longtemps leurs preuves. Pour des projets nécessitant de la souplesse et de l’adaptation, tout en ayant un objectif fixé à l’avance, les méthodes agiles et le lean s’avèrent redoutablement efficaces.

Je pense qu’il faut plutôt voir l’effectuation comme une autre voie possible, un outil supplémentaire que l’on peut dégainer lorsque les circonstances s’y prêtent.

  • avant tout, l’absence d’un projet fédérateur : ça ne doit pas être vécu comme un point rhédibitoire, puisque des voies existent
  • l’opportunité de ressources ou d’une équipe déjà sous la main mais sous-utilisés
  • la volonté de découvrir un nouveau marché, ou d’explorer un terrain vierge

Enfin, il faut avoir conscience que ces façons de faire peuvent faire peur ou décourager certains, et au contraire stimuler de manière très puissante d’autres : il est donc indispensable de jauger l’état d’esprit des forces en présence avant de se lancer dans de telles aventures.

En revanche, je ne peux que vous inviter à expérimenter l’effectuation, à l’occasion d’une période de creux, que ça soit à titre personnel (vacances, chômage…), ou professionnel (inter-contrat ou creux dans son coeur de métier).

Envie d’expérimenter ? Parlons en ! J’ai eu l’occasion de pas mal expérimenter, et d’accompagner des équipes dans des expériences d’effectuation. Rejoignez nous dans l’exploration de ce nouvel univers !

Le Lean ne vous suffit plus ? Tentez l’effectuation !

Gros sujet aujourd’hui : lorsqu’on entreprend, en particulier dans un domaine qui exige de l’innovation, on se rend rapidement compte que des méthodes “classiques” de conduite de projet ne sont pas adaptées. On ne peut pas se contenter de s’organiser avec l’hypothèse que tout va se passer de manière linéaire, d’un point A à un point B.

La réalité est beaucoup plus chaotique et imprévisible. Se pose alors la question : faut-il renoncer à toute forme d’organisation, et laisser voguer le navire, ou bien chercher de nouvelles idées pour amener, de manière empirique, un cadre à ce qui peut s’apparenter à un joyeux foutoir ?

Lire la suiteLe Lean ne vous suffit plus ? Tentez l’effectuation !

Better done than perfect

J’ai croisé à de multiples reprises des projets qui stagnaient, ne parvenant jamais à respecter une date de sortie, sous prétexte de vouloir atteindre la perfection avant de sortir vraiment du bois.

Bien sûr, l’objet de ma réflexion du jour n’est pas de mettre en ligne n’importe quoi, ou de fournir au client des versions complètement buggées de ses outils.

Mais il ne faut jamais oublier une chose : dans le monde virtuel du numérique, rien n’est figé. Si une maison, une voiture est mal conçue, “buggée”, il y a de fortes chances que cela va entraîner de lourds travaux, et parfois remettre en question l’ensemble du projet.

Ce genre de situation est rare dans le domaine du numérique. Essayer, puis revenir en arrière, est le lot de tous les développeurs. Dans certaines méthodologies de conduite de projet, on enseigne même le “courage” de jeter du code, qui a deux vertus :

  • déjà, on s’est assuré d’avoir essayé
  • jeter puis réécrire, c’est s’appuyer sur son expérience pour refaire proprement, plutôt que de bidouiller un existant
  • enfin, on utilise la souplesse du numérique pour se dire que jeter n’est pas très coûteux ; dans des cycles de développement agile, on parle d’une journée au maximum.

Une perfection utopique

Se dire qu’on va atteindre la perfection lorsqu’on aura parfaitement exécuté un cahier des charges, c’est se fermer les yeux sur une composante essentielle : le feedback utilisateur.

Un cahier des charges n’est souvent qu’un ensemble d’hypothèses faites sur la potentielle adaptation d’un outil à un utilisateur. On peut tenter de s’approcher d’une forme de vérité en impliquant un maximum d’utilisateurs dès les phases de conception (c’est même fortement conseillé) ; en revanche, même avec une implication maximale, il y a fort peu de chances que l’on parvienne à l’outil idéal dès sa première version. Parce qu’on n’est jamais exhaustif. Parce que l’utilisateur n’a forcément qu’une image imparfaite de l’outil tant qu’il ne l’a pas entre les mains.

Ce constat pourrait être affolant. Plutôt que d’affoler, il est souvent ignoré, en rejouant pour la n-ième fois la comédie du cahier des charges parfait. Mais il pourrait bien mieux être pris en considération en appliquant le principe du “mieux vaut fait que parfait”.

Rome ne s’est pas faite en un jour

Facebook était loin de ressembler au Facebook actuel lorsqu’il est sorti dans sa première version. Il était très loin d’être parfait, ni même très conforme à l’idée même d’un réseau social puisqu’il n’était qu’une esquisse, codée à la va-vite sur un coin de table, pour noter le physique des filles de l’université où était Mark Zuckerberg.

Windows était loin d’être parfait dans sa version 1.0. Il était même catastrophique.

On pourrait reproduire ces exemples à l’infini. Et surtout les décliner à d’autres univers que celui de la création logicielle. N’importe quel Youtubeur vous dira que leur première vidéo était catastrophique.

Mais il y a un principe important : Ne jamais publier sa première vidéo, ou son premier jet, ou clore un projet dans sa première version sans attendre la perfection, c’est aussi ne jamais se donner la chance de faire un deuxième jet, une deuxième version qui tirera des leçons de la première. Et ainsi de suite.

Lorsque j’ai eu l’occasion de travailler avec des grosses structures, des administrations, je m’attendais souvent avec crainte à des organisations pesantes, à des processus tuant toute motivation et créativité. Mais en fait, très souvent, j’ai eu affaire à des gens très compétents, motivés, mais qui souffraient d’un défaut qui plombait leurs projets sans souvent qu’ils s’en rendent compte : le désir de rendre quelque chose le plus parfait possible.

Le numérique est l’idéal pour expérimenter

Dans un univers qui bouge en permanence, on est très souvent amené à faire du “jetable”, du temporaire. Parce que les délais sont contraints, parce que la ligne directrice est trop floue pour en faire quelque chose de solide. Plutôt que de subir une frustration d’avoir quelque chose de “jetable”, une bonne façon de voir les choses est de se dire qu’il s’agit simplement d’un essai, d’une première version que l’on sortira de la manière la plus souple possible.

Peut-être qu’il n’y aura pas d’autres version, mais peut être aussi que de cette expérimentation naîtra une nouvelle idée, ou une variation du projet qui finalement le fera aller de l’avant. Parce que l’on aura eu un feedback peu coûteux.

Certes, ce principe est plus facile à appliquer lorsqu’on effectue en travail en interne que lorsqu’on passe par un sous-traitant, une entreprise de services qui réalise le travail pour vous, et qui elle n’aura qu’une seule logique : celle de facturer au plus tôt, et donc de clore définitivement un projet au plus vite, quitte à ensuite faire des opérations de maintenance ultérieures qui seront facturées à leur tour. Mais de plus en plus d’entreprises du numérique se font à ces façons de procéder, ne serait ce que, comme on l’a vu plus tôt, c’est le mode de fonctionnement habituel des développeurs.

Devenir accro au feedback

Si je n’avais qu’une seule leçon à donner à mes étudiants en gestion de projet, ça serait de devenir un drogué du feedback. C’est la seule chose qui compte, et tous les projets devraient être conçus ainsi : comme des outils à délivrer du retour utilisateur.

Lorsque l’on met les utilisateurs dans la confidence de cette phase “expérimentale”, on s’aperçoit souvent qu’ils ne prennent pas mal du tout l’information, voire qu’ils peuvent se sentir presque flattés d’être impliqué ainsi dans votre projet.

Pour les personnes impliquées, délivrer à un rythme très fréquent sans chercher la perfection, c’est se donner la possibilité de “jeter” certains travaux sans vivre le traumatisme de mettre à la poubelle d’un coup des années de travail. Et ils vous seront redevables d’avoir pris la peine de recueillir du feedback le plus tôt possible.

Et pour le décideur, c’est l’outil parfait pour sortir de la “pensée magique” d’une vision hors sol qui devient une réalité à succès. On trouvera toujours des exemples où un entrepreneur a trouvé la formule miracle dans son coin, mais la plupart du temps, une vision ne se retrouvera que plus solide si elle est nourrie par un feedback conséquent.

Ce cher Steve Jobs, exemple type du dirigeant intuitif, disait souvent qu’il ne voulait pas s’appuyer sur l’avis de ses utilisateurs, en citant Henry Ford : “Si j’avais demandé à mes clients ce qu’ils souhaitaient, ils m’auraient parlé d’un cheval plus rapide”. Mais il ne faut pas oublier que, si Apple est effectivement parti d’une intuition, ou plutôt d’un pari (celui de l’explosion du marché de l’ordinateur individuel), le vrai succès de la firme s’est fait via de nombreuses sorties, plutôt fréquentes, qui ont permis d’affiner la stratégie de la marque pour aller vers quelque chose de vraiment conforme aux besoins réels de l’utilisateurs. Et, à moins d’avoir les moyens d’Apple, le meilleur moyen pour vous d’y parvenir est encore d’adopter la devise : Better done than perfect !

Vers moins de bullshit et plus de technologie humaniste : pourquoi la vague du tech backlash est une excellente nouvelle

Les entrepreneurs européens ont une chance incroyable : nous avons une boule de cristal à portée de main.

Si si ! Et pas besoin de Madame Irma pour cela. Il suffit de regarder ce qui se passe aux USA !

Même si cela fait parfois mal à l’ego de se le dire, il faut se rendre à l’évidence : une bonne partie de ce qui se passe chez nous s’est passé il y a quelques mois ou années aux Etats-Unis. D’une part parce que l’art du “copycat”, qui consiste à s’inspirer très largement de ce qui se passe de l’autre côté de l’Atlantique, a depuis longtemps fait ses preuves (les chinois en savent quelque chose), d’autre part parce que les Etats-Unis sont depuis longtemps bien plus actifs en ce domaine.

Lire la suiteVers moins de bullshit et plus de technologie humaniste : pourquoi la vague du tech backlash est une excellente nouvelle

L’après smartphone se profile. Mais à quoi ressemblera t’il ?

La présentation des nouveaux appareils photo, pardon, des nouveaux smartphones de chez Apple, lors de la traditionnelle présentation (on ne dit plus “keynote”, on dit “special event”) de rentrée, n’a pas vraiment passionné les foules, même si les investisseurs sont eux ravis de voir s’étoffer l’activité “services”, fort lucrative, de la firme.

Cela fait déjà un moment que l’on parle d’itérations successives : difficile, en étant objectif (même si les orateurs de chez Apple le sont fort peu), d’utiliser désormais à outrance le terme “révolution”, tellement les évolutions des téléphones intelligents se font maintenant à petits pas, certes assurés, certes parfois impressionnants de maîtrise technologique, mais sans grand chamboulement.

Lire la suiteL’après smartphone se profile. Mais à quoi ressemblera t’il ?