Pourquoi les gens s’obstinent à acheter des briques LEGO à leurs enfants, alors que nous connaissons tous la douleur de ces petits objets diaboliques dans nos coussinets au milieu de la nuit ?

Quand j’étais enfant, j’avais beaucoup de ces objets que je laissais traîner au sol. D’abord de grandes briques, puis de petites briques. Et puis des LEGO Technic. Des Meccano aussi, plus tard. On construisait avec mon frère les objets du manuel d’instructions. Les objets construits, c’était important !

Il faut bien l’avouer, c’était du solide ces instructions. Les objets construits étaient stables, identiques à la photo de la boite, et jolis. Enfin, ça c’est quand on avait bien compris les instructions du manuel. Et quand on n’avait pas perdu des pièces. Il a rapidement fallu trouver d’autres moyens de construire. Et puis on avait souvent des problèmes : quand les bâtiments étaient trop grands, ils s’effondraient. Ce n’était pas facile. On a inventé des manières de construire différentes, plus solides. On a dévié du manuel, et puis on a fini par perdre le manuel.

Beaucoup plus tard, à l’université, on nous a expliqué des trucs comme “Agilité”. Les histoires sont devenues des “cahiers des charges”, les manuels techniques se sont transformés en “design pattern”, les journées de construction des “sprints”. C’était toujours rigolo mais on avait pas toujours le temps d’améliorer les choses. Et puis on a découvert le “Craftmanship”, le “Peer-programming”. On a retrouvé le partage d’expérience, la co-construction, le “bien conçu”.

L’expérimentation.

L’échec.

L’apprentissage.

L’amélioration.

Ces autoroutes de la connaissance universitaire ne pouvaient en effet pas se suffire à elles-mêmes. Il fallait travailler, il fallait s’exercer. “Faites des gammes !” nous répétait alors un de nos professeurs de mathématiques. “Les musiciens s’entraînent en faisant des gammes, moi à la maison je pose des équations pour m’amuser”. Nous n’avions pas la même manière de nous amuser, mais nous aussi, nous faisions des gammes. Des centaines d’heures à écrire du PHP, du C, du C++, du Java. Comparer nos codes source, les améliorer.

Échouer.

Souvent échouer.

L’entreprise c’est du sérieux

Et puis, soudain après le diplôme: l’entreprise.

La structure. Le management. Les délais. L’absurdité parfois. La fatigue, souvent.

Le jeu ? Jamais. L’entreprise c’est du sérieux.

Pour continuer à tisser notre toile, il fallait trouver de la ressource par soi-même. Les livres c’était bien, mais rien de comparable avec les gammes. Alors on a continué à expérimenter, à comparer nos code source, à échanger avec les autres. Nous confronter à de nouveaux scénarios.

Et puis : le Cloud. AWS.

Les dizaines de services.

La documentation.

Les architectures officielles.

Les briques.

Le manuel.

Les instructions mal comprises.

Les pièces perdues.

L’improvisation.

Les bâtisseurs n’avaient pas dit leur dernier mot.

Une nouvelle route de la connaissance. Et pourtant, si familière. Enfouie depuis notre enfance. L’expérimentation. L’essai comme arme ultime du savoir.

Par millions, nous autres développeurs avons demandé des procédures plus souples, des mises en production plus rapides, des espaces d’expérimentation, la possibilité d’échanger avec des pairs. La culture de l’amélioration, la volonté de faire du mieux possible : nous avons embrassé le Craftmanship comme guide, tout simplement parce que ça fonctionne.

Et au milieu de tout ça : la réalité de la production. Comment savoir si ce plan de bascule qu’on a imaginé fonctionne ? Comment s’assurer que tout le monde peut le prendre en main ? “Hé bien il y a qu’à tester” disait l’autre. Mais c’est l’entreprise, l’entreprise c’est du sérieux. Alors on écrit des procédures, on limite le bac à sable, on s’assure que les personnes ont les scénarios à l’avance, et au final on déroule un cas d’usage tellement planifié qu’il ne se produira probablement jamais. La panique, le manque de documentation, les éléments mal compris, les pièces perdues : c’est tout le temps, toujours, partout. L’entraînement doit correspondre à cette réalité.

Bien évidemment je ne vous demande pas d’envoyer au broyeur toutes vos procédures. Cependant l’arme ultime de l’apprentissage, vous la connaissez depuis votre enfance, c’est l’expérimentation. 

Alors le temps de quelques heures, perdez les instructions du manuel, mettez vos équipes IT dans un parc de jeux et posez leur infrastructure au milieu de la pièce. Enfin, assurez-vous que chacun puisse comprendre et expérimenter celle-ci : envoyez quelqu’un détruire leur jouet, volez-leur des pièces, faites s’écrouler des parties du système.

Il ne s’agit pas seulement de chaos engineering. La gamification va au-delà de la stabilité et l’observabilité des systèmes, l’interaction entre les personnes est une composante importante. Récompensez les équipes et alors regardez se créer l’échange  entre elles. Vos équipes découvriront des solutions, identifieront les faiblesses du système, se débrouilleront pour remplacer les pièces manquantes, trouveront des contournements pour que la grue continue d’être stable. Peut-être qu’ils se disputeront. Peut-être que certains seront perdus. Peut être que vous constaterez que la survie de votre application tient à une ou deux personnes.

Ainsi émerge le modèle d’apprentissage par le jeu. Nous sommes tous des enfants forcés de jouer ensemble dans une grande cour de récréation qu’on appelle l’entreprise. Matéo ne saura pas faire du patin à roulettes sans avoir échoué en essayant. Léa n’osera pas sauter du toboggan si Marie ne l’accompagne pas. Bernard ne saura pas comment redémarrer le serveur Nginx si Joséphine ne lui explique pas. Jean-Philippe ne pourra pas savoir comment débugger efficacement l’application s’il ne l’a pas vu en erreur au moins une fois.

Entendons-nous bien, le GameDay ce n’est pas juste du Chaos Engineering. Celui-ci va au-delà de la stabilité technique des systèmes, car ce qui met en musique la technologie ce sont avant tout des humains et par conséquent des interactions entre professionnels. Rien de bien de révolutionnaire, que le manifeste Agile et le manifeste du software Craftmanship ne théorisent déjà, mais qu’il me semble adéquat de rappeler :

• “Individuals and interactions over processes and tools” – Agile Manifesto
• “Not only individuals and interactions, but also a community of professionals” – Software Craftmanship manifesto

Le GameDay comme outil de partage et d’amélioration

Le Gameday est cet espace que vous pouvez créer pour permettre à vos équipes d’apprendre ensemble à co-réparer, co-construire, co-améliorer. Un Gameday est un environnement d’expérimentation sûr où vos équipes IT pourront jouer à la vraie vie pour transcender leur quotidien.

A l’ère des applications distribuées et de la complexité grandissante des systèmes, dans la tourmente de la volatilité des compétences, l’apprentissage au fonctionnement d’un écosystème devient un enjeu primordial. Un système où la compréhension de chacun de ses intervenants est la plus profonde possible est un système qui tombera moins souvent en panne car davantage de personnes pourront y intervenir pour y corriger les problèmes.

Depuis plusieurs années, nous proposons dans nos offres de transformation une ou plusieurs sessions de GameDay, au choix : avec des environnements-type ou bien directement avec les environnements du client répliqués dans des écosystèmes isolés. Cette méthodologie nous permet d’exercer les équipes en situation réelle, d’identifier les lacunes de leurs infrastructures mais plus important encore de visualiser et corriger les différents niveaux de compréhension technique au sein des équipes en poussant chacun vers le haut.

L’expérience nous montre que les équipes qui ont suivi ce type de programme de formation sont non seulement plus confiantes dans leur maîtrise de leur SI, mais sont aussi davantage proactives dans l’amélioration de leur quotidien. Celles-ci auront su créer du partage de connaissance, mais surtout construire un environnement de sérénité intellectuelle.

En effet, au-delà de former les plus juniors à des tâches techniques, l’apprentissage par le GameDay et le partage d’expérience qu’il implique au sein du jeu permet aux plus expérimentés de gagner en sérénité sur la stabilité de leur écosystème, mais aussi de désacraliser la connaissance des composants historiques. Au sein d’une équipe, la confiance est une composante importante : chacun doit pouvoir demander de l’aide sans avoir d’appréhension.

Cela peut paraître quelque chose sur laquelle vous n’avez pas besoin d’agir, et pourtant cette sécurité affective est souvent difficile à obtenir lorsque les niveaux de compétence et de confiance sont hétérogènes et totalement impossible à mettre en place naturellement lorsque vous avez créé – volontairement ou non – des silos de connaissance.

Pour terminer, je ne peux que vous encourager à intégrer la pratique du GameDay au sein des parcours de formation de vos équipes, et à chaque nouveau projet. Ce n’est évidemment pas la panacée, aucune formation ne peut le prétendre; cependant, des avantages indéniables sur la technologie et l’humain émergeront de la pratique de ce “serious game”.

“Serious” car bien sûr, l’entreprise, c’est du sérieux.

Article initialement publié dans le hors-série reBirth, à télécharger ici.