Youen Chéné
Transcription
Bonjour à tous.
Pendant les vacances, j'ai voulu lire un livre que m'avait donné Dimitri Bailey, un des organisateurs.
C'était ce fameux livre. Qui a essayé de le lire, celui-là? Qui est allé jusqu'au bout?
Je suis toujours au deuxième chapitre.
Donc j'ai lu un autre livre qui est l'histoire de Jajinsky qui a été refaite par un Américain sur les écrits qui ont été republiés au siècle dernier. Et du coup, je vais vous faire un parallèle entre l'Empire mongol et les start-up, avec tout ce que... Qui est similaire à l'approche Lean, à l'approche Kanban et tout ça.
Je me présente, je suis Youn Chiné, je suis le directeur technique de Sagi. On est un éditeur basé à Rouen, en Normandie, on a toute l'équipe de R&D là-bas. Et je suis notamment activiste dans tout ce qui est codeur en scène, DevOps for Kids, et tout ce qui est association avec les startups comme NWX.
On va faire ça en cinq parties. Une première partie pour vous montrer vraiment le parallèle. Ensuite, ce qu'on a fait, comment on l'a fait. Et après, ce qu'on a appris et comment on va vers la croissance plus tard.
Le premier point, c'est l'Empire mongol. Pourquoi ce parallèle? L'Empire mongol, c'est un empire qui s'est créé en moins de 80 ans, en l'an 1200 et quelques. Ils avaient un système logistique qui leur permettait de faire entre 200 et 300 km par jour. Ils voyaient très léger, c'était déjà très lean à l'époque. Et ils sont allés du bout de la Corée, du bout de la Chine, jusqu'au bout de l'Ukraine, la Tchécoslovaquie et tout ça. Et ils avaient un modèle économique d'hypercroissance qui était le loot, en gros le pillage de villes pour prendre des ressources, mais aussi pour aller chercher des connaissances. Quand ils avaient une ville ou un village, ils prenaient le village, ils triaient les personnes par métier et ils incorporaient les personnes avec les métiers qu'ils intéressaient dans leurs équipes. Et ensuite, la ville vivait en autonomie. Et il continuait, il continuait, il continuait. Ce qui fait qu'on avait énormément de richesses qui arrivaient, et qui arrivaient parmi les chemins, parmi la route de la soie, qui arrivaient en Mongolie après.
Et ça a été très, très, très vite. C'est comparable à une start-up qui va aller conquérir un maximum de marchés, avoir un premier monopole sur un marché très, très vite.
Ils ont été très innovants dans ce qu'ils ont mis en place. Ils avaient une organisation militaire qui était très scalable, mais avec pas mal d'autonomie aussi.
Et ils ont surtout battu des vieux empires. C'était les premiers à faire tomber Bagdad, qui était une ville réputée imprenable, dans le monde du Moyen-Orient, qui était très riche à l'époque. C'était les premiers à le faire et souvent ils étaient deux fois plus de guerriers en face avec des grosses armures et tout ça.
Et vous allez voir le parallèle tout au long de cette présentation.
Mon sac, il est là.
Donc la première partie est très courte. Là, on va avoir deux grosses parties pour ça.
La première partie, c'est que comme les Mongols, on attaque des gros empires.
On fait une plateforme as a service dans le big data. Donc il y a déjà au moins deux buzzwords dans le titre. Et nos concurrents en face chez nos clients, ça va être IBM, ça va être Oracle, ça va être SAP avec Business Object. L'objectif, c'est de faire tomber Business Object. Et ça va être aussi Microsoft. Tout le monde est concurrent de Microsoft. Après, c'est différent.
Et ils ont un gros avantage, c'est qu'ils ont plein de sous à la banque. Ils peuvent exécuter ce qu'ils veulent avec tout l'argent qu'ils veulent. Ils ont un gros désavantage, c'est qu'ils ne vont pas vite.
La vision a été un peu perdue. On le voit avec le changement à Microsoft, la vision est plus claire, mais l'exécution est plus lente. Et le client est un numéro.
On peut faire la différence en étant agile, rapide, parce qu'on attaque un marché. On ne fait pas de la politique parce qu'on vend du service à un client. On attaque un marché. Et l'autre point de ces détails, c'est aussi de prendre soin de nos clients, qu'ils ne soient plus un numéro.
Et donc, il y a une étude qui est disponible sur TED, vous avez le lien en bas, vous aurez la présentation, c'est qu'est-ce qui fait qu'un startup est un succès. Donc, il a fait une étude statistique sur pas mal de choses. Et ce qui a été révélé, c'était le timing le plus important. Ce n'est pas le nombre d'argent levé, ce n'est pas forcément l'idée ou le business model, mais c'était vraiment le timing.
Pour les plus pointillés, le score est aussi supérieur à 100 parce qu'il y a plusieurs réponses possibles à chaque fois. Et comment on arrive à ce timing? Qu'est-ce que je vais utiliser? Est-ce que je vais utiliser du bon cycle en V? En faisant je design, je fais, je teste, je mets en prod. J'aime bien d'ailleurs la conversion en anglais qui est waterfall, c'est-à-dire qu'on tombe toujours dans le fond.
Ça ne se relève pas.
Et pourquoi l'agilité? Parce que pour une start-up, c'est une question de survie. Si vous mettez votre produit trop tard, vous mettez 500 000 euros, 1 million, 1,5 million, 2 millions de budget pour faire la R&D. Si vous arrivez trop tard et que tout le monde a pris le marché, vous avez perdu l'argent. C'est vraiment une question de survie.
Est-ce que les personnes que vous avez amenées dans l'aventure, est-ce que les commerciaux, les développeurs, les marketeux, l'ARH, tous ceux que vous avez amenés, viennent pour rien? C'est vraiment une question de survie. Donc on a Scrum, qui est en gros l'itératif par marge d'escalier. On cadence et on améliore.
Moi, je ne suis pas un grand fan de Scrum. C'est bien pour commencer parce qu'il y a des règles qui rassurent, notamment pour les grands groupes et tout ça. Moi, j'avais besoin de quelque chose qui prenne plus en compte le contexte. Donc on est parti plus sur du Kanban, c'est-à-dire qu'on part d'un fonctionnement actuel à 2-3 et on améliore le fonctionnement en fonction du contexte. Contexte, c'est quelque chose qui va revenir dans la présentation. Comment on s'adapte au contexte? Le contexte est important. Comment on s'adapte au terrain? Comment on s'adapte à l'équipe qu'on a?
Et d'être toujours prêt à changer, à s'adapter. Vous avez toujours une question de survie.
Car je vais prendre la partie Darwin, c'est-à-dire que ce ne sont pas les plus intelligents qui gagnent. Si on prend les sociétés qui ont beaucoup marché, souvent on a des gens pas très intelligents en haut, mais ils ont juste exécuté, ils ne sont pas trop posés de questions. Ils sont adaptés très vite au terrain au lieu de faire des grands plans pour tout prévoir.
Et l'autre point, c'est qu'on a fait du lean startup, c'est-à-dire qu'on a livré un premier produit qui n'était pas trop cher à développer. On l'a mis aux mains, on l'a vendu même à des premiers clients, des utilisateurs. On a pris de la donnée et on a corrigé au fur et à mesure. Et on a fait évoluer notre roadmap au fur et à mesure. On avait quand même une vision, mais on l'a enrichie au fur et à mesure. L'objectif, c'est qu'on a commencé par ce qu'on appelle un minimum viable product. Donc souvent, il ne faut pas oublier soit le minimum, soit le viable. Le minimum, on a essayé de tout mettre dedans, où le viable, en fait, ça ne sert à rien, ça n'a pas de valeur. Il faut que ça apporte de la valeur, quelque chose pour le client. On verra comment on a fait. Et comme on est chez The Family, un des accélérateurs, c'est« fake it until you make it», c'est-à-dire que le tout n'est pas obligé de marcher derrière. Je prends les sociétés comme Full Contact, ou comme plein d'assistants, Full Contact, ça scanne votre carte de visite et ça vous le fait automatiquement. Derrière, ça va être des algorithmes de deep learning.
Mais la vérité, c'est que quand la machine n'arrive pas, ça arrive chez un humain qui va l'écrire, globalement, qui va faire apprendre la machine. Sauf que pour vous, c'est transparent, vous ne le savez pas. Et donc, ils ont mimé une partie du fonctionnement pour savoir si le marché prenait ou pas.
Et ça peut être très dur de se rendre compte au bout d'un certain moment.
C'est une faute de vache pour ceux qui sont dans le fond.
Et surtout, on provient des écoles d'ingénieurs des universités françaises où on apprend à faire bon du premier coup.
Il y a une société qui s'appelle Michelin. Le motto pour la production, c'est faire bon du premier coup. C'est difficile de l'appliquer à l'informatique. Donc l'objectif, c'est de faire quelque chose qui fonctionne, même si ce n'est pas parfait, mais ça ne prend pas les 5% de besoin sur le côté pour faire des arbitrages. Et quand vous mettez un produit sur le marché, vous n'êtes pas embarrassé par le produit. Peut-être que vous allez livrer trop tard. Peut-être que vous allez trop polir les choses. Ce n'est pas valable pour tout le monde. Si vous faites du hardware très performant, vous avez besoin que ce soit quasiment parfait du premier coup. Si vous faites du logiciel qui est livré sur un marché où ça bouge beaucoup, où il y a beaucoup de concurrence, vous devez tester le marché. Et surtout, vous devez prendre la boucle de retour. C'est ça le plus important dans une startup. C'est vraiment, on prend les données, on le fait, on le fait, on le fait. Là, on va livrer une version où c'est que les retours des clients, des intégrateurs et de ceux qui font l'époque en interne pour les clients.
De juin, juillet, août. On a pris ça, on a pris tous les changements et on les intègre là pour qu'ils soient à disposition. Et surtout, on discute avec le client, on y va. C'est-à-dire que moi, j'y vais en mode, je ne vends rien, je prends juste du retour et on voit ce qui ne va pas. Tout le monde met un point sur l'expérience utilisateur.
Par exemple, dans les années 2000, vous avez beaucoup d'applicatifs. On va prendre IBM pour installer quelque chose, c'est plein plein de next, suivant, suivant, suivant, on ne lit plus, ce n'est pas beau, on est perdu, il y a trop d'informations à l'écran. Ça demande de travailler sur quelque chose de plus agréable à l'écran.
Comment on a fait ça? Parce que l'objectif, quel que soit le mode d'agilité qu'on fait, c'est de livrer de la valeur à chaque partie. Comment on fait une version incramentale qui est utilisable? De passer à« j'assemble des composants au dernier moment» à« j'ai quelque chose qui marche».
Ça, c'est Sagi Manager, ça sert à gérer votre production Big Data avec tous les jobs de traitement de data science au-dessus de ça. Ça, c'est la version 1.0, la première support à long terme qu'on a livré en septembre.
On a commencé avec une première version, j'ai ressorti le screenshot il y a quelques jours, et ça ressemblait à ça à l'époque.
Je crois que c'est moi qui avais fait le graphisme globalement.
Et on avait deux fonctions principales pour le premier client, qui était de faire des jobs talent et de faire des jobs Java. C'est tout. Après, on avait toute la partie stockage, mais ça, ça allait à peu près. Et ça, on l'avait vendu à un premier client. La première version, elle était en proche à un premier client.
Et ça, c'était la version 0.4. La version 0.1, 2.3 n'ont jamais marché. C'était les premiers prototypes. Ça ne marchait pas ensemble. Et c'est vraiment la 0.4 qu'on a quelque chose qui fonctionnait. Ça s'appelle le Darwiniste. Il faut que ça survive. Deux mois après, on a livré une deuxième version où on a mis Spark. C'est le framework le plus hype dans le Big Data depuis un an et demi, pour ceux qui ne connaissent pas, et d'autres fonctions.
Ensuite, on est arrivé avec une nouvelle interface qui est un peu plus belle, qui est un peu plus visible avec un petit peu moins d'informations. On a ajouté R, on a ajouté Docker. R, c'est pour faire de la statistique. Et là, on est en version 0.6, on doit être en novembre-décembre de mémoire. Et après, encore une version au bout de 7,5 mois. Donc vous voyez, c'est un ou deux mois à chaque fois. Attention, c'est une plateforme as a service. C'est-à-dire que ce n'est pas juste une application mobile qu'on livre, c'est une plateforme pour héberger les applications. Donc il faut que ça fonctionne et il faut que ça soit stable. Sachant que le premier client venait du retail, donc pour ceux qui ne connaissent pas le retail, c'est pas payer très cher et c'est très très exigeant. Donc il faut que ça fonctionne.
Et enfin, on a fait une autre livraison avec un nouveau client, on a mis de la sécurité. Parce que c'était une banque. Et là, on a un peu souffert, on a mis un demi-mois de plus, un mois de plus. Et même la version d'après, on a encore rajouté de la sécurité. Pour que tout soit bien sécurisé, l'identification, l'identification. Donc toujours, on est sur un cadencement d'un ou trois mois. Et comme on est une start-up et qu'on veut attaquer le marché, on a même fait du matériel.
Une première version de matériel. Ce n'est pas nous qui l'avons fait, on l'a fait sous-traiter. Mais pour avoir quelque chose de prêt pour le 16 de Las Vegas au début d'année, on a dû rocher, on a dû couper des fonctionnalités, mais on a quelque chose qui était présentable, qui était déployable et qui apportait de la valeur. C'est-à-dire avoir sa data,
dans les data centers des clients, sans que ça aille dans le cloud de chez Google ou de chez Amazon. Par exemple, en banque, réglementairement, ils ne peuvent pas sortir la donnée sur certaines données, sinon c'est amende dans le mois.
Après, on a sorti encore une autre version. Donc, on avait notre beau vélo avec plein de fonctions avancées pour avoir des jobs bien gérés et versionnés comme une application Android, etc.
Donc on a pris des noms de la conquête spatiale. Donc Astérix, c'est le premier satellite français qui a été déployé dans l'espace. Vous verrez avec le nom à la fin. Et là, on a plus de 10 instances en prod, donc on a un peu plus de revenus qui est arrivé, tout ça. On fait des POC avec les clients.
Et on se rapproche peu à peu de l'1 à 0. Bon, c'était presque prêt, donc on a sorti une 0,10 intermédiaire, parce que le délai commence à augmenter, donc on a dit, OK, on a 4 features, on les sort, on a une version, on déploie. On avait de la valeur à délivrer qui était en stock. Si votre développement est en stock, il n'a aucune valeur.
Et on a fait une nouvelle interface pour arriver enfin à l'A0, donc Apollo 11, l'arrivée sur la Lune, qui était le rêve du CEO à la base. Et avec des dernières fonctions comme des pipelines de data et tout ça. Donc ça, toujours tous les 3-4 mois. Et enfin, on est arrivé, ce mois-ci, on a fait une série A, on a levé 4,2 millions. Pour pouvoir attaquer le marché avec des hordes de commerciaux, des hordes de marketeux et des nouveaux développeurs pour renforcer l'équipe. Pour pouvoir attaquer ça, pour pouvoir attaquer les empires qu'on avait vus. Mais au lieu de faire un projet sur deux ans, on a délivré la valeur tous les deux ou trois mois.
Donc c'est beau comme ça, mais comment on a fait ça ?
Donc on va attaquer la troisième partie.
En gros, l'art de la guerre. Ce que vous voyez, c'est un schéma qui sont les tactiques qui ont été faites quasiment sur place par les Mongols. Où là, en fait, il y a un petit troupe qui attire l'armée ennemie. Ils prennent fuite jusqu'à un point qu'ils avaient décidé avant. Et ensuite, il y a des armées qui attaquent sur le côté.
C'est comme ça qu'ils ont battu de grosses armées à cheval, avec des grosses armures en Ukraine et tout ça. Et au passage, ils se sont arrêtés dans cette partie de l'Europe parce que l'Europe était une partie très pauvre à l'époque. Le modèle économique, c'était le loot, c'était le pillage. Donc ils se sont arrêtés là, sinon ils auraient été jusqu'en France et tout ça. Parce que dans le Moyen-Orient, c'était beaucoup plus riche. En gros, l'art de la guerre. Ce que vous voyez, c'est un schéma qui sont les tactiques qui ont été faites quasiment sur place par les Mongols. Où là, en fait, il y a un petit troupe qui attire l'armée ennemie. Ils prennent fuite jusqu'à un point qu'ils avaient décidé avant. Et ensuite, il y a des armées qui attaquent sur le côté.
C'est comme ça qu'ils ont battu de grosses armées à cheval, avec des grosses armures en Ukraine et tout ça. Et au passage, ils se sont arrêtés dans cette partie de l'Europe parce que l'Europe était une partie très pauvre à l'époque. Le modèle économique, c'était le loot, c'était le pillage. Donc ils se sont arrêtés là, sinon ils auraient été jusqu'en France et tout ça. Parce que dans le Moyen-Orient, c'était beaucoup plus riche.
Vous pouvez faire n'importe quoi, du cycle en V, du Kanban, du Scrumban, du Scrum. Ce qui compte, c'est le code que vous livrez.
Si votre code n'est pas bon, s'il ne sent pas bon, si à chaque fois c'est dur de rajouter une fonctionnalité, pour faire tout ce que vous voulez, vous ne serez pas agile, vous mettrez du temps à sortir les nouveautés. Vous prenez du retard. C'est une présentation de Venkat, qui est sans doute un héritier des Moguls. En gros, c'est une ancienne partie de l'Empire mongol qui est arrivée en Inde et qui a gouverné l'Inde pendant trois siècles. Qui a fait une présentation au dernier DevOps. Elle est en anglais, je vous ai mis le lien. En gros, vous ne pouvez pas être agile si votre code n'est pas bon. Pour faire tout ce que vous voulez, il faut que vous travaillez votre code. Donc on va en parler de dette technique. Comment on gère la dette technique de ça? Comment on fait qu'on puisse livrer des choses? En gros, si vous avez trop de dette technique, vous avez un gros boulet au pied.
Et dans 18 mois, vous êtes mort parce que vous ne pouvez plus livrer de nouvelles fonctionnalités. Ça prend 2, 3, 4 mois de plus et les concurrents, ils arrivent. Et nous, on a vu, on est arrivé un peu en avance. Depuis six mois, on a pas mal de concurrents qui arrivent. Donc comment on fait pour être aussi agile qu'eux? Parce qu'eux, ils viennent de commencer, donc ils n'ont pas de code, ils n'ont pas d'héritage.
Après, vous pouvez dire pas de technique. Je vais faire mon truc parfait avec les règles de l'art et tout ça. Après, les règles de l'art en informatique, il y en a plein.
Si vous faites ça, vous êtes un mort vivant. C'est-à-dire que vous ne sortirez jamais votre produit. Et vous êtes mort, mais vous ne le savez pas encore. De toute façon, vous arriverez après les autres.
Et enfin, un des autres défauts que je trouve qu'on a en France, c'est de faire de l'over-engineering. Moi, j'ai fait une école de mécanique, où on faisait des schémas avec des roulements et tout ça. Donc on était très bons pour faire des choses compliquées.
Et l'over-engineering, c'est vous n'étrez jamais, parce que ça ne sortira jamais. Et surtout, c'est une histoire de contexte. Ce qui m'intéresse dans le commerce, c'est l'adaptation au contexte. C'est-à-dire que ça, vous ne ferez pas du VTT en montagne avec ça. Je vous le dis tout de suite, c'est un avion.
Ça ne sera pas adapté au contexte.
Et donc l'objectif, c'est d'avoir le bon niveau.
Comment on a mis ça en place ?
Ce qu'il faut savoir, là, c'est différentes tactiques qui ont été mises en place par les Mongols.
Des attaques, des attaques en circulaire autour de l'ennemi, des attaques à répétition pour qu'il n'y ait jamais d'arrêt, le fait de feindre la fuite.
Il y a un point important dans cette organisation, c'est qu'en fait, vous avez des équipes autonomes.
En fait, là, vous avez des équipes autonomes, d'autres équipes autonomes, d'autres équipes autonomes, qui, elles, peuvent s'adapter au terrain.
L'objectif, c'est de commencer à construire des équipes autonomes avec une mission spécifique. On leur donne le pourquoi, ce qu'ils doivent atteindre. Ça reprend des choses qu'on a vues hier, par exemple. L'objectif, c'est de s'adapter au terrain.
Ils peuvent choisir leur langage, leur camban, leur mode de fonctionnement, etc. Et surtout, ils sont responsables de la dette technique.
Parce que c'est eux qui sentent la peine de ça. C'est eux qui ont les problèmes. C'est eux qui font que quand on doit rajouter un bouton rouge à tel endroit qui fait telle chose, si c'est compliqué à faire, c'est eux qui le sentent. Donc ils ont, pour le moment, une journée par semaine. Mon rêve, c'est de le mettre à deux, trois jours.
Pour retravailler ça, pour faire que ça soit plus rapide et tout ça. Et ça va même plus loin, ils ont même rajouté l'équipe des petites nouveautés que moi je n'avais pas vu, pas demandé, mais qui sont très pratiques pour un utilisateur. Par exemple, ils ont raccourci de moitié le délai d'apparition des statuts. Et ça, quand le commercial a fait la démo, il était content parce que c'était beaucoup plus dynamique. Mais ce n'était pas demandé dans les stories. Ils ont fait ça en plus parce qu'ils ont retravé le moteur derrière. Donc ça crée un peu d'innovation locale.
Et surtout, ce que je demande, c'est de ne pas demander la permission de faire quelque chose. Si vous voyez qu'un truc n'est pas bon, il faut le corriger tout de suite. Ou prévoir de le corriger. Parce que c'est la survie de la société qui est en jeu.
On n'est pas dans une banque ou une assurance où l'argent rentre tout seul. Là, on est à la recherche d'un modèle économique. C'est plus compliqué. Donc il faut sortir ça à temps.
Donc on a réservé du temps toutes les semaines. Et après, l'objectif, c'est qu'on va parler de code. Donc on parle de test automatique, unitaire, on teste les parties de code, d'intégration, de bout de fonctionnement de bloc. Si vous n'en avez pas, donc au début, on fait une startup, on a 24 ans, on fait du Node.js, on va à toute vitesse, on va faire le premier truc. Le bout d'un an, ça devient compliqué parce que chaque fois qu'on y fait un truc, on pète quelque chose. Nous, on n'est pas encore assez bons dessus. Et le problème, si on ne le fait pas, ça va être compliqué pour tout le monde.
C'est-à-dire qu'à la fin, ça ne sortira plus aussi. Donc ça demande du travail, ça demande d'être expert dans son art du code, dans son art de la guerre.
Continuez par une autre partie.
On a la partie logicielle, mais on a aussi des parties déploiement, des parties support, des parties même recrutement. On a des cambans internes pour le faire. On suit le flux. Un recrutement, c'est quelqu'un qui dépose son CV, il est sélectionné ou pas. Ensuite, il fait un entretien de qualification, après avec l'équipe, après avec l'ARH, et après il y a la négociation, puis après il y a l'embauche, etc. Donc c'est un flux où on élimine au fur et à mesure.
Et c'est vite du volume. Et ce qu'on fait, c'est qu'au début, on expérimente les cobranes avec Trello, parce que c'est très rapide, c'est facile à faire et tout ça. Là, c'est le même, en fait. Pas à la même date, mais c'est le même. Et après, une fois qu'on est à peu près stable, que tout le monde a bien compris comment on le fait, on le productise, si je peux me permettre l'anglicisme,
sous Jira parce que sous Jira je peux faire plein de statistiques. Et surtout je peux sortir la donnée beaucoup plus facilement que sur Trello. Et c'est entièrement configurable.
Et comme nous on fait du big data, on a un lac de données internes où je déverse tout Jira, je déverse tout Jenkins, toute la saisie des temps, comme ça je peux avoir les pourcentages de support et tout ça, et on peut faire de la statistique. Et ce qu'on est en train d'essayer de faire avec les chefs de projet ici présents, c'est de ne pas baser l'estimation qu'on fait pour l'époque de nos clients pour savoir comment ça prend de tester telle valeur et tout ça. sur le passé, en gros, tel type de story, on met tant de temps pour la faire à 80% ou à 50%. En gros, ce qu'on peut dire, c'est que si on vend un accompagnement, si tu as tant de jours, tu as 70% qu'on ne dépasse pas les temps.
Si tu vends ton jour, tu es à 90%, donc tu es bien. Si tu vends ton jour, tu es à 40%. L'objectif, c'est de partager le fait, le risque de s'engager ou pas. Et ça, c'est basé sur la statistique.
On y reviendra un peu plus tard. Enfin, ce qu'il faut savoir, c'est que ce qui a fait le succès de l'Empire mongol, c'est la logistique.
C'est-à-dire que c'était un pré-internet, c'est-à-dire qu'ils savaient voyager léger, et en fait ils étaient sur la route de la soie à la base. Et en fait, au fur et à mesure des conquêtes, ils ont créé plein de routes, où leur objectif c'était d'amener le maximum des loups, des biens, vers le central, vers l'équivalent d'Oulan Bator à l'époque. Et pour ça, il devait faire déjà circuler l'information très vite, mais aussi faire circuler les biens, les techniques. En fait, ils n'ont jamais rien inventé. Par contre, ils ont su réutiliser au maximum ce qu'il y avait. Ils ont intégré plusieurs religions, ils ont intégré des techniques de catapulte et tout ça. Ils ont intégré de nouvelles méthodes pour forger les épées et tout ça, mais ça, ils l'ont pris au fur et à mesure de leur conquête. C'est-à-dire que quand ils prenaient un village, ils gardaient les ingénieurs à l'époque, les artisans, pour faire du craft et pour améliorer ça.
L'équivalent en interne, c'est que là je suis en train de construire des équipes de support pour essayer d'accélérer les autres. Pour l'UX design, pour l'exploitation, bientôt pour la RH.
Pour accélérer les cambans des autres, pour apporter des spécialités, pour accélérer les autres. Ça reprend une des parties de l'organisation Spotify. En gros, l'objectif, ce n'est pas que la QA et l'exploitation ne soient pas des goulots d'étranglement dans l'exploitation, dans la livraison de choses, mais que ce soit des accélérateurs. Donc c'est plus des équipes de support. L'objectif c'est vous le faites, vous le mettez en prod. Vous êtes responsable jusqu'au vous. Si vous codez mal et que vous aurez beaucoup de support, ce sera de votre faute. Par contre, on ne peut pas être expert en UX design, on ne peut pas être expert en Linux, en réseau en même temps. Donc il y a des équipes pour les aider en interne, pour essayer d'accélérer ça.
Il faut savoir que l'Empire mongol a vécu longtemps comme ça, beaucoup, et c'était aussi la cause de leur déchéance. Parce qu'en fait, pourquoi à un moment l'Empire s'est écroulé? C'est que la peste est apparue en Europe. Et comme ils avaient des moyens logistiques très importants, où le moindre bien partait de l'autre bout de l'Asie, de l'autre côté, ça a aussi amené la peste en même temps.
Et du coup, quand ils se sont rendus compte au bout de 50 ans que c'était la source, ils ont coupé les voies de communication. Quand ils ont coupé les voies de communication, Ils ont coupé les richesses.
Et quand il n'y avait plus de richesses, les populations se sont révoltées. Et c'est tombé comme ça. C'est tombé parce que la logistique était très bonne. Parce que ce n'était pas isolé, c'était très communiquant. Et là, le challenge à venir, c'est vraiment comment je fais communiquer des admins 6 avec des développeurs pour que ça tourne, parce que je change un peu le périmètre des admins 6.
Quatrième partie, là on va voir tout ce qu'on a appris. Ça va être assez court. Regarde l'heure.
Donc, temps de guerre, temps de paix.
Dans les armées, il y a toujours les deux organisations pour être rapide et après pour responsabiliser les gens. Si vous prenez beaucoup de livres de management, c'est beaucoup des livres de militaires américains.
On en verra un tout à l'heure. Et comme les Mongols, j'ai été payer une autre présentation, celle de Café Netflix, il n'y a pas très très longtemps, sur leur culture. Enfin, c'est pas 2001. Sur leur culture, c'est comment ils fonctionnaient en interne. Donc il y a différents points. Et je vais reparler de contexte, la partie contexte et contrôle. Parce que du coup, on a fait des groupes autonomes, mais sur certains groupes ça a fonctionné, sur certains groupes ça ne fonctionnait pas.
En gros, le principe, si tu rends une équipe autonome, au lieu de lui dire, comme dans la keynote d'hier, de construire le pont, c'est va de l'autre côté de la rivière. Ensuite, l'équipe est autonome pour résoudre ce problème. C'est-à-dire que s'il y a des problèmes sur le terrain, elle peut s'adapter à ça, parce qu'elle connaît le but ultime.
Et l'objectif des managers, c'est que le contexte soit assez bon pour que les gens puissent s'adapter, que les gens soient héros et compétents dans leur travail.
Et donc le contexte, ça permet de... C'est en gros les nouveaux modes de management. On va donner un contexte, on va pouvoir mesurer ce qui se passe, on va pouvoir donner l'autonomie et avoir une organisation apprenante. Le contrôle, c'est tu fais ça, ça, ça, ça, ça, ça, ça, et tu ne débordes pas, il faut que ce soit exécuté. Là, en gros, ça vient du Taylorism, c'est pour tout ce qui est productivisme. Sauf que produire du logiciel, c'est du code, ce n'est pas du productivisme. C'est-à-dire qu'on fait quelque chose de nouveau à chaque fois. Si c'est pareil, on fait une boucle.
Et le problème, c'est qu'on applique des méthodes qui viennent du siècle dernier, mais qui sont pour des usines où on fait toujours la même pièce, où il y a un tag time, un cadencement, et il faut que ça sorte.
Là, c'est plus compliqué. Cependant, sur le terrain, des fois, il y a des exceptions. Et l'exception qu'on a eue, c'est quand les gens sont en train d'apprendre leur art, sont en train d'apprendre leurs différents niveaux.
On a eu quelques problèmes.
Et donc, il faut toujours s'adapter aux changements.
Et en fait, on avait des équipes, notamment sur le produit, on a embauché des développeurs expérimentés.
Où le contexte autonome tournait très bien. En management textien, il n'y avait pas grand-chose à faire. Il y avait quelques arbitrages, mais ça tournait très bien. On est des équipes plus jeunes, notamment sur la partie data science. Si vous voulez embaucher des data scientists, c'est dur d'avoir des gens expérimentés. Et là, c'était plus compliqué. Donc du coup, on a deux contextes différents. Là, on va garder ce que j'ai présenté précédemment, mais là, on va mettre pour le moment plus de contrôle le temps que les personnes apprennent. Ça reprend le shu-ari qui vient des arts martiaux qu'on utilise souvent. Shu, j'apprends les règles. A, je les masterise. Et ri, je vais au-delà des règles pour inventer. Là, j'ai des personnes entre le A et le R, et là, j'ai des personnes qui sont en train d'apprendre. Et dans ce contexte d'autonomie, on a eu des problèmes de qualité, des problèmes de délai, il y a plein de choses qui n'allaient pas, et donc du coup, on a mis plus de contrôle. C'est, tu utilises ces outils-là, tu fais ça, ça, ça, ton comportement, c'est ça, ça, ça, on le standardise. Alors que là, ils ont leur comportement, ils le modifient en fonction de leurs besoins, en fonction de leurs problèmes. Et là, on est plus en position de coach, de mentor pour que ça tourne. Au début, c'est vraiment la période d'appréhension. Peut-être que dans un an, six mois, ça va passer de là à là, on va libérer plus de choses. On a dû remettre plus de contrôle sur certaines parties. Et ça, c'est vraiment le terrain qui nous l'a appris. Là j'ai des personnes entre le A et le R, et là j'ai des personnes qui sont en train d'apprendre. Et dans ce contexte d'autonomie, on a eu des problèmes de qualité, des problèmes de délai. Il y a plein de choses qui n'allaient pas. Et donc, du coup, on a mis plus de contrôle. Tu utilises ces outils-là, tu fais ça, ça, ça. Ton camban, c'est ça, ça, ça. On le standardise. Alors que là, ils ont leur commande, ils le modifient en fonction de leurs besoins, en fonction de leurs problèmes. Et là, on est plus en position de coach, de mentor pour que ça tourne. Au début, c'est vraiment la période d'appréhension. Donc peut-être que dans un an, six mois, ça va passer de là à là, on va libérer plus de choses. On a dû remettre plus de contrôle sur certaines parties.
Et ça, c'est vraiment le terrain qui nous l'a appris.
Dernière partie, comment on scale ? Le problème d'un startup, c'est d'avoir une bonne scalabilité. Parce que pourquoi on lève de l'argent? C'est pour courir plus vite que l'autre.
Sinon, on fait une PME et on fait de la croissance organique, mais on grossira petit à petit. Là, l'objectif, c'est d'aller très vite, de courir avec les chevaux dans toute la steppe pour qu'on courir l'ensemble de l'Asie et de l'Europe. Les Mongols étaient très lignes dans leur approche. C'est-à-dire qu'ils voyageaient très léger, ils avaient de la viande séchée pour que ce soit le plus léger possible. Et après, ils avaient des points de réapprovisionnement quand ils payaient des villages, bien sûr.
Et donc on va aller du côté du Japon, que les Mongols n'ont jamais réussi à conquérir. Il y avait la mer à traverser, et ils n'étaient pas dans leur contexte habituel, ils n'ont jamais réussi. Ils ont perdu beaucoup, beaucoup d'hommes là-dessus. Le muda, c'est le gâchis, mais au sens large du terme. Ce n'est pas je produis quelque chose qui ne sert à rien, c'est aussi je fais quelque chose qui ne sert à rien. Je fais quelque chose qui n'apporte pas de valeur.
On est en start-up, je travaille dans des grosses sociétés, ça permet de virer les personnes négatives, les personnes qui ne s'assurent pas, et surtout de ne pas les embaucher au début. Et là, on est dans un instant particulier, on a levé beaucoup d'argent, on n'est plus visible, donc du coup, on a pas mal de parasites qui arrivent. Il faut pouvoir sélectionner parmi ça. Et mine de rien, ça permet de faire tourner. Je ne sais pas, est-ce que vous connaissez la fable du poulet et du cochon ou pas, ici? Non?
En fait, c'est un poulet qui demande à un cochon, est-ce qu'on peut monter un restaurant d'omelette au lard?
Et le cochon, il ne veut pas parce que c'est sa cuisse, c'est lui-même qui va vendre. Et le poulet, il pond juste des œufs. Donc lui, il ne s'implique pas, il ne perd rien. Quand vous faites par exemple un délice crème et tout ça, les poulets, ça va être ceux qui viennent, mais qui ne sont pas impliqués dans le projet, qui n'ont rien à perdre. Donc ils peuvent mettre le bazar, de toute façon, ils ne sont pas impactés.
L'objectif, comme on est petit, c'est d'éliminer ça. Mon boulot avant, tant que manager en équipe de développement, c'était d'isoler l'équipe des parasites. Ça me prenait 50% de mon temps. Et je ne produisais aucune valeur. J'ai aussi enlevé tout ce qui est meeting d'architecture.
Dans les sociétés, vous avez des gens dans des tours d'ivoire qui décident de l'architecture pour tout le monde. Là, c'est l'équipe qui choisit son architecture.
Et c'est une tendance de fond.
Par exemple, des groupes comme Criteo, leur meeting d'architecture, c'est une mailing list où ils lancent des choses. Nous, c'est un channel Slack où les gens changent des choses. On teste, ça marche, ça ne marche pas. C'est vraiment une approche darwiniste.
Il n'y a pas de QA en tant que tel. Là, on va intégrer des testeurs, mais pour accélérer, accompagner les équipes à mieux tester. Pour faire une partie du plan de test, mais surtout pas pour bloquer la mise en production. Pour ne pas ralentir. C'est un challenge difficile, mais on prend souvent les sociétés, il y a un quart de testeurs pour trois quarts de développeurs et ça ne passe pas, il y a un goulot. Chez Apple, c'est quasiment l'inverse.
Dans la partie produit, j'enlève les chefs de projet. Les équipes sont autonomes. On a des chefs de projet pour gérer les POC avec les clients, pour gérer la relation, pour faire un peu d'estimation, etc.
Mais là, le métier est même en train de changer. On va plus vers du product management, de l'accompagnement sur le besoin et tout ça.
Et enfin, le premier qui me fait une estimation ou un gant sur un produit interne, c'est l'aide de licenciement.
Pour moi, ça n'a aucune valeur. On ne livrera pas le produit plus vite.
Et on peut le faire parce qu'on est petit, parce qu'il n'y a pas beaucoup de politique et tout ça.
Quand on travaille avec les écoles, c'est un peu plus compliqué parce que c'est ce qu'on leur apprend. On fait des projets avec les écoles, avec des étudiants pour tester des choses. Et là, on travaille avec l'université. Et là, j'attends qu'ils me finissent les spécifications parce que c'est ce que les profs leur demandent. Moi, j'aimerais juste avoir une démo pour voir si ça marche ou ça ne marche pas.
Enfin, j'aime bien bouger l'équipe en disant arrêtez de trop réfléchir, exécutez ce que vous savez faire. Les footballeurs, ils s'entraînent 80% du temps pour 10% de match. Pour faire les petites aides de pigeons, ils s'entraînent énormément. En développement, c'est la proportion inverse.
Moi, je veux que les tests unitaires, ce soit de l'automatisme, quasiment, qu'on sache comment les faire. Plutôt que de poser des questions sur comment j'ai architecturé tel machin que tel machin. Comme ça, le temps qui est dédié pour faire le temps de cerveau est dédié sur les trucs à valeur ajoutée. C'est-à-dire qu'il faut entraîner ses équipes pour aller plus vite derrière.
Et bien sûr, on a plein de cambans de partout. Ça va sur nos produits, sur l'époque, sur le support, le déploiement, que ce soit les tâches de déploiement ou les projets d'amélioration continue sur l'infrastructure.
On a environ 20 bords en interne, ça comprend les POC clients. En fait, ils les suivent, on surgira, ils suivent tout.
Et donc sur le produit, on a...
Non, c'est bon.
Toc, toc, toc.
Alors, ce n'est pas le bon, mais je vais quand même l'illustrer à l'oral.
Donc l'objectif, c'est que le premier, c'est les opportunités. J'ai fait un mauvais copier-coller ce matin. On met des stories, qui sont des idées, comme ça. Ensuite, il y a un parking, où ça, on le fera plus tard, parce que c'est bloquant juridiquement, parce que c'est trop cher, etc. Ensuite, il y a la partie« j'écris la story». Et après, elle est prête pour une release. Et ensuite, je la mets à disposition dans une colonne priorisée pour l'ensemble des équipes.
où là l'objectif c'est de, vous voyez là, là 1 c'est 9, 4, 1, 1, 2, 1. Là je parle sur des mini-releases avec le minimum de choses disponibles. Avant on en avait 15, 20, donc on mettait 1, vous avez vu 2 mois, 3 mois pour le faire. Là l'objectif c'est de diminuer au minimum.
Et ensuite, ça arrive dans la tout doux pour eux. Ils affichent que les releases qui les intéressent. Et ensuite, c'est une partie assez classique. Je fais, c'est bloqué. La partie validation, où là, moi et ensuite les product managers valideront le fonctionnement global de la story, si ça correspond.
Et ensuite, il y a une code review. Après, ça va en test. Après, ça part en release. Et après, NRT, c'est non-regression testing. C'est pour tout ce qui est test de non-régression sur, pas les nouveautés, mais sur ce qu'il y a avant.
Et enfin, c'est livré au client et là, c'est prêt dans un wagon de livraison pour être déployé sur nos environnements, sur les appléances des clients.
Pour l'époque des clients, on a en gros quelque chose d'un peu plus simple. Là, vous revoyez les opportunités et tout ça. Je peux afficher client parce que c'est un de nos investisseurs, donc je n'ai plus de problème dessus. Et là, on va avoir refusé, in progress, in review, done. Donc quelque chose d'un peu plus simple. En gros, c'est un Scrum-like en termes de colonne.
Et en déploiement, on a quelque chose d'encore plus simple, où là, c'est en gros, je crée une nouvelle plateforme, je rajoute des users, j'ajoute telle option, j'ajoute la sécurité sur telle plateforme.
Et là, c'est plus vraiment de l'exploitation de l'infrastructure. Donc, il va y avoir quelque chose de très simple pour le moment. Et par exemple, pour la partie infrastructure, moi c'est un métier que je connais moins bien. Donc ce que j'ai demandé à l'administratif, c'est quand tu fais une tâche, tu me fais un gira, comme ça je vois ce que c'est une tâche pour toi. Et de toute façon, tu remplis ça, ça me sert juste à savoir. Puis après, une fois qu'on est rodé, on va pas mal d'organiser ça. Parce que c'est quelque chose qui est moins dans la culture de l'administration, de l'administratif et tout ça. Et pourtant, comment être très adapté?
Et enfin, j'ai un board CTO où je peux voir tout ce qui se passe partout.
Avec un filtre sur partout qui me permet d'identifier ce qui est bloqué, ce qui est en cours, de voir s'il y a trop de choses en cours ou pas.
Et notamment là, j'ai un problème ici.
Enfin, je ne vous ai jamais parlé de bord physique. Il nous en reste un. Et il est voué à disparaître.
Parce qu'en fait, on a...
Jira, ça automatise tout. On a pas mal de choses dedans. On va...
Moi, souvent, il y a des gens qui sont en distance, en déplacement, et l'utilité est de moins en moins grande, de suivre les tâches. En gros, on va enlever les post-it qui sont le cargo culte de l'agilité. Le cargo culte, c'est on mime en pensant que ça fait la même chose. On ne va quasiment plus avoir de post-it. Par contre, je pense qu'on va rajouter plus des radiateurs d'informations.
Sur le lead time, le temps pour livrer, sur la qualité, etc. Et donc là, il y a un vidéoprojecteur qui va arriver pour remplacer le dernier board physique.
Par contre, j'ai une grosse facture Jira.
Comme beaucoup de startups, c'est un peu mon infrastructure centrale.
Et surtout, en France, dans le monde, c'est dur de recruter des développeurs, des talents, des bons développeurs. Donc on va commencer sur une première équipe à aller à recruter à distance. GitHub est organisé comme ça, 37signals maintenant, Basecamp est organisé comme ça, donc c'est un modèle qu'on va tester sur une équipe. C'est difficile à changer comme culture. Ce qui veut dire qu'il faut qu'on soit plus formel dans ce qu'on partage et tout ça. Quand on est à distance, il faut communiquer plus. Mais on va faire ça sur une équipe de seniors au début, sur des équipes, pour améliorer ça. Et quand on a du distance, ça veut dire que les boards physiques forcément disparaissent parce qu'ils sont moins à jour.
Et surtout sur le support, ça nous permet de nous étendre partout. Revenons au Mongol.
Là, vous avez l'algorithme de scalabilité de l'armée mongole. En gros, vous avez des escouades de 10.
Ces 10 escouades se réunissent pour élire leur chef, qui est le Zoun, qui eux-mêmes sont groupés par 10 pour les ordres, qui vont être avec le Mingam, et pour après ensuite aller sur le Tumène. Donc là, on est à 10, 100, 1000, 10 000, et au-dessus, vous avez le Khan.
Donc l'empereur, le roi et tout ça. Et donc là, vous avez une chaîne de commande très rapide pour pouvoir dire, donner une information et donner un ordre. Et après, vous avez des escouades qui, eux, par contre, ont une mission et ont le pouvoir de s'adapter au terrain par rapport à cette mission-là.
Donc Spotify n'a rien inventé, en gros.
Ça l'a été dit il y a un moment. Et donc comment on fait nous pour avoir cette scalabilité? L'objectif, comme je l'ai dit, c'est d'avoir des équipes autonomes, dans leur techno, dans leur process Kanban et tout ça, mais aussi dans le recrutement. Moi, en recrutement, je fais rabatteur et à la fin, je fais la négociation. Au milieu, c'est l'équipe qui choisit ses... Prochain collaborateur ou l'inverse.
Et en gros, ça permet d'avoir une autonomie, de rendre les gens responsables. Ce qu'on va changer, c'est qu'au lieu de faire des équipes de juniors et de seniors, on va essayer de les mélanger, comme ça il y aura de l'apprentissage plus automatique et il y aura moins de problèmes d'autonomie.
À ça, je rajoute une couche de management. Donc là, je vais parler des outils du manager, Manager Tools, qui provient d'un ancien militaire américain. Où c'est des techniques assez simples qui permettent d'avoir de la communication récurrente toute l'année avec ses collaborateurs.
Avec des 1 à 1, c'est-à-dire qu'on voit quelqu'un tous les 15 jours, toutes les 3 semaines, toutes les semaines, ça dépend, où le premier quart d'heure, c'est dédié aux collaborateurs. Et vous êtes en position d'écoute. Et en position de relance pour ouvrir des sujets et tout ça. Ensuite, vous pouvez faire des feedbacks. Un feedback, c'est quand tu as tel comportement,
alors c'est bien parce que l'équipe fonctionne mieux et c'est valorisant pour tout le monde. Par contre, quand tu as tel comportement, il y a telle personne qui est vexée, elle fait la tête pendant deux jours et vous ne travaillez pas. Et vous ne vous entendez pas. Donc c'est vraiment du comportemental. Et enfin, il y a la partie coaching pour évoluer vers de nouveaux postes, pour évoluer vers de nouvelles compétences et tout ça, pour le long terme. Et quand vous faites ça, l'entretien annuel devient quasiment une formalité, parce que normalement tous les problèmes vous les avez sortis avant, si vous avez bien fait votre travail.
Parce que d'habitude, les ententes annuelles, c'est un peu cocotte minute.
Et enfin, vous avez deux techniques, comme le DISC. Je vous ai mis un lien d'un site qui le fait. DISC, c'est-à-dire dominant, influent, stable, consciencieux. C'est des modes de communication de personnes.
Par exemple, Moi, je suis plus dominant, ma direction financière est plus stable. Donc des fois, on se frite un peu. Et c'est la vie. Et donc on essaye de s'adapter. Et en général, les CEOs, les commerciaux, on va être plus des I, des influents, vont se reposer sur le réseau.
Et l'objectif, c'est d'avoir du management scalable. C'est-à-dire que je différencie la partie
gestion d'une roadmap, gestion d'un projet, tout ça, de la gestion humaine.
La personne qui est responsable de l'exécution de la roadmap, il ne veut pas faire de management de chez moi. Par contre, il y a une personne qui aime bien ça.
Et qui, là, il est à 4 personnes et qui va augmenter au fermement jusqu'à 7-8. Et après, on va former un nouveau Padawan qui lui va faire 1, 2, apprendre, faire des erreurs, apprendre, et monter jusqu'à 7, 8, et ainsi de suite. On va faire des cercles de management. L'objectif, c'est que s'il y a un problème, ça puisse être remonté dans le mois, quasiment, pour qu'on puisse le résoudre.
Parce que quand on est manager, l'objectif, ce n'est pas de savoir le problème après, c'est de le savoir le plus tôt.
On a aussi un outil interne qui permet d'avoir l'ambiance de l'équipe.
Je pense qu'il y a de bonnes corrélations avec le lundi, le vendredi et la météo pour le moment. Ou les mises en prod.
Et du coup, là, le rôle au niveau de la direction, il y a la partie vente, il y a la partie finance. Et moi, le rôle sur la partie CTO, c'est de vérifier que les roadmaps qui sont délégués sur l'ensemble des équipes sont bien alignés.
Mais avant de faire ça, on va rester humble, on va juste tâcher de l'essayer de livrer plusieurs fois par mois. Pour livrer de la valeur encore plus vite. C'est pour ça que ce que vous avez vu, il y avait 1, 2, 1, 2 stories par release. Alors qu'avant où j'étais avant, c'était plus 40, 50, et là j'avais mes 10, 15, et encore c'est trop gros. On livre de la valeur au fur et à mesure.
Il y a des sociétés comme Criteo, les Furet, c'est 1600 par mois.
Bon, ce n'est pas les mêmes équipes.
Et nous, l'objectif, c'est qu'on est encore une petite équipe, mais si on livre quelque chose plusieurs fois par mois, on pourra livrer de la valeur plus rapidement et surtout pas avoir du support de vieilles versions et tout ça. Et donc, si moins de support, plus de feature, et d'engager le cercle vertueux, on a failli le faire en mois d'octobre, on est tombé sur un gros os, et une fois qu'on a corrigé cet os, ça devrait être bon. Parce qu'en fait, il y a la 1 qui doit sortir, il y a 3 développeurs par-dessus qui essayent de résoudre le problème. Pendant ce temps-là, ça ne sert à rien d'être 4 ou 5. Donc il y a une personne qui a commencé la 1.2, et la 1.2 est presque finie en fait. Parce que du coup, elle est sur de bonnes bases. Mais la 1, c'est juste qu'il faut qu'on la sorte parce que c'est le moteur interne. C'est le truc pas sexy que personne ne voit et qui doit fonctionner très bien. Ça ne fonctionne pas, ça ne sert à rien de faire le reste. Et si on arrive juste à faire ça, on sera content et peut-être que Judge Inskan sera fier de nous. Merci de votre attention.