Un jour, au détour d’une conversation sur je ne sais plus quel sujet, un copain me dit “Ah tiens : la méthode Scrum, faut que tu regardes ce que c’est, ça va carrément d’intéresser !”

Docile, je vais à la bibliothèque, et j’emprunte un livre qui s’appelle “La méthode SCRUM” (ou quelque chose de similaire) sans avoir aucune idée de ce dont il s’agit. Je commence à lire, et je réalise bien que je ne comprends pas grand chose. Au bout du 10 pages, je vois qu’il n’est question que d’informatique. J’ai mon père au téléphone par hasard à ce moment là (il est dans l’informatique) et je lui dis “Je suis en train de lire un livre sur la méthode SCRUM” ce à quoi il me répond : “Tu te lances dans le code ?”

Je ne comprends rien, je me demande pourquoi mon pote m’a parlé de ça, je vais voir sur internet et je découvre alors le concept de l’agilité. Je lis un peu, et comme toujours quand je découvre une méthode de travail, je réfléchis à une potentielle façon de l’adapter à notre boulot : l’écriture de visites guidées.

Je me relance dans la lecture du livre sur la méthode Scrum, en sautant toutes les parties 100% informatique mais en lisant attentivement tout ce qui est de l’ordre de la relation client, de la structuration du projet, etc.

Je reviens au bureau quelques semaines plus tard avec une nouvelle méthode de travail pour la conception de nos nouvelles visites. Plus agile donc. Nous découvrons ce nouveau langage mystérieux : backlog, itérations, release, sprint…

Création d’une application ou écriture de visites guidées : certains problèmes ne changent pas.

Ce qui m’a intéressé, c’est que nous sommes confrontés aux mêmes problèmes que les développeurs avant le développement des grands principes de l’agilité.

Lorsque nous décidions de lancer l’écriture une nouvelle visite guidée nous commencions par passer des semaines entières de recherches approfondies pour balayer la totalité du sujet. Ensuite, nous faisions un repérage terrain, souvent assez sommaire car nous avions la connaissance théorique des lieux et nous pensions que cela suffisait. Enfin nous passions au moins un mois à écrire la visite pour finalement la tester (une seule fois) et la vendre alors qu’elle pouvait être à des années lumières de ce qu’attendait notre public.

Cette méthode de travail était une grosse perte de temps et d’efficacité. D’abord, parce que l’on se noyait dans des recherches qui n’allaient jamais resservir pour cette visite ni pour aucune autre. D’aucuns nous répliqueront que les recherches historiques ne sont jamais perdues, que c’est toujours utile, etc. C’est vrai. Mais dans des moments comme ce mois d’octobre 2017, où nous accueillons une bonne centaine de groupes en un mois, et où il faut commencer la production d’une visite qui doit être vendue en janvier, on doit aller droit au but, pas le choix.

Ensuite, nous ne faisions qu’un seul test lorsque toute la visite était écrite. Ce seul test rendait les choses très compliquées car il fallait tout vérifier en une seule fois : la viabilité du parcours, la cohérence des scènes, le ton, le rythme, la compréhension des explications, etc.
C’était impossible.

Une de nos visites qui a été conçue de cette manière (Quand Molière joua à Lyon) a été retravaillée par la suite de très très nombreuses fois, jusqu’à 2 ans après la création de la visite, car il y avait beaucoup trop de choses à modifier après le seul test effectué.

Comment notre travail a été transformé

Nous avons donc adapté les principes généraux de l’agilité pour l’écriture de visites guidées. Désormais, nous commençons, dès le début du travail, par programmer 4 ou 5 tests. Le premier est un test parcours réalisé en interne qui nous permet de tester la longueur du parcours, la pertinence des lieux dans lesquels nous souhaitons nous arrêter, etc. Nous ne faisons pas venir de public, et à ce stade, le texte n’est pas écrit. Nous avons simplement commencé les recherches générales, sans entrer dans les détails, validé un principe général pour la visite et le ton du discours.

Après ce premier test, nous approfondissons les recherches pour aller trouver les détails utiles pour les scènes choisies. Cela nous permet de cibler les recherches et de perdre moins de temps. Nous préparons une première version de visite, on pourrait dire une version bêta, que nous testons avec ou sans public selon nos besoins. Nous pouvons avoir par exemple besoin de tester le parcours une nouvelle fois en interne si de nombreux changements ont été fait après le premier test.

Le travail continue ainsi, avec un certain nombre d’itérations jusqu’à la livraison du produit.
La totalité de nos tests publics sont suivis d’un temps de feedback. Soit sous la forme de discussions à bâtons rompus en fin de visite, soit de manière plus méthodique lorsque nous avons besoin d’informations plus précises. Nous faisons ensuite une analyse de ces retours en équipe, et procédons aux changements nécessaires.
Bien entendu, le travail ne s’arrête pas lorsque nous avons livré le produit car les visites évoluent beaucoup après leur lancement, mais elles évoluent plus lentement.

Cette méthode nous a permis d’être plus efficaces, mais aussi de mieux répondre aux attentes de notre public et de proposer des visites et des parcours beaucoup plus agréables et mieux travaillés.

L’écriture, la communication, la commercialisation

Ces principes et cette méthodologie ne s’appliquent pas qu’à l’écriture de visites guidées. Nous avons aussi pris l’habitude d’intégrer dans notre planning général de création tout ce qui touche à la communication, à la commercialisation.

Avant, nous étions facilement pris de cours. Nous n’étions concentrés que sur le contenu de notre visite, et soudain nous prenions conscience qu’il fallait aussi écrire un texte pour la présentation sur notre site internet, qu’il fallait faire des photos, ajouter une page au catalogue.

Grâce à la planification complète de la création de la visite et aux tâches bien précises qui correspondent à chaque étape, nous sommes capables d’ajouter au bon moment la rédaction des textes de communication, de prévoir sur quel test nous ferons venir le photographe. Nous pouvons aussi informer nos partenaires et clients de façon plus précise du moment où nous pourrons leur communiquer des informations sur la visite.

La méthode de la “Revue de Code”

La prochaine méthode que nous allons intégrer à notre travail sera le principe du “Code Review” ou “revue de code” en français.

Cet été, alors que je venais de passer 2 semaines non stop à écrire la visite qui nous avons produit pour l’Opéra de Lyon, je me lamentais du fait qu’il fallait désormais tout relire et que mon cerveau était en train de fondre. Un développeur qui passait par là m’a dit : “Mais vous n’avez pas un principe de code review ? Chez nous, celui qui relit doit toujours être différent de celui qui a codé !”

C’est une évidence ! C’est d’ailleurs ce que nous faisions lors des tests : une personne de l’équipe conduit la visite et les autres écoutent et prennent des notes qui serviront de relecture. Nous allons donc mettre en place ce système de relecture systématique après chaque phase d’écriture et comme pour le code, l’idéal serait d’envoyer à la relecture de petits paragraphes pour être plus efficaces, au lieu de relire la totalité du code d’un coup. Ça tombe bien, notre travail est toujours organisé en petits paragraphes qui correspondent à des arrêts de la visite.

Le mélange des pratiques et des genres

Ces expériences nous confortent chaque jour un peu plus dans l’idée que nous devons impérativement nous inspirer les uns des autres. En apparence, le métier de développeur informatique n’a rien en commun avec l’écriture de visites guidées. Et pourtant !…

Ainsi, chez Cybèle, nous continuons sans cesse de nous inspirer de toutes sortes de méthodes : écriture de scénario de cinéma, méthodes de brainstorming, créativité et génération d’idée en tout genre, agilité, et nous avons hâte d’en découvrir encore d’autres !

---