Ismaël Héry
Transcription
Ok, super. Allons-y. Bonjour, je m'appelle Ismaël Hery. Merci d'être là, je suis très content d'être avec vous. J'espère que ce sera assez court pour nous laisser un peu plus de temps pour les questions-réponses. Et je pense que, de toute façon, c'est assez court, donc n'hésitez pas à m'interrompre si vous avez des questions ou des éclairs, des illuminations pendant la presse. Allez-y, je vous en prie.
Très rapidement, quelques mots sur moi.
On va y arriver. J'étais coach Agile et Lean jusqu'en 2011 dans une boîte qui s'appelle Octo. En 2010, j'ai mis en place du Kanban sur des activités à Mont, l'expérience dont a parlé David hier.
Et depuis 2011, je travaille au Monde, j'ai été responsable des développements, puis responsable du projet de refonte des outils utilisés par les journalistes, le CMS, le back-office. Et à partir de décembre, je serai responsable du produit et de l'IT. Mais peu importe. Ce dont je vais vous parler aujourd'hui, c'est...
Que quand on cherche à concevoir, à designer et à opérer, à maintenir en condition les produits numériques qu'on fait au monde, on a de grosses problématiques. On a une problématique d'exécution, on a besoin de faire des choses, on a besoin d'apprendre énormément. On sent que c'est un thème qui traverse un peu la conférence, on nous en a parlé pas mal ce matin.
Donc je vais partager avec vous cette problématique, le fait qu'on a besoin de beaucoup apprendre, des choses qu'on met en place pour tenter de rendre cet apprentissage le plus efficace possible, et puis partager des illustrations, des retours d'expérience sur ces points. Ok, qu'est-ce qu'on fait? Je vais aller vite là-dessus, je pense que vous savez ce qu'on fait. Notre principal produit, c'est le site gratuit. On a 100 millions de visiteurs uniques environ. On a un site payant, c'est l'offre premium, il faut être abonné. On a environ 70 000 abonnés purs numériques.
On fait des apps mobiles. Et on fait aussi maintenant depuis un mois,
C'est de ne pas faire tomber.
Depuis un mois, on fait ça depuis un mois en fait. On a développé un outil en interne qui permet aux journalistes de rédiger, éditer, corriger leur contenu pour le web, pour le numérique et pour le papier. L'idée étant que, comme dans beaucoup d'organisations jusqu'ici, on avait des rédactions qui étaient disjointes, une rédaction papier et une rédaction numérique, qui travaillaient dans des outils séparés, qui se haïssaient cordialement. Les organisations se rapprochent et on a donc fait un outil pour accompagner ce rapprochement.
Donc voilà, ça c'est les principaux produits numériques que nos directions, nos utilisateurs nous demandent de mettre en place. Alors, des petites caractéristiques de notre contexte. Qu'est-ce qui est particulier chez nous? On n'est pas un pur player, on est une boîte, en fait, jusqu'ici on imprimait des choses sur du papier, ça va encore être le cas pour quelques années, mais ça va sans doute s'arrêter plus tôt qu'on ne le croit. Mais donc on a vraiment le clash de deux cultures, une culture de journalistes papier, une culture d'ouvriers des imprimeries, et une culture de journalistes numériques et des gens qui font des produits numériques.
J'ai vu le déclic il y a vraiment un ou deux ans où ces deux cultures ont compris qu'elles allaient vraiment devoir bénéficier des richesses de l'autre culture pour survivre. Donc le clash est plus franc et massif comme il est. jusqu'ici, mais on a quand même toujours des réflexes, des façons de penser, des mindsets qui sont très très différents. Donc ça c'est une caractéristique. Une boîte de culture.
Comme vous le savez, c'est super difficile économiquement. Personne n'a trouvé encore de solution pour maintenir des business de news, de presse en ligne ou papier qui soit viable. Le New York Times ou le Guardian, qu'on prend souvent comme exemple, ne sont pas du tout des exemples, ce ne sont pas des boîtes qui gagnent de l'argent. Le New York Times a décidé il y a quelques semaines de supprimer 100 postes de journalistes et le Guardian jette de l'argent par les fenêtres dans des ordres de grandeur complètement déments. Ils peuvent se le permettre, tant mieux pour eux. En tout cas, c'est super dur, ce qui explique qu'on a relativement peu de moyens et qu'on a de fortes contraintes. Parce qu'on ne peut pas dire, là on a un petit problème, on va doubler ou embaucher 10% de développeurs en plus. Non, ce ne sont pas des choses qui nous sont accessibles.
On utilise des technos pas hyper satisfaisantes, on utilise des technos même buggées, on peut le dire. Alors j'entends par pas satisfaisantes des choses qui ne sont pas stables, qui sont pleines de bugs. Un exemple récent... iOS 8, je ne sais pas si c'était en France aussi, mais je suis sûr qu'aux US, la première release d'iOS 8, iOS 8.0.1,
c'est la réception cellulaire. Donc vous aviez un smartphone qui était super super smart, mais qui n'était pas du tout faune en fait. C'était terminé, il n'y avait plus de faune. Je ne sais pas si ça arrive en France, mais voilà, c'est le cas sur quasiment toutes les briques, tous les frameworks, toutes les plateformes qu'on utilise, c'est franchement buggé. Au passage, vous vous rappelez peut-être du principe du Toyota Way, utiliser seulement des technologies matures qui ont fait leur preuve. Donc ce n'est pas du tout ce qu'on fait.
Une autre particularité, c'est que la plupart de nos projets finissent à l'heure, pour pas mal de raisons. La première, c'est qu'on a peu de moyens, je vous l'ai dit tout à l'heure. La deuxième, c'est que beaucoup de ces projets sont liés à l'actu. Donc là, on n'a même pas besoin d'avoir de discussion sur le cost of delay.
Si on fait un projet sur une soirée électorale, évidemment, on a essayé d'appeler, on était un peu en retard, on a appelé, écoute François, est-ce que tu ne veux pas décaler la soirée, la faire dans deux jours, parce que là, on a une super animation sur la carte, mais on n'est pas encore prêt. Bon, évidemment, ça, ce n'est pas fait. Donc voilà, des contraintes qui font que les projets sortent malheureusement ou heureusement à l'heure. Et on a aussi un élément culturel, c'est un vieux loup de mer du Linde qui m'a fait comprendre ça. Il m'a dit« mais regardez-vous, tous les jours, même si vous êtes à l'arrache comme beaucoup d'organisations, tous les jours vous faites un truc comme ça et qui sort à 10h30». Ça, c'est un petit break. Vraiment, j'ai assisté plusieurs fois à ça. Effectivement, on a un chaos, on a beaucoup de choses qui se passent. pas très bien, des gens qui s'entendent plus ou moins bien, mais à un moment, il y a l'horloge qui tourne, et quand elle approche de 10h30, là, tout d'un coup, les gens comprennent, vont à l'essentiel, et le truc sort dans les temps. On a d'énormes pénalités financières si ça ne sort pas à l'heure.
Ok, donc ça c'était les caractéristiques de notre contexte qui nous amènent à notre problème. Quel problème on est confronté quand on essaye de concevoir et de développer ces outils?
On est en point 1, on essaye d'aller en point B. Le point B, c'est quand nos clients, à la fois internes, donc la direction et les utilisateurs finaux, sont satisfaits, évidemment, quand on a respecté les contraintes de budget et de temps. Et il y a un truc qu'on sous-estime très souvent, c'est le budget et les coûts d'opération, de maintenance. Donc les ops et les développeurs qui corrigent les bugs, si c'est largement au-delà de ce qu'on a prévu, on n'est pas du tout dans le respect des contraintes qu'on s'était données au début.
Donc on est là, on essaie d'aller au point B, pardon, hop, on va y arriver, et en fait, on n'a aucune idée de ce qui se passe entre les deux. J'ai été project manager, donc j'ai fait des plans avec d'abord on fera ça, bon évidemment on fait de l'agile, donc on fait des itérations, d'abord on fera ça, ensuite on aura un milestone, on installera le framework, machin, on mettra en place la... J'ai écrit tous ces trucs, mais en fait, on n'en a réellement aucune idée de ce qui se passe entre les deux. Il y a beaucoup, beaucoup, beaucoup, beaucoup d'incertitudes.
Beaucoup de questions auxquelles, déjà, on ne sait pas. La question va se poser pendant le projet et en plus on n'a aucune idée au moment où on démarre et même un peu plus tard des bonnes réponses à ces questions.
Dans mon métier, mais je pense que ça doit être le cas dans le vôtre pour beaucoup d'entre vous, on va dire qu'il y a trois grands domaines de questions. Le premier domaine sont les questions qui concernent l'expérience utilisateur, le problème qu'on cherche à résoudre, l'ergonomie, le besoin. Donc là, beaucoup, beaucoup, beaucoup d'inconnus. Qu'est-ce qu'il veut exactement, etc. On a ensuite des questions qui concernent le développement. Est-ce qu'on saura développer vite? Combien de temps prendra telle feature? Et on a finalement un domaine qui est le operations, en français on appelle ça la prod ou l'infra, ça dépend un peu, dans lequel on a aussi beaucoup, beaucoup d'inconnus.
Donc déjà, se rendre compte qu'on a ces trois domaines de questionnement. Des exemples, en produit, est-ce que c'est vraiment un problème d'utilisateur? Est-ce que ce n'est pas quelque chose que moi je pense être un problème d'utilisateur et que finalement l'utilisateur n'a pas? Est-ce que ce que je suis en train de, avec mes idées génialissimes, de développer, de concevoir, de faire un superbe design, ça fonctionnera une fois que ce sera dans les mains de l'utilisateur? Rien n'est moins sûr.
Est-ce qu'entre ces deux features, on doit vraiment mettre le paquet sur celle-ci, ou plutôt sur celle-là? Bon, une infinité, on pourrait continuer comme ça, vous en avez sans doute de votre côté, à l'infini. Des exemples de questions existentielles auxquelles on n'a pas les réponses du tout en démarrage de projet, côté équipe de dev.
Est-ce qu'on doit utiliser ce framework-là, cette librairie-là, ou l'autre librairie qui a à peu près les mêmes caractéristiques sur GitHub ou une autre plateforme? Combien ça va prendre de temps pour développer cette feature? Est-ce qu'on sait faire des tests automatisés sur cette techno?
Une fois que je vais monter en charge, on a des problématiques de montée en charge importantes. Quand je vais monter en charge, je risque que mon premier bottleneck, mon premier goulet d'étranglement, ce sera la base. C'est la base qui va lâcher, ce sont les serveurs web qui vont lâcher, c'est le Redis qui va lâcher. On a un feeling parce qu'on a fait des projets un peu similaires, mais en fait on n'en sait rien.
Côté prod, quel effort sera nécessaire pour déployer sur les différents environnements ? Quand vous faites votre super plan de projet avec la date de fin, vous faites une hypothèse sur ça. Vous vous dites que ça prendra à peu près tant de temps pour mettre en place les outils de déploiement. Ensuite, je saurais déployer à peu près toutes les semaines. En fait, vous n'en savez rien tant que vous ne l'avez pas fait. Quelles sont les principales faiblesses de mon système? Une fois en production, de quels outils de supervision, d'alerting j'aurais besoin? Vous vous rappelez, le point B, c'est quand tout fonctionne, l'utilisateur est satisfait, le système est stable. Donc avant d'arriver à B, vous avez vraiment besoin de répondre à cette question. Quelles sont les fragilités? Comment je serai alerté?
Combien de serveurs je vais devoir acheter? Est-ce que c'est 10? Est-ce que c'est 20? Est-ce que je vais devoir aller chez Amazon parce que je suis incapable de raquer tous ces serveurs moi-même?
Ok, donc plein de questions dans ces trois domaines auxquels on n'a pas encore les réponses.
Donc si je reformule un peu la situation à laquelle on est confronté, on sait qu'on ne sait rien, on sait que si on veut développer, mettre en prod dans des bonnes conditions le plus vite possible, on va devoir apprendre très très vite sur toutes ces questions, sur tous ces domaines. Donc la question revient finalement à comment est-ce que je peux apprendre, faire que mon équipe va apprendre très efficacement, très vite. Sur toutes ces questions.
L'hypothèse, mon hypothèse, c'est qu'on va s'efforcer d'apprendre dans tous les domaines. On ne va pas en favoriser un au dépend des autres. On ne va pas être super fort en apprentissage des questions produits et UX, par exemple, et très très mauvais en apprentissage sur la prod. Ce sera assez terrible. Et on ne va surtout pas attendre trop trop tard pour apprendre.
Je vais vous présenter des pratiques, quelques pratiques, évidemment on ne les a pas inventées, vous en faites sans doute, vous mettez sans doute en oeuvre ces pratiques vous aussi. Ce sont des pratiques super intéressantes parce qu'elles sont nécessaires à l'exécution d'un projet et la construction d'un produit, mais on estime qu'elles sont super intéressantes pour apprendre parce qu'elles répondent aux critères qu'on a vus tout à l'heure. Elles nous permettent d'apprendre très très tôt, elles nous permettent d'apprendre sur les différents domaines et d'apprendre très efficacement.
La première pratique, c'est les tests utilisateurs. Les tests utilisateurs, si je devais donner une définition, grosso modo, je dirais, on observe nos utilisateurs utiliser vraiment votre produit final en conditions proches de la réalité ou dans les conditions de la réalité. Ils sont à leur poste et vous intervenez à peine, vous les laissez, vous les observez d'un peu loin. Donc voilà, observez cet utilisateur une fois par mois, utilisez votre produit. Qui fait, avec cette définition-là, qui fait les tests utilisateurs? Moi, je lève et je baisse la main. Ok.
Donc, les tests utilisateurs.
On a tous beaucoup d'expérience dans nos domaines respectifs, donc on a tous des intuitions de ce qui va marcher, de ce qui ne va pas marcher. Une fois sur deux, ces intuitions sont bonnes, mais vraiment, vraiment, c'est l'outil, c'est la pratique qui, de ce point de vue-là, nous met des grandes baffes, nous met des grandes claques et nous fait apprendre énormément. Donc l'idée n'est pas de... On connaît tous ces citations de Ford et de Steve Jobs. L'idée n'est pas d'attendre que l'utilisateur nous formule le problème et nous formule les solutions, articule tout ça, clac, clac, voilà, il nous signe ça avec son petit nom d'utilisateur, c'est bon, on n'a plus qu'à implémenter. Non, non, évidemment, ça ne marche pas comme ça. Mais les tests d'utilisateurs sont super efficaces. Pour valider vos hypothèses sur ce qu'est le problème et pour valider vos hypothèses sur la solution. C'est au coût et à l'investissement de tests que ça prend, c'est d'une efficacité redoutable par rapport à beaucoup d'itérations. Je suis en train de me chauffer sur Twitter, c'est un peu fort, mais je disais sur Twitter, j'en ai marre d'entendre« fail fast». Au sens où on incite beaucoup dans nos communautés, il faut échouer rapidement, échouer rapidement. C'est bien d'échouer, on apprend. Si on peut apprendre sans échouer, c'est encore mieux. Donc les tests d'utilisateurs nous permettent d'à peine échouer parce qu'on n'a pas encore commencé forcément à développer. On a développé des débuts de mock-up ou des choses avec un investissement très très faible.
Donc, fail fast est sûrement un bon slogan pour rendre moins effrayant l'échec. Mais pour autant, si on peut réussir aussi vite ou aussi bien sans se planter, tant mieux. À cet égard, les calculateurs sont super efficaces. Je ne sais pas, c'est un peu fort, mais je disais sur Twitter, j'en ai marre d'entendre « fail fast », au sens où on incite beaucoup, beaucoup dans nos communautés, il faut échouer rapidement, échouer rapidement. Oui, c'est bien d'échouer, on apprend. Si on peut apprendre sans échouer, c'est encore mieux. Donc les tests d'utilisateurs nous permettent d'à peine échouer parce qu'on n'a pas encore commencé forcément à développer. On a développé des débuts de mock-up ou des choses avec un investissement très très faible. Donc, fail fast est sûrement un bon slogan pour rendre moins effrayant l'échec. Mais pour autant, si on peut réussir aussi vite et aussi bien sans se planter, tant mieux. À cet égard, les calculateurs sont super efficaces.
Alors les caractéristiques des testateurs qui font que ça peut prendre chez vous, que ça peut marcher chez vous. Première caractéristique, c'est qu'on a besoin de le faire très souvent et très facilement, que ce soit peu coûteux, que ce soit cheap. Donc en fait, on va le faire soi-même. Culturellement, dans beaucoup de boîtes du web en France, on est assez old school et c'est des choses qu'on outsource. Donc il y a des boîtes, je ne me rappelle plus des noms, des cabinets, à qui on outsource nos testateurs. Donc on écrit une propale, ça prend un mois pour écrire la propale, leur décrire ce qu'on veut tester avec eux, contractualiser en choisissant le fournisseur, designer les tests avec eux. Donc là on est à deux mois, ils font les tests, une semaine ou deux, ils analysent les résultats de tests. Là on a trois mois, vous voyez j'ai testé deux, trois écrans, là ça m'a pris trois mois. C'est complètement dément alors que j'ai besoin de... Pour ce que j'ai testé, j'ai besoin que ça me prenne quelques heures, quelques jours, pour le faire tout le temps, toutes les semaines, tous les mois. Donc première erreur, outsourcer cette compétence. C'est quand même dingue qu'on imagine, je dis dingue mais on le fait encore, pas sans tout mais on le fait encore, qu'on imagine outsourcer la compréhension du besoin utilisateur. Donc beaucoup d'équipes marketing et produits notamment ont très peur en se disant« Oh c'est un truc compliqué, il faut faire appel à des ergonomes, c'est de la rocket science. » Et notre ami Steve Krug qui avait écrit un premier bouquin culte sur l'ergonomie qui s'appelle...
Quelqu'un se rappelle du premier bouquin Steve Krug? Bon, peu importe. Oui, Don't Make Me Think. Ne me faites pas penser. Je suis utilisateur, je ne veux pas penser quand j'utilise vos interfaces. Il a écrit ce bouquin,« Request sur le jury mail d'Easy», pour dédramatiser et... Et en fait expliquer simplement les tests utilisateurs. Donc voilà, faites-les vous-même, essayez. Les premières fois, vous allez forcément vous planter, mais sincèrement, il y a plein plein de guides, plein de petits tips, plein de checklists dans la littérature Lune Startup, chez Steve Krug, pour vous aider à faire vos premiers tests utilisateurs assez rapidement et à moindre coût.
Donc ça c'est un exemple de petite grille.
C'était sur le CMS, ça c'est un test sur le CMS, donc on voulait vérifier, vous voyez une hypothèse, l'utilisateur trouvait immédiatement comment créer un article, il était face à l'interface, il y avait plusieurs menus possibles et on voulait que rapidement, de manière assez évidente, il trouve le menu pour créer et commencer à rédiger son article.
Donc il y a la consigne tout en haut, on a un script, donc dans les testateurs il y a quelqu'un qui est assez distant, qui essaie de ne pas trop s'énerver quand le testateur fait n'importe quoi sur son produit, mais qui lui dit voilà on voudrait tester ça, est-ce que tu peux le faire? Et puis on a un script qui prend plein plein de notes, donc il va noter si l'objectif était atteint, le nombre de clics, le temps passé, le nombre d'erreurs, etc. Les remarques diverses et variées, ça peut être les jurons de l'utilisateur par exemple.
Alors, quelques histoires sur le testateur au monde. Ça, c'est plutôt un fail. Donc on a développé ce truc en 2013. C'est une géolocalisation des contenus sur une carte. Donc c'était assez cool à designer, à développer, avec des API OpenStreetMap, etc. On était super fiers de nous. Et on a fait des tests de site, mais très très tard. On les a faits il y a quelques mois, donc plus d'un an après le lancement du produit. Et il s'avère que les utilisateurs ne comprennent pas vraiment ce que fait ce produit. En fait, beaucoup ne l'ont même pas remarqué. C'est dans les surabonnés, il faut être abonné. Beaucoup ne le remarquent même pas. C'est un peu bas dans la une abonnée, mais pas si bas. Donc là déjà, bon ok, on a... Beaucoup investissent sur ce truc, mais ils ne le connaissent pas. Et pour ceux qui le connaissent, beaucoup ne le comprennent pas. Donc là, on rentre encore un peu plus ses épaules. Donc vraiment, moi cette expérience-là me permet de vendre et d'expliquer l'intérêt du test utilisateur en interne, en disant, voilà, rappelez-vous la carte sur laquelle on a fait beaucoup de choses, on était sûr de nous, on se disait, ouais c'est génial, ce truc est vraiment génial, ça va forcément prendre. Et en vrai, les utilisateurs ne sont pas hyper aussi enthousiastes que nous. Deuxième anecdote sur les tests utilisateurs, sur le CMS, sur chaque test utilisateur, un truc qu'on pensait être difficile, on se disait, voilà l'utilisateur, il y avait des débats entre nous, mais ça ne va pas marcher, il ne va pas comprendre par où passer. A chaque fois, un truc qu'on pensait difficile a été évident pour l'utilisateur. Donc on s'était complètement planté, notre intuition était fausse. Et à chaque fois, un truc qu'on pensait évident, c'est-à-dire qu'on ne contestait même pas, on n'avait pas d'étape dans le test pour ce truc-là, l'utilisateur accrochait complètement et ne passait pas du tout. On devait lui dire, c'est comme ça, donne-moi la souris, là je te montre, on passe à l'étape suivante. A chaque utilisateur, on a eu le cas, un truc évident, pas évident, un truc. Donc voilà, des grosses claques et un énorme apprentissage à chaque fois. Et la deuxième anecdote, on testait, on avait des personas, vous savez, c'est des profils pour un peu segmenter, c'est du théâtre, donc on avait des gens un peu geeks dans nos profils, parce qu'il y a des jeunes journalistes qui font des trucs très visuels, qui font du code, qui développent. Et puis on a des journalistes qui ont dépassé. L'âge de la retraite, parce que je crois que chez les journalistes, ils ont le droit de bosser jusqu'à je ne sais plus quel âge. Donc on testait aussi ce profil-là, qui était un bon extrême pour nous. Et puis on lui dit, le test c'était pour tester le copier-coller, parce que voilà, ils font des copier-coller. Oui, les journalistes font des copier-coller, ça n'a rien. Et donc là, on voulait vérifier qu'ils comprenaient que ça fonctionnait avec ce outil. On lui dit, donc voilà, tu veux copier le contenu qui est sur le bureau. Et là, il nous dit sur le bureau au quatrième étage. Non, évidemment, on parlait d'un contenu sur le bureau Windows. Donc ça, c'est vraiment un truc. Quand il nous a dit ça, on a fait OK. Notre utilisateur, notre persona du journaliste, c'est comme ça. Il pense comme ça, il a ce type de problème. Et ça nous a mis une bonne, bonne baffe.
Donc pour résumer, faites-en, mangez-en, amenez vos développeurs si vous pouvez assister à cet utilisateur pour augmenter drastiquement l'empathie qu'ils peuvent avoir avec eux. Ou parfois ils peuvent prendre des raccourcis sur« mais ça c'est évident, c'est un non-sujet» et en fait pour ton utilisateur, ce ne sera pas du tout un non-sujet.
Sur les test utilisateurs, prenez 10 secondes et posez-vous la question, là maintenant, qu'est-ce que vous, prochaine étape, qu'est-ce que vous pouvez faire pour essayer d'aller voir vos utilisateurs, utiliser votre produit dans les jours qui viennent? Est-ce que vous allez lire Strifkrug? Est-ce que vous allez, si vous avez un produit grand public, aller au Starbucks pour le tester ou dans un TGV? Qu'est-ce que... Ne me répondez pas, mais posez-vous la question. Qu'est-ce que vous allez faire?
Ok, deuxième pratique que l'on met en place, qu'on utilise le plus souvent possible, c'est le déploiement le plus tôt possible, et j'allais même dire trop tôt. Alors on connaît tous les versions bêta, Google a popularisé ça. Mais ce qui est plus intéressant que le système de version bêta, c'est comment peut-être sur des sous-parties, sur des sous-usages, sur une sous-partie technique, sur un sous-périmètre, comment je vais pouvoir pousser un truc pas complet. Donc pas complet sur plein d'axes possibles, plein de façons de dire que ce n'est pas complet. Et creuser cette idée de pas complet et de comment des trucs pas complets vont pouvoir aller le plus loin possible, le plus vite possible.
Ok, donc quelques petites recettes de cuisine sur les tests, les bêtas, les versions bêtas.
Première recette, c'est de bidonner, de pipoter beaucoup de choses dans le système. Donc l'apprentissage est tellement énorme qu'on va être prêt à faire un investissement, et on le fait, et ça vaut toujours le coup, de faire du double run, brancher dans vos systèmes d'information, brancher, avoir un tuyau temporaire pour brancher tel système avec tel système, le vieux système de paie avec le nouveau système de paie, ça c'est chez les banquiers, chez nous ce sera le vieux CMS avec l'ancien CMS. On fait beaucoup. beaucoup de devs temporaires, jetables, qui ne servent pas à grand-chose, sauf avoir une version en bêta qui marchote sur un sous-périmètre, sur un sous-usage pour une sous-population. Mais l'apprentissage est tellement énorme qu'on fait cet investissement. Donc on bidonne beaucoup.
Deuxième recette, comme on met, je disais, fail fast tout à l'heure, ça ne me plaît pas vraiment, malgré tout j'en fais aussi. En version bêta, on met dans les mains des utilisateurs des trucs qui sont assez cassés, qui ne sont pas forcément fonctionnels, où il n'y a pas tout, et ce qu'il y a, on va forcément un peu trop tôt en production, ça ne marche pas complètement. Du coup, on a un accompagnement de nos bêta-testeurs qui demande beaucoup d'énergie. Donc on va devoir les recruter avec attention, à la fois qui représentent les différents personas, les différents profils, mais on va prendre des gens plutôt bienveillants.
Parce que sinon, la personne au bout d'une heure du théâtre, on a un truc qui est moyennement fini, elle va se fermer comme une huître et elle va dire« Ok, vous me faites vraiment trop perdre mon temps, elle va aller voir ailleurs. » Donc on prend plutôt des utilisateurs bienveillants, ils ne sont pas forcément représentatifs, parce que dans la vraie vie aussi on a des gens qui sont chiants, qui ne sont pas tous bienveillants. On prend aussi quelques chiants, pour que ce soit assez représentatif, mais beaucoup de personnes plutôt bienveillantes qui vont être capables de jouer, de travailler avec nous sur cette version bêta. On passe beaucoup de temps avec elles à les encourager. Ok, ouais, donc ça... Et qu'est-ce que t'en penses ? Donc on recueille leur feedback en permanence. On les encourage dans l'utilisation d'un truc qui n'est pas forcément fonctionnel. On est vraiment à l'écoute de ces gens-là, on passe beaucoup de temps avec eux parce qu'ils nous font gagner énormément de temps et nous on leur fait perdre un petit peu malgré tout.
Et on les rembourse un petit peu, c'est-à-dire que... Dans un Kanban, peut-être qu'ils ont, je n'ai jamais matérialisé comme ça, mais ils ont quelques features qui sont pour eux, qui sont pour les bêta-testeurs, pour les encourager à continuer à utiliser notre version bêta toute cassée. Donc ce n'est pas eux qui guident la roadmap du produit, ce n'est pas eux qui dirigent, ils ne sont pas product owners. Mais on leur donne quelque chose assez régulièrement.
On les rembourse.
Lorsqu'on n'est pas capable de déployer un périmètre fonctionnel utilisable, un sous-module utilisable par un utilisateur finaux, que ce soit
le grand public ou des journalistes, on s'efforce d'aller en prod le plus vite possible avec des sous-modules technico-techniques testables par les techos, par les développeurs, par les ops. Ça, ça nous apprend énormément. Toutes les grosses mises en prod, en fait, elles sont découpées et des sous-composants techniques partent en prod bien avant, bien avant, bien avant les sous-composants fonctionnels. Donc on teste énormément de choses, on teste la stabilité, même un truc qui n'est pas trop sollicité, il peut planter. On se rend compte que même un truc pas utilisé, quand on le déploie, ça va être une galère sans nom, qu'on manque d'outillage, que ce truc n'est pas supervisé. Donc même si c'est quelque chose d'invisible, on apprend énormément à déployer en avance de phase. Donc, qu'est-ce que je peux prendre comme exemple? Tous les produits que je vous ai montrés au début, en fait, ils sont disponibles en production bien avant des semaines, si ce n'est des mois avant leur usage réel.
Ok, donc des semaines, ça je vous l'ai dit, c'est parti. Les avantages de déployer très très tôt, Le premier, c'est de focusser les responsables produits, les product owners, appelez ça comme vous voulez, sur les vrais problèmes utilisateurs.
Ces gens-là se font plein d'idées, des bonnes et des mauvaises, et une fois le produit vraiment entre les mains des utilisateurs, la priorité sur quel est le vrai problème de mon utilisateur, elle devient évidente pour tout le monde. Ok, on avait tous imaginé que c'était ça, non, non, pas du tout, c'est ça. Donc mettre très très vite en prod et mettre régulièrement en prod, ça va vous assurer que vous allez focusser les responsables produits sur vos vrais problèmes. Pareil avec les techos, je pense aux ops ou aux développeurs qui se font toujours des plans. Les ingénieurs ont se dit, ouais, mon problème, quand ça va monter en charge, ce sera Redis parce qu'il n'y a pas de master safe, je ne sais pas quoi. Ou alors après, une fois qu'on sera sans mutateur, c'est ce composant-là qui va lâcher. Ou alors, ah non, on va avoir une attaque. On va avoir un denial of service, les hackers vont nous attaquer. Au monde, le denial of service, c'est nous qui nous les faisons la plupart du temps. C'est rarement les hackers. 9 fois sur 10, c'est nous. Et les problèmes auxquels on pense, allez, on va dire une fois sur deux, on a raison, c'est le prochain problème, mais une fois sur deux, on se pende complètement. Donc ça, ça va vous permettre aussi de ne pas gaspiller du temps d'engineering sur, j'en sais rien, faire un cluster Redis ou faire un cluster Postgres SQL, alors que ce n'est pas du tout votre prochain problème. Donc ça c'est assez génial, déployer en prod, rencontrer des problèmes et focusser les personnes qui sont responsables de la résolution de ces problèmes sur ces vrais problèmes.
Ça va nous permettre d'améliorer aussi la robustesse, active ou passive, je ne sais plus exactement par rapport à la keynote de Don Reinerzen, Mais ça va nous permettre d'améliorer la robustesse du système très très tôt. On va le mettre en prod, on va le solliciter un peu, beaucoup, passionnément. Et il va crasher. Et donc on va constater dans le cas de vrais problèmes, de vraies conditions de prod, qu'on a tel problème et qu'on va devoir mettre en place telle contre-mesure pour le rendre plus robuste. Donc ça va nous permettre d'améliorer petit à petit
notre système, avec une matière première d'amélioration continue qui est réelle. En fait, tous ces problèmes, si on ne déploie pas en bêta, on les rencontrera aussi plus tard, le jour de la mise en prod et dans les mois qui suivent. Là, on commence juste à les rencontrer un peu plus tôt. Donc l'amélioration continue de problèmes de prod commence beaucoup plus tôt. Et ce qui est chouette aussi, c'est que ça engage les personnes, ça fait que les personnes sont plus passionnées, plus excitées par le projet, parce que sur des projets qui peuvent durer 6 mois ou 1 an, 1 an et demi, parfois beaucoup plus long, les gens sont en prod plutôt. Ok, ils ne sont pas en prod avec toutes les features, parfois ils ne sont même pas en prod avec des vrais utilisateurs, mais il y a une petite excitation de la grosse mise en prod, des crashs, parce qu'on va avoir des crashs, on va avoir des gros problèmes dans les semaines qui vont suivre. Ça, vous rajoutez de l'excitation et de l'énergie dans une équipe.
C'est le big deal beaucoup plus tôt. Le jour de la mise en prod est dans les mois qui suivent. Là, on commence juste à y rencontrer un peu plus tôt. Donc l'amélioration continue de problèmes de prod commence beaucoup plus tôt.
Et ce qui est chouette aussi, c'est que ça engage les personnes. Ça fait que les personnes sont plus passionnées, plus excitées par le projet. Parce que sur des projets qui peuvent durer 6 mois ou 1 an, 1 an et demi, parfois beaucoup plus long, Les gens sont en prod plutôt, ok ils ne sont pas en prod avec toutes les features, parfois ils ne sont même pas en prod avec des vrais utilisateurs, mais il y a une petite excitation de la grosse mise en prod, des crashs, parce qu'on va avoir des crashs, on va avoir des gros problèmes dans les semaines qui vont suivre, ça vous rajoute de l'excitation et de l'énergie dans une équipe.
C'est le big deal beaucoup plus tôt.
Ok, quelques histoires de déploiement en prod anticipé. Donc ça, c'est la une abonnée qu'on a faite en 2013.
Donc, cette une, auquel vous accédez si vous êtes abonné, elle a des dispositifs éditoriaux un peu particuliers, les contenus ne sont pas les mêmes, les zones de mise en avant ne sont pas les mêmes, les rythmes de rafraîchissement ne sont pas les mêmes. Donc, tout ça pour dire que les journalistes ne travaillent pas cet objet éditorial comme ils travaillent la une gratuite. Au moment où on a fait ce truc, ça posait plein de questions. Ils ne savaient pas si ça allait marcher, ils ne savaient pas s'ils allaient pouvoir mettre tel type de contenu dans tel bloc, ils ne savaient pas les shifts de journalistes, parce qu'on se met à jour 24-24 maintenant, comment ils allaient devoir organiser, s'ils allaient devoir faire trois journalistes entre 8h et 14h, et beaucoup de questions. Donc ces questions, on a essayé de les adresser avant de sortir en prod. Donc quelques semaines avant la sortie en prod de ce truc-là, on avait une version assez buguée, je dois le dire, qu'on a mise dans les mains des journalistes et sur lesquelles ils ont fait ce type de une qui était du point de vue design pas fini comme ça. Mais ça leur a permis de voir plein plein de choses. On a découvert d'autres choses après la mise en prod, mais pendant trois semaines, un mois, avant la mise en prod, ils ont joué avec pendant plusieurs heures par jour, et ils faisaient vivre cette une abonnée. Et ils se sont rendus compte, ah ouais, tel truc, ça marche pas du tout. Là, la photo comme ça, avec ce type de titre, c'est no way, il n'y a aucune façon que ça marche. Et donc on a appris au plus tôt sur ces usages.
Deuxième histoire, sur le CMS, je vous disais, ça fait maintenant un mois et demi qu'on fait ça avec le CMS que l'on a développé.
Et en fait, les cahiers, les suppléments sont faits depuis juin, mais le CMS est en production depuis dix mois, depuis beaucoup plus longtemps. Et on a mis en production un truc minimaliste qui permettait d'écrire sans enrichissement et de pousser dans le vieux CMS. On a un peu contraint des utilisateurs à dire« Ah si, tu vas utiliser ce truc-là, c'est un peu chiant à utiliser, ça ne fait pas tout ce que tu veux et tu dois jongler entre les deux outils, mais tu nous aimes bien et puis on va t'offrir des chouquettes toutes les semaines et tu vas voir, tu vas nous aider à améliorer le produit au fur et à mesure. » Tout ce que je vous racontais tout à l'heure. Et ce truc a été salvateur parce qu'on a eu plein de problèmes. En fait, depuis 10 mois, on résout des problèmes. Je vais vous illustrer ça par quelques post-mortem. On a eu des plantages, on a eu des gros crashs, on a eu des pertes d'articles, plein plein de problèmes que pour certains on aurait eu après la mise en prod du dernier moment de il y a un mois si on n'avait pas fait ces déploiements plus tôt.
Allez, quelques histoires. Donc à l'issue de chacun de ces incidents, on fait un post-mortem. Lisez les web operations ou le blog de Etsy pour structurer vos post-mortem. Comment je recueille la timeline de ce qui s'est passé? C'est quoi les problèmes? Quels étaient les problèmes? Quels étaient les... Pas les routes causes, mais... jamais de route cause, mais les causes, quels problèmes j'ai rencontrés pendant la résolution, etc. Et donc on a fait un post-mortem, par exemple...
Alors voilà, la base de données de prod est vidée. Alors ça c'était un dev qui a lancé ses tests automatiques. Test automatique, test unitaire qui vide la base de données avant de mettre des données de test. Seulement, il avait laissé dans les paramètres d'environnement la base de prod. Donc, il a vidé la base de prod en lançant ses tests automatiques. Donc, il s'est fait taper sur les doigts, très rapidement, on a fait le post-mortem. À ce moment-là, on avait deux ou trois utilisateurs qui jouaient avec le système en prod. Je ne sais pas, on devait faire peut-être cinq ou dix articles par jour, même pas. Non, même pas d'ailleurs. Donc, ce n'était pas très grave. Vous voyez, on a eu la honte vis-à-vis de deux ou trois utilisateurs et pas de 400 utilisateurs. Et puis, je n'ai pas mis en péril... Je n'ai pas mis en péril l'apparition de ça, parce que si ça m'était arrivé, peut-être que je ne serais pas là pour vous parler.
Donc ça, c'est une histoire de post-mortem.
Qu'est-ce qu'on a eu? Les serveurs qui tombaient tous tour à tour comme des mouches, je ne me rappelle plus donc je ne vais pas vous raconter. Les serveurs DNS, les serveurs DNS qui tombaient et plus de DNS, l'application ne fonctionnait plus du tout. Donc post-mortem, les ops ont analysé le truc parce qu'on avait des serveurs DNS qui se donnaient la main. Avec des relais quand on a un. Un tombe, l'autre prend la main, etc. Mais ce mécanisme de fallback ne fonctionnait pas.
On n'avait pas été alerté, on a découvert le problème très tardivement. Donc ça ne fonctionne pas, ok, pourquoi? Je crois que ça nous a pris une heure ou deux avant d'arriver à« c'est le DNS qui ne fonctionne pas». Donc là, vous voyez, c'est un composant assez évident qui n'était pas supervisé, sur lequel il n'y avait pas d'alerting. Vous pouvez dire« on a mal fait notre job». Je ne sais pas comment on a été arrivé là. Toujours est-il que suite à ce post-mortem, Évidemment, on était alerté quand les problèmes de DNS tombaient, et le mécanisme de fallback a été revu et corrigé pour que ça fonctionne. Donc plein de petites histoires comme ça, avec des crashs qui nous sont arrivés plus tôt. Et donc le plus tôt on a appris ça, le mieux on s'est porté. À droite, l'image est très mauvaise, mais c'est un exemple d'outil de supervision. Là, c'est sur les erreurs. Mais plein d'outils de supervision qu'on a mis en prod et qu'on a customisés très tôt, des mois et des mois avant la grosse sortie du projet. Typiquement, dans la vie d'un projet, les outils de supervision, d'alerting, de monitoring, ce sont des choses qui arrivent tard, très tard, voire jamais. Là, on a eu des vrais problèmes, donc on a vraiment... Mettre en place des contre-mesures vis-à-vis de ces problèmes. Et la plupart des outils de supervision, maintenant ça fait un mois qu'on est en prod, on en a ajouté un tout petit peu, mais je ne sais pas, 90% étaient présents avant la sortie, la vraie 1.0. Donc ça c'est un énorme apprentissage. Accessoirement, ça permet aussi de mettre en plan les ops, ce que je vous disais tout à l'heure dans la boucle beaucoup plus tôt. Je ne vais pas vous parler de DevOps, mais les ops qui reçoivent les projets très tardivement, qui sont intégrés dans les projets très tardivement, qui ont l'impression d'être toujours la dernière roue du carrosse, là ils sont engagés beaucoup plus tôt, ils sont confrontés aux problèmes beaucoup plus tôt, ils discutent, ils collaborent avec les devs beaucoup plus tôt.
Donc ça, c'est super.
Ok, dernière pratique.
Dernière pratique, on a parlé des testisateurs, des déploiements au plus tôt. Dernière pratique, lorsqu'on est confronté à un choix, et ça, ça arrive tous les jours, on est confronté à des milliers de choix tous les jours, choisir le chemin qui maximise l'apprentissage, c'est souvent une super décision. Dans nos projets, vous voyez de la fumée et des flammes, et à gauche on entend les loups hurler, donc on doit choisir entre ces deux alternatives. C'est jamais aussi paisible que sur la photo.
N'empêche, le cas un peu typique, c'est que j'ai le choix entre deux features, en tout cas moi ces dernières années ça a été ça, j'ai le choix entre deux features, laquelle je développe. Elles sont à peu près du même coût, les développeurs me disent que grosso modo c'est la même complexité.
Pour les utilisateurs, C'est à peu près le même retour sur investissement, soit en termes d'audience, soit en termes d'usage. C'est à peu près pareil. Par contre, il y en a une qui va m'apprendre beaucoup. Il y en a une qui va m'apprendre beaucoup sur les usages du théâtre, parce que j'ai une grosse inconnue sur ce point-là. Je ne sais pas comment ça marche. Il y en a une qui va m'apprendre beaucoup sur la complexité technique, parce qu'elle va m'obliger à mettre le doigt dans ce module de moteur de recherche qu'on ne connaît pas trop, qui est un peu obscur. Ou alors il y en a une qui va m'obliger à déployer sur une nouvelle techno de serveur que je ne maîtrise pas du tout. Tout ça pour dire que vous avez souvent une alternative qui va vous apprendre beaucoup, va vous apprendre énormément. C'est souvent un bon choix de prendre ce chemin-là, de prendre le chemin qui maximise l'apprentissage. Alors, au final, qu'est-ce qu'on a appris? Ça marche rarement, voire jamais, comme on pensait que ça allait marcher. Même quand on a suivi toutes les bonnes pratiques, on a fait des design studios. Ça, les design studios, c'est quand vous mettez l'utilisateur dans une salle, vous faites des sprints très, très rapides de conception avec eux.
Des tests du théâtre, etc. Même si vous faites tout ça très bien, en bon petit élève scolaire, ça ne marche jamais comme on pense que ça va marcher. Les déploiements en production nous apprennent largement plus que toutes les autres pratiques. D'un ordre de grandeur, ça apprend infiniment plus. C'est pour ça que j'ai insisté sur la pratique déployée un peu vite, un peu mal, mais très très tôt en production.
C'est réellement là qu'on apprend. Et on sait au monde, là je vous ai montré des trucs qui marchaient à peu près, il y a plein de trucs qui ne marchent pas, vous devez le voir d'ailleurs vous aussi. On est très mauvais encore sur les tests utilisateurs, on n'en fait pas sur tous nos projets. Pour certains, on les outsource encore, on est long à les faire. Parfois on les fait bien et vite, mais on a un gros gros volant d'apprentissage encore là-dessus.
Du coup, qu'est-ce que je peux vous dire en conclusion?
Ça ne sert à rien d'être, vous vous rappelez, il y a trois domaines, en tout cas en ce qui me concerne. Ça ne nous sert à rien d'exceller dans l'apprentissage dans un des domaines. d'être super fort dans un domaine et d'apprendre de manière peu efficace dans les deux autres domaines. Du coup, je ferai un petit parallèle avec la théorie des contraintes. On va dire que l'apprentissage global, ce sera l'apprentissage, il sera aussi efficace que l'apprentissage de votre maillon le plus faible. Donc si vous avez une responsabilité cross-fonctionnelle,
essayer de maintenir un bon niveau d'apprentissage sur le produit, les devs, les ops, et de ne pas se focaliser sur un des domaines aux dépens des autres. Et voilà, ce qu'on a tenté de mettre en place et qu'on va continuer à mettre en place dans les mois qui viennent, c'est de favoriser des pratiques qui sont bonnes à la fois pour l'exécution menée à B. bien au projet, mais implicitement pour apprendre vite et bien.