Comment gérer la dette technique quand on est organisé en squads ?

0:02 La dette technique, je ne sais pas ce que vous en pensez, mais bon, c'est un petit peu comme la vieille tante au repas de Noël. C'est vrai que c'est pénible, mais il faut faire avec. Cela dit, parfois, ça peut bien se passer et c'est exactement ce que Marine Safar, CTO de CAFEYN, va pouvoir nous expliquer dans sa conférence« Comment gérer la dette technique en mode squad». Marine Safar, je suis ravie de vous accueillir pour ce Tech.Rocks Summit. Vous avez évidemment plein de choses à nous raconter sur cette histoire de dette technique. Alors, j'ai fait cette comparaison hasardeuse avec la vieille tante à Noël. Comme on est dans cette ambiance un peu Christmas, je me suis permise de vous inviter à la maison. Et puis comme ça, je vois un petit peu votre chez vous aussi, ce qui est plutôt sympathique. Évidemment, tout ça, c'est lié au Covid. On le sait bien, puisqu'on doit pratiquer certaines de nos interviews comme ça en distanciel. Mais ça ne gâche rien au plaisir qu'on a de se retrouver, surtout de vous écouter. Alors Marine, je vous laisse la parole, je vous laisse vous présenter. Et puis nous expliquer un peu qu'est-ce qu'on peut faire avec cette dette technique. Et peut-être qu'il y a beaucoup de solutions et vous allez les partager avec nous.

1:06 Tout à fait, en tout cas je vais essayer. Donc je suis Marine Safar, c'est Théo chez Caffeine et je vais vous parler aujourd'hui d'une expérience un peu malheureuse. Donc j'ai remarqué souvent dans les talks qu'on a des retours d'expérience sur des choses positives, moi c'est plutôt sur une chose négative et donc justement pour essayer de... Que tout le monde fasse bien attention à cette histoire de dette technique, notamment... lorsqu'on est organisé en squad. Parce que ce qui s'est passé chez nous... Vous savez qu'on adore ça, on adore ça au Tech.Rocks Summit, un zéro bullshit. Donc, on aime justement des retours d'expérience qui sont basés parfois sur des échecs pour optimiser les choses derrière. Exactement, exactement. C'est ce qu'on va essayer de faire. Donc, juste pour me présenter brièvement, j'ai travaillé dans des boîtes de logiciels un peu classiques avant qu'Internet existe, donc il y a fort, fort longtemps. Et assez rapidement, j'ai rejoint un éditeur de logiciels de la Silicon Valley qui était pionnier de l'e-commerce. Et ensuite, j'ai travaillé dans les agences web, notamment chez Agency.com, donc une agence new-yorkaise.

2:12 Et là, j'étais à Londres à l'époque, en fait. Et on a mis en place le premier site Internet du Guardian et de The Economist. Et ensuite, j'ai travaillé chez Proximity BBDO, une agence plus marketing CRM pour P&G, une grosse boîte américaine. Et donc, en 2013, je me suis lancée dans l'aventure startup en rejoignant à l'époque le kiosque qui s'appelle maintenant Caféine et qui a connu, et c'est ça qui est important, une très très grosse croissance entre 2019 et aujourd'hui, on va dire. Donc, CAFEYN, je ne sais pas si vous connaissez tous, j'espère, mais c'est en fait le leader français du streaming de l'information. Donc, on a énormément grossi. récemment et notamment on est passé de 150 à 2000 titres, on est passé au départ de 0 à maintenant plus de 500 partenaires et on est en train de s'installer un peu partout en Europe. Donc on aura normalement 5 pays européens d'ici la fin de l'année, l'année 2021.

3:19 On est très orienté sur le produit, donc on a des bonnes notes sur les stores, on en est très fiers, donc 4.6 sur l'App Store et 4.6 sur Google Play. Et surtout, on a beaucoup grossi en mettant en place des partenariats. Donc, si vous avez un forfait Bouygues ou un forfait SFR, ou si vous êtes chez Canal+, ou si vous avez un Freebox Delta, vous pouvez avoir accès à CAFEYN gratuitement. Et aussi si vous avez un programme qui s'appelle Cédisconte à volonté. C'est grâce à vous qu'on peut lire tous nos magazines sur nos devices, Autre que papier, tout l'aspect numérique des magazines, c'est grâce à vous, sur tous les sites que vous venez de citer. Oui, exactement. Donc, en fait, nous, vous avez accès à l'intérieur de CAFEYN à, en effet, toute la presse, presse magazine et presse nationale, presse quotidienne, je veux dire. Donc, voilà. Donc, cette énorme croissance, elle continue, puisqu'on vient de faire l'acquisition de deux autres sociétés, de Millibris et Blendel, et je vais en parler un petit peu plus plus tard.

4:20 D'où la technique, avec justement ces acteurs-là que vous intégrez. Alors d'où la dette technique? La dette technique, elle vient surtout du fait qu'on est vieux, on est plus vieux. Une startup, on a commencé en 2008. Oh là là, mon Dieu, l'âge Internet, c'est énorme. Énorme. Donc, on est une scale-up. On aime bien s'appeler une scale-up. Et la dette technique, en effet, s'accumule assez souvent, notamment après 13-15 ans d'existence. Toutes les startups connaissent un petit peu ce problème parce qu'en fait, on commence à travailler en général avec des développeurs qui ont le niveau qu'ils ont au départ et on découvre la technologie. Et forcément, les technologies qu'on a utilisées, au début ne sont pas forcément ce qu'on appelle scalable, c'est-à-dire que plus vous avez d'utilisateurs, plus vous avez de partenaires, plus vous avez de fonctionnalités, plus il faut de la technologie très solide et celle qu'on a choisie au début n'est pas forcément celle-là. Parce qu'au début, on choisit une technologie pour aller vite. Donc, on a typiquement ce problème. Et ce dont je veux vous parler, c'est qu'en fait, on a énormément grossi.

5:21 Et comme on a grossi, on est passé de 40 à 150 personnes. On s'est organisé dans ce qu'on appelle les squads. Donc, le modèle qui est de plus en plus connu. Donc, c'est quoi une squad? C'est ça ma question. J'avais des grands yeux ouverts. J'apprends beaucoup de choses, beaucoup de termes techniques. Squad, une équipe en fait. Alors la squad, c'est au lieu d'être organisé avec typiquement votre équipe web, avec tous les développeurs web, votre équipe iOS avec tous les développeurs iOS ou l'équipe back-end, chaque organisation a toutes les disciplines. Donc une squad, ça va avoir un product manager, un product designer, un développeur iOS, un développeur Android, un développeur web, un développeur back, quelqu'un qui fait le QA et quelqu'un qui fait de la data. Ça, c'est un exemple de composition de squad. Et donc, c'est quoi l'idée derrière? C'est l'idée qu'en fait, la squad, elle est totalement autonome pour développer une nouvelle feature. Souvent, on appelle ça aussi des feature teams. Donc ça, c'est quoi l'idée? C'est à la fois d'être autonome, c'est aussi de limiter le nombre de personnes par équipe.

6:23 Parce que quand on est plus de 10, c'est très difficile de travailler en agile, puisque bien sûr, les squads, c'est une... des organisations agiles. Et l'idée, c'est qu'il faut limiter les tailles d'équipe. Et quand on est moins de 10, c'est beaucoup plus fluide. Par exemple, quand on fait des délits, il y a 7 personnes qui parlent et chacune a 3 minutes. Et du coup, ça va assez vite. Si on est plus, ça devient très compliqué de fonctionner. En tout cas en agile. Donc, c'est quoi ces squads? On les a divisés en deux tribus, donc une tribu sur vraiment l'information et l'autre tribu sur vraiment le business, on va dire. Et je vous expliquerai un petit peu plus tard les objectifs de chaque squad. Et ces squads, elles travaillent dans un process qui s'appelle le process donut. Pour moi, c'est Homer Simpson, le donut. Ce n'est pas forcément un process. Alors, ça nous permet de faire des breakfasts, des product breakfasts où on a des donuts. On y revient. Alors, ça devient plus compliqué, c'est sûr, aujourd'hui avec le Covid.

7:24 On est obligé de s'acheter chacun ses donuts quand on fait des présentations le matin. Mais c'est le donut process. Donc, l'idée, c'est d'avoir deux phases, une phase discovery et une phase delivery. Qu'est-ce que ça veut dire? La discovery, c'est là où on fait toute la conception, le design de chaque feature, où on fait vraiment les spécifications, les user stories, etc. Et la delivery, c'est là où les développeurs codent la feature qu'on doit coder et donc la livrent à la fin de la delivery. Et du coup, qu'est-ce qu'ils font les développeurs pendant la discovery? Ils aident à la discovery, mais ils font aussi ce qu'on appelle le tech care, c'est-à-dire qu'ils s'occupent de... la correction de bug, l'orifacto, la R&D, tout ce qui est purement technique, on va dire. Donc, il y a une forme de learning process aussi dans ce cadre-là, dans le donut process. Exactement, exactement. Et de toute façon, c'est itératif. Comme toute la méthodologie, c'est de toute façon itératif. On a grossi vite, donc forcément, on a accumulé de la dette technique et notamment, on a aussi changé de modèle. Donc, on est passé d'un seul catalogue à 450 catalogues différents selon les partenaires.

8:28 On est passé de 150 publications à 2000 et surtout, on est passé d'un modèle où on n'avait que des magazines. Donc, les magazines étaient, par exemple, hebdomadaires. Donc, on avait le temps de les mettre en ligne et de faire tout le traitement qu'on a à faire sur les magazines. À un service avec ce qu'on appelle la PQN et la PQR, donc la presse quotidienne nationale et la presse quotidienne régionale. Et surtout, la presse quotidienne régionale, c'est génial, mais pour chaque journée, vous pouvez avoir de 60 à 80 éditions, selon la région, à mettre en ligne le matin, bien sûr avant 7h du matin. Donc ça, il a fallu énormément automatiser, ce qui a changé complètement la façon dont on gérait le contenu. Et enfin, on est passé d'un modèle où on vendait un forfait à 10 euros et vous aviez des crédits, donc vous pouviez dépenser des crédits pour acheter un magazine. À un modèle unlimited, donc vraiment le modèle typique Deezer, Spotify, de je ferai un forfait à 9,99 euros et j'ai accès.

9:30 C'est à toute la presse. Voilà, ce qui est absolument génial pour les consommateurs. Mais qui a complètement changé de modèle derrière. La complexité de ça, ça a été le reversement aux éditeurs. Parce qu'avant, on calculait le reversement des éditeurs par rapport au crédit. Et donc, en gros, on donne à peu près la moitié du revenu aux éditeurs, ce qui est tout à fait normal. Et ça, c'était fait par rapport au crédit. Quand on est passé à Unlimited, C'est beaucoup plus difficile de calculer les reversements éditeurs par rapport à une consommation qui peut être de 5 magazines à 60 magazines, si vous n'avez que ça à faire de l'économie. J'ai une autre question pour vous. C'est plus difficile. C'est dimensionnable, je dirais, pour vous, parce que c'est un mensuel ou un hebdo, donc on a un peu plus le temps techniquement d'intégrer le produit à une presse quotidienne, où là, c'est tous les jours. Ça veut dire qu'initialement, le modèle technique n'avait pas été pensé pour l'intégralité du marché de la presse, mais simplement pour vos premiers clients.

10:34 Oui, c'est un peu ça. C'est-à-dire qu'en effet, on n'avait pas autant de pression d'avoir un système super automatique et super scalable parce qu'en effet, au départ, on s'est dit, on prend les magazines, on les transforme. Parce qu'en fait, ce qu'on prend, c'est des PDF qui sont dédiés à l'imprimerie. Donc, pour les transformer en numérique, il y a pas mal de traitements à faire. On change toutes les pages, on change ce qu'on appelle le color space, on les watermark pour que si jamais il y a du piratage, on puisse retrouver la personne qui nous a piraté. Donc voilà, il y a beaucoup de traitements. Et donc au début, on a juste fait ça de façon la plus efficace possible. Complètement sur mesure et en fait on avait un back office et on avait des gens qui manuellement faisaient plusieurs étapes pour mettre en ligne un magazine. Et c'est vrai qu'avec la PQN et la PQR, du jour au lendemain, on s'est dit qu'il faut tout automatiser. Et donc, il y a eu un gros travail là-dessus. Donc, tout le traitement. Donc, en fait, aujourd'hui, il n'y a aucune intervention humaine.

11:36 Donc, dès que le PDF est déposé par les éditeurs sur notre serveur FTP, c'est détecté automatiquement et toute la chaîne commence et tout est géré de façon automatique. Donc, toute cette partie, on avait déjà décidé à partir de 2019 de s'attaquer à la réduction de la dette technique, puisque comme je disais, les technologies qui avaient été choisies pour faire toute cette partie au départ n'étaient pas forcément très faciles à maintenir, faciles à faire évoluer et faciles à scaler surtout, puisqu'on traite quand même beaucoup, beaucoup de publications, il y en a 2000. Du coup, on a commencé début 2019 à refaire tout le système de récupération de contenu et de gestion de contenu que je viens de décrire. Et ça s'est plutôt bien passé. Et ensuite, en 2020, on a fait toute cette partie, la partie récupération des PDF sur le FTP, la partie traitement des PDF, la partie automatisation, et on a été jusqu'à améliorer la qualité

12:38 de ce qu'on a sur le web, parce que c'était déjà en très haute qualité sur les applications iOS et Android, et on a mis la même qualité sur le web, ce qui n'était pas forcément facile à faire. Donc, on n'a pas fait que de la réduction de la dette technique, on a aussi amélioré le service. Et donc ensuite, à partir de septembre 2019, comme je vous le disais, on s'est organisé en squad. Donc on est passé d'équipe de discipline. à des équipes qui avaient chacune un objectif business. Donc, la squad acquisition, elle a comme objectif d'aller chercher de nouveaux clients. La squad rétention, elle a comme objectif, une fois qu'on a les nouveaux clients, de les garder. Donc, le anti-churn, le très célèbre anti-churn. La squad contenu, elle s'occupe de comment faire montrer qu'on a autant de profondeur de contenu, alors que vous avez un petit écran, notamment sur un iPhone. Ce n'est pas évident de faire comprendre aux premiers utilisateurs quand ils arrivent sur le service qu'il y a 2000 titres derrière. C'est même très difficile. Et ensuite, on rend le contenu dynamique, ça change tout le temps, etc.

13:41 Et on a une squad qui s'occupe des partenariats, donc de l'intégration des partenariats, puisqu'on en a beaucoup. Et enfin, une squad qui s'occupe de services pour les éditeurs. L'avantage de ça, c'est que maintenant, on est beaucoup plus focalisé sur des objectifs business et c'est beaucoup plus clair. Et ça, ce n'est franchement pas facile dans ce qu'on fait. C'est chaque développement, chaque nouvelle feature, on a des KPI et on sait pourquoi on les fait, quelle valeur business ça va apporter à l'entreprise. Donc ça, c'est super. Par contre, depuis fin 2019, on avait quand même une énorme roadmap technique à faire, que ce soit côté mobile, côté web ou côté back-end. Et donc, on a commencé une grosse, grosse refonte de nos API et de notre modèle de base de données. Donc, on a créé... une nouvelle table, on a fait tout ça. Mais on s'est aperçu, déjà en août 2020, on a eu une énorme intégration à faire d'un nouveau partenaire avec plein de nouvelles features, alors qu'on était en pleine refonte.

14:43 Et à ce moment-là, l'organisation en squad nous a desservis. C'est-à-dire qu'on avait trop de choses à faire en même temps. Et malheureusement, comme la priorité, c'était vraiment côté business, on a laissé tomber une grosse partie de la refonte. Et du coup, Au lieu de... Si on avait terminé avant cette refonte, on aurait eu cette nouvelle intégration sur nos nouvelles API et notre nouvelle base de données. Mais à la place de ça, on a fait une intégration assez rapide sur notre legacy, donc ce qu'on appelle le legacy. C'est en général là où il y a le plus de dette technique. Et du coup, à la place de la réduire, on a augmenté la dette technique. jusqu'au moment où, en effet, on a eu un système qui était plus très stable. Et ça, C'est ça, c'est exactement ce que j'allais dire, c'est de ne plus avoir de stabilité. Pour un CTO, c'est votre cauchemar le plus absolu. Et j'ai vécu le cauchemar pendant deux semaines et demie.

15:44 Alors, c'était intermittent. Heureusement, le service n'est pas tombé pendant deux semaines et demie. Mais tous les matins, entre 6h30 et 7h, au moment de notre pic, parce qu'on a un énorme pic, tout le monde se réveille. La première chose que les gens font, c'est qu'ils vont sur Caféine et lisent la presse. Absolument. Et tous en même temps. Et du coup, ça faisait tomber le service le matin au moment où il était le plus utilisé. Donc ça, ça a été absolument terrible. Et donc, Tragédie Business, et ce que je dis souvent, alors on a augmenté la capacité des serveurs, parce que c'est un problème sur la base de données, et en attendant de corriger le problème et d'accélérer, en fait on a accéléré la refonte qu'on avait prévue dès le départ, parce qu'en fait en même temps d'avoir Parfait, les deux futurs, on a bien sûr eu beaucoup plus d'utilisateurs. Donc, on a eu les... Puisqu'on avait un gros nouveau partenariat. Donc, on a eu tout en même temps. Donc, voilà, c'est ça, on a eu double peine. Et donc, c'est là où on s'est aperçu qu'à ne pas avoir terminé notre...

16:47 Se débarrasser de la grosse technique qu'on avait, ça nous a vraiment desservi. Voilà. Ça, c'est ce que j'ai appris. Et c'est ce que... Alors, je ne dis pas que l'organisation en squad est responsable de ça. Mais par contre, ce que je dis, c'est que l'organisation en squad met vraiment le focus sur la valeur des nouvelles features et sur la valeur business. Et aussi, elle sépare les équipes. Donc, si on a cinq squads et on a cinq développeurs web, il y en a un dans chaque squad. Cinq développeurs IS, il y en a un dans chaque squad. Et du coup, on manque un peu de cohérence entre chaque. Et du coup, on peut se faire avoir sur certains... Enfin, ça peut provoquer certains problèmes. Ce sont des problèmes de cohérence. Le collègue de l'autre qui explique où est-ce qu'il en est, lui, dans son propre développement, pour commencer à identifier un peu les problématiques. Alors, normalement, ça devrait être tout à fait le cas. Normalement, on devrait avoir deux choses, et ça, c'est ce que je recommande très fortement. C'est déjà une équipe plateforme qui est inter-squad, et la plupart des personnes, quand elles s'organisent en squad, elles ont ça.

17:52 Et nous, on n'avait pas à l'époque des équipes assez grosses pour faire ça. C'est-à-dire que vraiment, l'idée, c'est d'avoir une équipe plateforme qui soit trans... mais aussi en effet de faire cette coordination qui nous a un peu fait défaut. Donc en effet dans les recommandations, l'idée c'est non seulement d'avoir des gens dont le rôle est de s'assurer que tout se passe de façon cohérente entre les squads, mais en plus, moi une autre recommandation que j'aurais, c'est de faire, puisqu'on travaille en sprint, de faire une fois tous les deux mois, par exemple, un sprint qui soit un sprint purement technique où toutes les personnes se retrouvent de toutes les squads. Donc ça, c'est vraiment quelque chose que nous, on va mettre en place maintenant pour qu'on s'assure de la cohérence de l'architecture, en fait, entre autres. Voilà, donc ça c'est ce que je dirais surtout en conclusion, c'est qu'il faut absolument ne jamais oublier les photos. Ça paraît évident, mais comme il y a de plus en plus de pression sur la valeur et sur le ROI, sur les KPI, etc., souvent on oublie que,

19:02 oui, bien sûr, il faut faire des features, oui, bien sûr, il faut créer de la valeur pour l'entreprise, mais il faut surtout ne pas oublier de bien regarder ses fondamentaux, donc la qualité du code, l'architecture, le test coverage et surtout la cohérence entre les sprints et entre les features. Voilà, en conclusion, je dirais que le business, il faut faire attention à la... Ça t'explique souvent les choses se passent mal. Je pense que ça, ça va parler à beaucoup de monde. C'est mon expérience, pas seulement dans cette expérience, mais de toute ma carrière. Petite anecdote, un jour je suis partie d'une entreprise où j'étais, où j'avais mis en place ce qu'on appelle les profession services, etc. Et les deux fondateurs de la boîte m'ont dit, Oh là là, mais c'est dommage, on n'avait jamais à penser à toi. On avait... Voilà, on avait...

20:05 Et je me suis dit, c'est le plus beau compliment qu'on m'a jamais donné en tant que CTO, c'est... Oui, on s'en occupait, enfin, la technique, on n'y pensait même pas, quoi. Parce que c'est ça, quand vous faites bien votre travail et que tout est stable et tout est maintenant, et si rien ne se casse la figure, il y a le moins de bugs possible, c'est que vous allez travailler sur les fondamentaux, mais c'est du travail très invisible et très difficile à justifier, mais sur lequel il faut en tant que CTO absolument rester complètement vigilant. C'est ce qu'on entend aussi beaucoup pendant ces différents talks avec des experts comme vous, c'est qu'il y a une invisibilité effectivement du CTO et que ça empêche aussi les autres fonctions de l'entreprise de comprendre l'implication majeure qu'a la technique dans le business en fait. Donc, ce n'est pas quelque chose qui est au fond de la cave et puis on ne regarde pas trop et puis on laisse faire. Non, non, d'où le fait de travailler aussi en squad en intégrant plusieurs fonctions qui permettent d'évangéliser plus largement dans l'entreprise sur les impacts majeurs qu'a la technique en fait, sur le quotidien. C'est exactement ça.

21:07 Je pense qu'en plus de mettre en valeur tout ce qu'on fait côté produit, ce qu'on fait de façon, justement, ce dont je parlais, les breakfast, donuts, etc., où on raconte ce qu'on fait côté produit, moi, ce que j'essaie de mettre en place maintenant, c'est des dashboards et des KPIs qui montrent tout ce qu'on fait en termes de test coverage, stabilité, etc. Mais c'est vrai que ce n'est pas parlant et ce n'est pas sexy. Et pourtant, c'est le cœur de notre métier. Donc, je pense qu'il faudrait, ça existe peut-être, mais des sociétés qui font du marketing de la tech ou qui savent comment mettre en valeur les fondamentaux dans une boîte avec des sortes de graphes et de dire, voilà, là, on en est là, là, on en est là. Alors, pardon, je vous ai coupé sur les leçons. Des choses qui parlent un peu. Cette expérience malheureuse, entre guillemets, mais qui vous a permis d'optimiser le process. Oui, en fait, c'est ça. L'idée, c'est vraiment de s'assurer qu'on a bien sûr une équipe trans-squad, qu'on a beaucoup de coordination trans-squad. Et aussi, comme je disais, une fois tous les deux mois, on fait un sprint avec toutes les équipes qui se retrouvent et on regarde tous les sujets d'architecture, les sujets de performance, qui sont bien sûr très, très importants, surtout dans des business comme les nôtres, où on a des gros pics.

22:13 Les sujets de coûts aussi, puisque c'est facile de... d'avoir du cloud et de payer beaucoup d'argent pour pouvoir faire face au pic, mais ce n'est pas l'idée. L'idée, c'est aussi d'économiser et de le faire de façon la plus efficace possible. Donc, il y a toute une partie efficacité qui est très importante. Ça aurait été cauchemardesque pour vous, mais pour vos équipes, en fait, elles ont bien senti cette montée en charge et le fait d'être vraiment à la limite du précipice en se disant, mais si ça plante, même si on monte en capacité de réseau, de stockage, bien sûr pour l'instant on tire la route mais ça peut quand même péter à tout moment comment vous avez géré ça humainement en tant que manager, pas en tant que CTO? Alors, en tant que manager, on a travaillé de façon très, très proche. Alors, il y a... Il se trouve que j'ai des développeurs qui sont à La Réunion et qui ont un décalage horaire. Je me réveillais tous les matins à 5 heures pour qu'on regarde ensemble tout ce qui se passe. Parce qu'en fait, tout est sur le cloud, donc on a de l'autoscale. L'autoscale, ça veut dire que...

23:14 Plus il y a d'utilisateurs, plus ça monte tout seul. Donc, c'est très facile. Ça, c'est super. Ça, ça s'est très bien marché sur l'API. Le problème, c'est sur notre base de données, il n'y a pas d'autoscale. Donc, c'était à nous de faire le scale à chaque fois à la main, tous les matins. Donc, point de vue humain, on est devenus très proches, encore plus proches qu'on était avant. Et pendant deux semaines et demie, j'ai fait entre 5h et 8h du matin, on faisait du monitoring et on ajustait les choses à la volée. Est-ce qu'en parallèle, vous avez eu des vidéos de tech leaders dans votre équipe au moment où il y avait justement ce problème qui commençait à enfler? Alors oui, j'ai fait intervenir aussi des experts, donc des boîtes externes qui nous ont aidés, beaucoup aidés, heureusement, sur des choses très très pointues qui sont des choses de DBA, donc par exemple, réindexer, non, défragmenter les index d'une base de données. Et alors ça, typiquement, c'est un truc de dette technique, c'est-à-dire qu'on avait une base de données qui était là depuis 13 ans, donc on n'avait pas défragmenté les index, parce qu'on n'avait pas de DBA et que ce n'est pas une tâche auquel on pense tous les jours.

24:21 Et c'est d'ailleurs ce qui nous a sortis du problème, c'est-à-dire qu'à partir du moment où on a fait ça, tout s'est mieux passé. Alors, on a fait plein d'autres optimisations. mais celle-là, ça a été celle qui nous a débloqués. Et c'est grâce à une boîte externe qui est spécialiste dans la performance des bases de données qu'on a fait ça. On n'a pas intérêt à finalement se séparer de cet héritage lourd. Et puis repartir de zéro et créer un nouveau back-office qui, lui, pour le coup, sera peut-être plus scalable parce que notre enseignement de ce qu'on a vécu nous permet de nous dire que, oui, on n'avait pas imaginé qu'on allait intégrer la presse quotidienne alors qu'avant, on faisait du magazine. Est-ce que c'est une option qui a été évoquée? au sein de toutes les sociétés, vous-même, au sein du comité de direction. Oui, oui, tout à fait. Alors, c'est toujours très difficile à vendre, entre guillemets, mais c'est une chose que déjà j'avais fait en arrivant, c'est-à-dire que quand je suis arrivée, on avait une application iOS, Android aussi, pleine de techniques, et on a tout jeté, on a tout recommencé. Et c'est bien souvent, ça fait peur au business, alors qu'en vrai, c'est bien souvent bien plus sain de faire ça.

25:22 Et là, c'est ce qu'on fait aussi sur la nouvelle API et une nouvelle base de données, c'est l'idée de faire une refonte. Après, la seule difficulté là-dessus, c'est la continuité du service. C'est-à-dire que pour une application, entre guillemets, c'est facile de tout refaire et de la mettre sur les stores quand elle est refaite. Par contre, pour tout ce qui est backend, base de données, il faut de la continuité puisqu'on a toutes les informations des utilisateurs, les logins, etc. Donc, c'est un petit peu plus difficile de partir from scratch. Mais oui, en effet, c'est très souvent le cas. Je pense même qu'il devrait y avoir une règle, enfin, au bout de 10 ans, repartir à zéro, surtout quand on a utilisé des technos qui ne sont pas forcément les plus en pointe et qui posent des problèmes. Pour la prochaine fois? Oui, je pense que c'est une bonne idée de partir à from scratch. Merci beaucoup Marine. Alors bon, comme nous sommes dans le dernier sprint de Noël, on va se mettre aussi en mode squad networking puisque vous nous faites l'amitié de participer tout de suite à une session de networking. Donc nos tech leaders vont pouvoir vous poser des questions spécifiques sur l'intégralité des informations que vous nous avez confiées ce matin.

26:24 Donc merci infiniment de continuer de prolonger ce partage d'expérience. Vous savez qu'ici à Tech.Rocks, On aime justement ces échanges, surtout quand il n'y a aucun bullshit, ce que vous avez fait ce matin. Merci beaucoup Marine, à très bientôt. Oui, et à tout de suite pour les Tech Leaders. Merci, à tout de suite.