D’AppGratis à Batch : le périple d’un pivot

0:04 Bonjour, c'est Nicolas Douillet d'Off Engineering de Batch. Vous me suivez? On va rejoindre Antoine Guénard. Le voilà, il est justement en train de se préparer. Vous savez qu'un des arguments forts du Tech.Rocks Summit, c'est zéro bullshit. Et ce n'est pas toujours évident pour certains entrepreneurs de venir aussi faire part de virages pas simples à amorcer. Et c'est pour ça que je suis très heureuse d'accueillir avec moi Antoine Guénard, qui est cofondateur, CTO et CPO de Batch, qui est un outil de CRM pour mobile, et Nicolas Douillet, qui est dans son équipe avec lui, Head of Engineering, et qui vont nous expliquer dès maintenant comment on rebondit après avoir vu son business s'arrêter du jour au lendemain. Merci à tous les deux, je crois que tout cela va être très très riche d'enseignements. Je vous laisse. Bonjour à tous, on est vraiment très heureux d'être là aujourd'hui avec Nicolas. Je vais en profiter pour remercier d'abord l'organisation Tech.Rocks et notamment Jérémy de nous avoir invité à parler aujourd'hui.

1:10 L'histoire qu'on va vous raconter aujourd'hui, c'est une histoire de résilience. C'est celle de la chute d'Abgratis, notre précédent business, et la construction de Batch. C'est une histoire que vous connaissez peut-être déjà, on l'a racontée peut-être mille fois, mais pour la première fois aujourd'hui, on va la raconter sous un angle technique. Ou comment on a réussi à faire ce virage à 180 degrés en faisant les choses un peu à notre manière. Mais avant de commencer ça, on va d'abord se présenter. Moi, je m'appelle Antoine Guénard, je suis l'un des cofondateurs de Batch, je suis aussi CTO et CPO. J'ai 15 ans d'expérience dans la tech et je dirige du coup une équipe produit basée à Paris et une équipe tech basée à Lyon avec Nicolas qui va se présenter. Moi, c'est Nicolas Douillet. Je suis Head of Engineering chez Batch. J'ai à peu près 20 ans d'expérience. J'ai commencé dans le web. Ensuite, j'ai été à mon compte. Puis, j'ai rejoint les rangs de Abgratis il y a 9 ans. J'étais un des premiers embauchés. Je suis devenu lead backend. Et enfin, maintenant, aujourd'hui, je suis manager des 15 personnes de la tech qui se situent à Lyon. Aujourd'hui, forcément, on va raconter cette histoire qui, depuis ces six dernières années, est difficile d'en parler sans parler de la mort d'Abgratis, mais qui finalement nous a donné cet élan pour créer Batch.

2:21 Et enfin, on va essayer de tirer quelques leçons techniques de toute cette histoire. Tu nous racontes un petit peu Abgratis, Antoine ? Merci Nico. Abgratis, c'est un média qui a été créé en 2009 par mon associé Simon Davla. Alors je dis un média, en fait c'était un blog qui tournait sur WordPress. Le concept était assez simple, c'était la découverte d'applications iOS. En gros, tous les jours, on avait une équipe qui sélectionnait une app qu'on trouvait sympa, on rédigeait un petit texte et on envoyait une notification push à tous nos lecteurs ou en email. Ces lecteurs, il y en avait environ 15 millions dans une trentaine de pays, 12 langues, dont 3 millions d'entre eux ouvraient l'app tous les jours. Donc la croissance était vraiment phénoménale. Et l'apogée de cette activité, ça a été en 2013. On a levé des fonds, on a lancé le produit aux US et on visait quasiment 40 millions d'euros de revenus pour l'année. Et puis en avril 2013, une nuit, Apple a déréférencé l'application de l'App Store. Raison officielle, une guideline qui interdisait les notifications de push marketing. Raison officieuse, l'impact qu'Abgratis avait sur les classements des stores.

3:25 Alors ça a vraiment été la douche froide absolue pour nos équipes, tout le monde était KO. Mais après quelques mois, on n'avait pas trop le choix. Soit on laissait la boîte mourir, soit on pivotait, comme on dit dans le jargon. Et c'est ce qu'on a essayé de faire pendant l'année 2013, en essayant plusieurs idées. On a essayé de migrer à gratis sur Android, on a essayé de lancer un ad network, on a aussi même fait du game publishing, mais aucune de ces idées n'a vraiment pris ou nous plaisait totalement. Et puis, début 2014, il y a une idée, nom de code Bastion, qui est un peu sortie du lot, et c'est ce qui est de la douche froide absolue pour nos équipes, tout le monde était KO. Mais après quelques mois, on n'avait pas trop le choix. Soit on laissait la boîte mourir, soit on pivotait, comme on dit dans le jargon. Et c'est ce qu'on a essayé de faire pendant l'année 2013, en essayant plusieurs idées. On a essayé de migrer à gratis sur Android, on a essayé de lancer un ad network, on a aussi même fait du game publishing, mais aucune de ces idées n'a vraiment pris ou nous plaisait totalement. Et puis, début 2014, il y a une idée, nom de code Bastion, qui est un peu sortie du lot, et c'est ce qui est de la douche froide absolue pour nos équipes, tout le monde était KO.

4:29 Mais après quelques mois, on n'avait pas trop le choix. Soit on laissait la boîte mourir, soit on pivotait, comme on dit dans le jargon. Et c'est ce qu'on a essayé de faire pendant l'année 2013, en essayant plusieurs idées. On a essayé de migrer à gratis sur Android, on a essayé de lancer un ad network, on a aussi même fait du game publishing, mais aucune de ces idées n'a vraiment pris ou nous plaisait totalement. Et puis, début 2014, il y a une idée, nom de code Bastion, qui est un peu sortie du lot, et c'est ce qui est de la douche froide absolue pour nos équipes, tout le monde était KO. Mais après quelques mois, on n'avait pas trop le choix. devenu batch et c'est ce que Nicolas va vous raconter maintenant. Alors effectivement on a choisi de pivoter, on n'avait quand même pas se laisser abattre et en fait dans AppGratis on avait déjà un moteur de notification push qu'on utilisait pour envoyer à tous nos utilisateurs une annonce chaque jour. Donc l'idée c'était de prendre cet outil qu'on avait développé pour nous et de le transformer en produit. La première version de Batch, comme l'a dit Antoine, qui s'appelait Bastion, avait du coup ces trois composantes, qui étaient la première SDK qu'on installe dans toutes les applications de nos clients. Ensuite, on a un dashboard qui permet de créer des campagnes ou de voir les statistiques. Puis enfin, une API qui permet à nos clients, dans leur propre dashboard, de pouvoir également trigger des campagnes. Tout ça, passer au final d'un outil qui est juste pour nous à un produit qu'on commercialise, forcément, ça amène plein de nouveaux challenges techniques. Le premier, c'est beaucoup plus de trafic en real-time, qu'on doit indexer, qu'on doit stocker, qu'on doit resélectionner pour envoyer des pushs. On avait aussi des gros objectifs de stabilité. On installe un SDK dans plein d'applications qui sont déployées sur... sur plein de téléphones, et il est hors de question qu'on fasse tomber les applications de nos clients. Et puis enfin, aussi de la haute dispo, forcément, je pense par exemple dans les événements médias, je ne sais pas, par exemple les attentats ou les élections, il était hors de question que Batch ne soit pas disponible pour ces gros événements. Et enfin, comme on est passé du B2C au B2B, on s'est mis à être en face de grands groupes, et donc on devait leur apporter des engagements de sécurité, une documentation bien faite, et puis un support carré.

5:31 Alors en fait, sur le papier c'est super, mais derrière c'était tout de même encore un moteur assez light, puisqu'il était tiré de Sudam Gratis, donc la segmentation était plutôt rudimentaire, mais on avait déjà une puissance d'envoi qui était assez importante. D'ailleurs en interne on appelait ce produit le canon à pouche. Et ça a vachement séduit tout de suite nos premiers clients médias. Et ça nous a donné du beau moqueur pour continuer jusqu'à aujourd'hui. Et aujourd'hui, Fast Forward, c'est six ans après. Batch, aujourd'hui, c'est un leader d'un secteur qu'on appelle l'engagement mobile. On est une boîte d'une cinquantaine de personnes, on a 25 postes ouverts. Et il y a 10 000 clients en Europe, principalement, qui utilisent, enfin 10 000, pardon, applications et sites web, qui utilisent notre technologie. Là-dedans, il y a des médias, par exemple, comme Le Monde. Je dis bonjour à Sacha, qui était un des premiers à nous faire confiance. Il y a des e-commerçants comme Oui SNCF, Intermarché, des banques, des startups comme Cityscoot ou Backmarket. Et même le gouvernement. qui a utilisé notre technologie sur ses sites web pendant la crise du Covid.

6:34 Pour tous ces acteurs-là, on envoie 20 milliards de notifications tous les mois et on gère 300 millions de devices. Nico parlait d'une techno rudimentaire, elle a évidemment beaucoup évolué. Aujourd'hui, c'est une plateforme complète de marketing automation avec de la segmentation, de la personnalisation en temps réel et de nouveaux canaux comme par exemple des push notifications web ou des messages in-app. Pendant ce parcours, on a vraiment appris beaucoup de choses et c'est ce qu'on a voulu vous partager un peu maintenant. Vous raconter comment est-ce qu'on est parvenu à opérer ce pivot qui finalement a été un succès et quelles leçons techniques nous on a attiré et peut-être que ces leçons techniques vont être intéressantes pour vous aussi. Je vais laisser la parole à Nicolas. Avant de rentrer dans le vif du sujet, on va faire un petit panorama de nos technos. Il y en a quand même pas mal. On utilise Cassandra, Kafka pour de la data, des langages différents, du Go, du Java, du Python pour le web service, des frameworks sur du front, puis aussi des outils de containerisation. Donc tout ça, ça fait quand même pas mal de technos. En fait, la plupart ont été introduites en réalité à l'époque d'AppGratis, parce que l'effet cool startup et puis le business le permettait.

7:35 Ça nous permettait d'expérimenter, de jouer un peu avec ces technos et on a fait rentrer pas mal. Alors au final, en faire rentrer, c'était bien, mais il y a quand même des moments où quand on fait rentrer une techno un petit peu trop tôt, par exemple je pense à Docker, qu'on a fait rentrer de manière très tôt, du coup on a quand même des ratés, on avait des manques de stabilité. Je me rappelle d'ailleurs cette anecdote de Vincent, notre lead backend, qui une nuit de rage décide de sortir toutes les apps de Docker, de les faire tourner à côté, tellement il en avait marre. de l'instabilité. Il y a aussi des technos qu'on a mis vachement de temps à intéresser, comme Cassandra, où du coup ça a été cinq années d'apprentissage. Aujourd'hui, on pourrait presque dire qu'on est des experts, même s'il nous reste encore beaucoup à apprendre, mais c'est des nuits de prod tombées, à chercher pourquoi des serveurs ne répondent pas, essayer de comprendre ce qui se passait. Donc c'était vachement de difficultés. Donc au final, le constat est quand même plutôt simple, on ne devient pas expert du jour au lendemain en mettant une techno dans sa stack, en cliquant des doigts. Il faut du temps, il faut de l'expertise, il faut se casser les dents dessus, il faut apprendre à connaître ses faiblesses, à savoir comment les devs doivent interagir avec, comment un SRE doit la maintenir, etc.

8:44 Donc ça demande quand même pas mal de temps. Alors ça ne nous a pas refroidi pour autant, parce qu'on utilise quand même encore Kubernetes qu'on a mis il y a trois ans, par exemple, ou Redis Cluster qu'on est en train d'incorporer. Mais on le fait quand même avec beaucoup plus de pragmatisme. Et du coup, on se pose quand même des questions. Est-ce qu'en interne, on connaît suffisamment ce qu'il y a autour de ces technos et on saura comment elle va réagir, si possible, avant la prod? Ou est-ce qu'il faut qu'on aille chercher, et on en est là aujourd'hui, cette capacité, cette connaissance ailleurs, par exemple en embauchant? Ce que disait Nico, c'est que ces plâtres qu'on a essuyés avec toutes ces technologies-là, ça nous a quand même appris, il l'a dit, à être assez pragmatique. Pragmatique, ça veut dire qu'on va avoir besoin de changer souvent. On n'était pas en train de créer une technologie. avec une version majeure par an qu'on fournissait aux clients, qu'ils installaient sur leur propre serveur. On a la capacité de la faire évoluer en permanence pour deux raisons. La première, c'est qu'on allait se planter beaucoup. Et puis aussi que la croissance allait amener des problématiques de charge qui allaient évoluer en permanence et qui remettraient en question nos choix techniques. Une fois qu'on est parti de ce postulat, comment est-ce qu'on crée une plateforme qui est capable d'être extrêmement évolutive, Et ça, on l'a fait en séparant la logique en toutes circonstances.

9:51 Alors ça paraît assez simple de le dire. Chez nous, ça a été effectivement de mettre en place des microservices. Les microservices, aujourd'hui, pour nous, ça représente environ 200 applications. 2500 instances qui tournent, et tout ça sur une colonne vertébrale qui, chez nous, s'appelle Kafka. Et ça, ça a permis effectivement de séparer vraiment les applicatifs par logique métier. Une deuxième chose qu'on fait massivement, c'est une base de données ou une table de données pour un usage. Si par exemple on a des fonctionnalités analytiques, c'est d'autres fonctionnalités de segmentation, de lecture et de ciblage. Même si la donnée est strictement la même, on va la répliquer pour s'assurer que si par exemple on a des retards d'indexation à un endroit, ça n'impacte pas le reste de la chaîne et ça nous permet d'être extrêmement souple. Et puis un dernier exemple, en front-end par exemple, plutôt que de faire une single page app, on a choisi de faire une app plutôt hybride. Et ça, ça nous a permis de migrer d'Angular à React il y a quelques années et de ne pas le faire en un grand projet de six mois, mais de le faire effectivement un peu plus efficacement. Globalement, faire tout ça, séparer la logique, c'est aussi une manière de simplifier le code source, de migrer les données plus facilement quand on veut repenser une architecture, et enfin de faire des refactorings un peu plus chirurgicaux, plutôt que de faire ces fameux grands refactorings qui durent deux ans et qui accouchent de rien.

11:00 Chez nous, la plateforme peut évoluer en permanence en refactorant les zones qui sont les plus critiques. Donc ça, évidemment, c'est un coût. Avoir autant d'applications, autant de services, c'est un coût humain, c'est un coût à la maintenance. Et les gens, on l'explique avec un peu de recul, peut-être par notre ADN, et ça, c'est Nicolas qui va vous l'expliquer. Oui, effectivement, ça, c'est une partie que j'aime beaucoup. Je pense que c'est... La fusion entre nous deux, au final, entre ce perfectionnisme... légendaire d'Antoine et l'over-engineering maladif que je porte, c'est qu'on n'a jamais au final hésité à réinventer la roue. Alors je vois des gens déjà se crisper, au final, il faut remettre un peu de contexte à tout ça. La réalité, c'est qu'on est face à des acteurs américains qui sont surfinancés. Et puis nous, à côté, on était une petite boîte qui essayait de se relever et qui essayait de pénétrer un marché. Donc on a souvent... Beaucoup plus fait le choix de fonctionner avec des petits moyens. Donc quand on était en phase de la solution, est-ce qu'il faut acheter une techno ou est-ce qu'il faut la reconstruire? On la reconstruisait.

12:01 Donc tout ça, ça nous a amené énormément de connaissances, un savoir-faire, une grosse montée en compétences. On est quand même relativement pointu dans tout ce qu'on fait. Et aussi un gros avantage, du coup, c'est qu'on a réussi à avoir des coûts de fonctionnement qui étaient très très faibles, une très grosse indépendance. Alors un très bon exemple de ça, c'est qu'on marche sur 300 serveurs bare metal, pas du tout dans le cloud. On n'a pas de service managé, on utilise des solutions open source qu'on manage tout nous-mêmes. Et donc du coup, on n'a aucune dépendance avec rien. Ça nous a permis d'être très compétitifs sur le marché. Aujourd'hui, on prend un peu de recul, on se remet en question là-dessus, on se dit est-ce que vraiment on doit tout réécrire tout le temps et est-ce qu'on doit toujours tout refaire? La réponse est sans doute non. Comment est-ce qu'on arrive à se recentrer? Comment est-ce qu'on arrive à garder cet ADN qu'on n'a pas du tout envie de perdre, peut-être un peu moins d'over-engineering et peut-être laisser un peu plus sur la perfection, pour réussir à se reconcentrer sur notre business, puis aller chercher la complétance encore une fois. ailleurs dans d'autres services.

13:02 Ça me fait penser par exemple à GitLab qu'on hoste encore nous-mêmes, qui est un système de source, et au final on pourrait largement s'en passer. Alors là, c'est des remises en question qu'on a fait sur notre manière de faire, mais en réalité, on en a fait également sur la gestion de projet. La gestion de projet, ça a toujours été un truc assez particulier chez Batch. Pour ainsi dire, on n'en avait pas vraiment, même sur AppGratis. Mais quand il a été question de construire Batch, le constat, c'est que, comme le dit Nicolas, on arrivait sur un marché hyper mature. On n'a pas créé ce marché-là, le marché de l'engagement mobile. Du coup, on avait besoin de se différencier. Un marché où il y a déjà des appels d'offres, déjà des prérequis très importants. Ça met la barre assez haut et ça ne tolère pas l'idée qu'on puisse arriver sur ce marché-là en nouveaux entrants avec un MVP. Du coup, on s'est fixé une target qui était de fournir le meilleur produit, en tout cas un produit qui nous satisfaisait. Donc ça impliquait pas de planning, pas de deadline, et juste de sortir quand le produit nous semblait satisfaisant. Donc on a pris plusieurs années pour faire ça, avec des specs qui étaient relativement évolutives. Alors ça va complètement à l'encontre de toutes les méthodologies d'agilité, de product management qu'on peut entendre. Mais aujourd'hui, c'est peut-être ce qui nous a permis de nous différencier, peut-être ce qui nous a permis de pivoter avec moins de moyens.

14:07 La réalité, c'est que peut-être qu'aujourd'hui, les choses changent. Maintenant qu'on a une plateforme plus mature, il y a deux ans, on a fait un constat, c'est qu'on avait peut-être un peu plus de projets en dérive. J'ai le souvenir d'un projet de refonte d'un brique de login qui a mis deux ans et qui était complètement à l'arrêt. Et puis, peut-être des frustrations aussi des développeurs qui eux-mêmes étaient dans le temps de validation qui ne venait plus. Donc, même si la plateforme était quand même vachement maintenue, on était complètement en panne d'innovation. On n'arrivait plus à sortir de nouveautés. Ça, je dirais que c'était peut-être en début 2019. Et du coup, on s'est posé la question, comment est-ce qu'on peut finalement structurer de la conduite de projet en douceur? Pourquoi? Parce que dans une équipe qui n'en a jamais fait, ou pour qui la gestion de projet est presque un gros mot, il faut effectivement, en disant que le changement est un volant de plomb, comment est-ce qu'on amène ça progressivement? Ce qu'on a fait, c'est qu'on a d'abord embauché un chef de projet, quelqu'un de très différent de nous, puisqu'on a pris un chef de projet qui venait de SN, de chez Atos Worldline, pour les citer. Et on lui a interdit deux choses, je crois. La première, c'est de ne pas parler d'agilité et de Scrum au bureau, pour ne pas se faire lyncher. La deuxième, ça a été de choisir un outil de gestion de projet qui devait être tout sauf Jira.

15:10 Donc il a choisi Clubhouse, on est plutôt satisfait quelques années après. Et puis surtout, ça a été d'amener cette méthodologie agile progressivement, d'ailleurs presque sans qu'on s'en rende compte nous-mêmes, donc de créer du process, du process, du process, d'abord dans la gestion du backlog, dans la gestion des tâches, des objectifs, des milestones, etc. Donc ça, ça a vraiment été un pivot majeur pour la boîte, qui nous a permis effectivement de retrouver un peu une capacité à planifier la roadmap et finalement d'enlever cette frustration que les développeurs avaient. Mais voilà, la gestion de projet, c'est une chose, une organisation, c'est d'abord des personnes. Et c'est ça dont on va vous parler maintenant. Comment est-ce qu'on a revu un peu cette organisation? Et quelles personnes? On a une magnifique équipe technique qui se trouve à Lyon, avec des gens qui nous suivent depuis un bon moment. On a nos leaders qui sont Cédric, Stéphane, les deux Arnaud, Vincent, qui sont là et qui nous accompagnent depuis le changement même de Abgratis à Batch. Historiquement, cette équipe est composée de cinq pôles d'expertise. On n'a pas fait des pôles comme généralement il se passe des pôles de projet, c'est des pôles d'expertise comme du front-end, du back-end.

16:14 Et chacune avait du coup des process différents qu'ils ont créés de leur côté. Alors on a rapidement, une fois qu'on a un peu levé la tête, on a rapidement vu qu'au final, avoir des process différents, ça allait nous amener des difficultés. Les premières, c'est quand on on-board des nouvelles personnes, peut-être qu'elles ne comprennent pas trop l'envie. environnement dans lequel elle se trouve et c'est difficile de se mettre à coopérer avec ses collaborateurs. Ou alors la gestion d'incidents, quand on se retrouve à 5 heures du mat et qu'on ne sait pas comment cette app est déployée, où se trouve le code source ou comment il est fait, c'est très difficile, on se sent un peu seul de pouvoir remettre en place cette application. Donc la première chose en réalité qu'on s'est rendu compte, c'est qu'on avait d'abord besoin nous deux de... De changer, parce qu'on avait une organisation horizontale, et comme on en a parlé tout à l'heure, en réalité, ça cachait un goulot d'étranglement où seulement quelques personnes prenaient des décisions, surtout Antoine en réalité. Et du coup, on avait besoin de changer tout ça. Donc déjà de nous de changer, on s'est fait coacher, ensuite de transmettre le changement. Une fois qu'on avait réussi à transmettre ce changement, à créer une organisation qui puisse permettre de nous rendre remplaçables et que la structure elle-même puisse réussir à prendre des solutions.

17:20 Enfin, on s'est attaqué à notre mode artisanal pour se professionnaliser. Et donc, du coup, on a rationalisé tous nos process. On a essayé de prendre les meilleurs et de se dire, voilà, celui-là, là, on déploie. Ici, on rajoute des métriques, etc. On a essayé de réduire le stress également sur les équipes qui portaient la charge de l'infra sur leurs épaules, qui, du coup, commençaient à vraiment n'en plus pouvoir. Donc, on a mis des tours de garde, par exemple, d'astreinte. Et puis, effectivement, on a transmis comment prendre ses responsabilités et comment devenir plus autonome. Au final, ce qu'on a appris avec tout ça, c'est qu'une équipe, ça bouge aussi constamment, ça a besoin d'écoute, et pour ça, il faut des managers. Du coup, on a dû apprendre à être manager. C'est quelque chose qui n'est pas facile. Il faut vraiment abandonner. On ne peut pas être manager et faire autre chose. Donc, on est obligé d'abandonner son code. Alors, est-ce qu'on a réussi? Est-ce que j'ai réussi? Donc, ça, c'est le code que je fournissais en 2018. Et ça, c'est celui en 2020. Je pense qu'on est en bonne voie. En conclusion, on a essayé de nous enterrer et on ne s'est pas laissé faire, donc on a ressuscité.

18:26 Et ce virage très difficile, nous on pense qu'il a été possible parce que justement il y a eu un investissement vraiment très important de notre équipe, un très important et vraiment total, et peut-être que l'absence de méthodologie à cette époque-là nous a permis d'aller vite à un moment où finalement les ressources étaient limitées, et il fallait coûte que coûte sortir un nouveau produit qui nous permette de retrouver le chemin de la croissance. Et cette phase de résilience, vraiment, elle conduit aujourd'hui, je trouve, tout ce qui se passe dans la boîte, et notamment la nouvelle séquence qu'on est en train d'entamer, c'est que six ans après, on a réalisé finalement qu'on devait peut-être encore changer une nouvelle fois. Alors on se dit, mais encore, on pensait qu'on avait fait le boulot, mais finalement c'est assez normal dans une organisation qui évolue, qui est en croissance, et peut-être que cette résilience, à l'époque, nous a permis d'attaquer peut-être cette nouvelle phase avec sérénité. Puisque l'idée de fond c'est effectivement comment est-ce qu'on arrive à structurer cette équipe sans détériorer la culture qu'elle avait, la productivité qu'elle avait et je pense qu'on y est arrivé en y allant progressivement, en onboarding tout le monde dans le projet et puis c'est vrai que si tout le monde est conscient finalement des problèmes c'est beaucoup plus simple

19:27 et ça a été le cas et voilà, aujourd'hui je pense qu'on est assez serein face au nouveau challenge qu'on attaquera. Voilà. Merci beaucoup. Merci. Non, ne dites pas merci tout de suite, j'arrive, j'arrive. Moi, je suis hyper impressionnée. Honnêtement, sacrée force de caractère que de vous voir tous les deux raconter ces expériences-là. Mais j'ai une petite frustration. Ah. Oui, une petite. Je vais la partager avec vous. Là, vous nous avez éclairé sur la partie méthodologique, pragmatique, etc. Mais psychologiquement, comment on se remet aussi de ce qui vous est arrivé, Nicolas? Antoine, oui. Tu n'as pas subi un choc psychologique? Non, ça a été dur. C'est vrai que ça a été dur. Il faut imaginer ce qui se passe. Vous avez un budget, une boîte, il y avait 80 personnes chez Abgratis, des gens qui font des métiers variés, toute une équipe éditoriale qui est presque l'équivalent d'une rédaction chez un média. Vous voyez vos collègues qui s'en vont, la boîte qui d'un coup n'a quasiment plus de cash qui rentre. Et vous savez que vous avez potentiellement 4-5 ans devant vous. Et les premiers mois, vous ne les passez pas à penser au pivot, vous les passez effectivement à reconstruire la boîte, à essayer de stabiliser tout ça, et puis à vous reconstruire vous personnellement.

20:30 C'est ça, est-ce qu'on pense un peu à soi aussi? On met du temps à y penser, ou alors c'est par séquence. Alors heureusement, on a une équipe forte, on l'a dit, donc je pense que chacun a vécu sa phase de dépression de manière un peu décalée, donc on a réussi à tous se soutenir. Mais je dirais que dans le flot, dans les vagues du pivot vers BATCH, finalement, je pense qu'on a un peu tous oublié le trauma et qu'on a réussi à rebondir tous ensemble. Mais c'est vrai que oui, c'est des moments qui sont vraiment très durs pour les équipes historiques. Donc vous êtes encore plus fier aujourd'hui de pouvoir dire, ça y est, la phase de résilience, on l'a véritablement passée. Méfiant, mais très fier. Prudent, on va dire, plus que méfiant. C'est vrai que ça donne une vraie force. Je pense que Nicolas est d'accord avec toi. Non, non, en fait, juste après, de toute manière, on est tellement surpris, on est tellement dedans, on est tellement à essayer de refaire quelque chose qu'au final, on n'y pense pas, on ne prend pas de recul. C'est un peu comme ce qui peut nous arriver dans la vie, c'est difficile de prendre de recul et de se rendre compte de ce qui s'est passé. Aujourd'hui, avec du recul, on se dit, ah ouais, quand même. Abgratis, c'était une expérience forte, mais au final, celle-là l'est encore plus. Il fallait peut-être en passer par là, justement, pour arriver à Abgratis. Peut-être, qui sait? Il y a quand même aussi autre chose qui m'intrigue.

21:30 Dans votre parcours, en France, on a quand même coutume de dire que les échecs, on les met un peu sous le tapis. Ce que vous faites là avec nous, c'est formidable, parce que je pense que ça va aussi donner envie à d'autres de libérer leur parole. En plus, c'est très tendance de libérer sa parole aussi sur les échecs. Comment on peut contribuer justement à faire voler en éclats cette croyance en France, justement en écoutant de plus en plus de témoignages comme le vôtre? Ou il y a d'autres choses aussi à mettre en place? On avait dit parfois c'est un peu philo un tech rock. On a combien de temps? On a 12 heures. On peut se concerter. Non, non, mais je ne crois pas qu'il y ait vraiment... On le dit souvent, effectivement, mais je pense quand même que les mentalités changent vachement. Il y a de plus en plus de gens qui reviennent sur des histoires de plantage. Nous, le nôtre, il est assez particulier parce qu'il y a beaucoup de pivots de boîtes qui sont un peu pour des causes endogènes, des boîtes qui n'ont pas réussi à trouver un product market fit, qui n'ont pas réussi à trouver un business, et qui, avec l'argent qui reste, souvent recréent quelque chose. Ce qui est assez particulier, c'est qu'effectivement, c'est une boîte qui était en hypercroissance. Aujourd'hui, on aurait dit qu'après, c'était une scale-up, peut-être.

22:31 Mais là, il y avait vraiment une cause exogène qui était le fait qu'Apple, effectivement, il y a un droit de mort sur notre business à l'époque, fermeture du robinet. Et peut-être que c'est plus simple de raconter une histoire, parce que le plantage a une cause externe. On a l'impression d'être moins responsable. Évidemment qu'avec du recul, on pourrait expliquer qu'on a nos responsabilités, qu'on aurait pu le voir. Tout le monde a un avis assez tranché sur la question. La réalité, c'est qu'effectivement, quand on est dans ces activités-là, il y a souvent tout un tas de causes externes ou d'acteurs externes qui peuvent avoir un impact sur notre business. Mais du coup, oui, je pense que c'est... C'est peut-être plus simple pour nous de raconter cet échec, un, parce qu'on a réussi à s'en retourner, et deux, parce qu'effectivement, on n'a pas l'impression peut-être d'en être responsable. Peut-être que ça aide. Effectivement. Merci beaucoup Antoine et merci beaucoup Nicolas. Je rappelle que Nicolas et Antoine sont disponibles immédiatement pour une session de questions-réponses et je suis sûre que vous avez beaucoup de questions à leur poser. A bientôt. Merci beaucoup. A bientôt.