Prendre les bonnes décisions dans un monde tech en mouvement

0:03 Le gros changement qu'il y a eu par rapport à il y a 5 ans, c'est que maintenant l'IA, tout le monde en parle. Ce n'est plus un sujet de niche technique. C'est plus possible de se plaindre. Aujourd'hui, on a des outils IA qui nous facilitent la vie. On peut enfin se concentrer sur des choses à valeur ajoutée. Bonjour à toutes et à tous, je suis très heureux d'animer ce nouvel épisode du podcast Tech.Rocks. Je suis Samir Guelbi, CEO de Fondative, une entreprise d'ingénierie qui aide les CTO à améliorer leur delivery et renforcer leur socle technique. Je suis moi-même ex-CTO de formation ingénieur en informatique. J'évolue depuis plus de 20 ans dans le monde de la tech et j'ai le grand plaisir aujourd'hui d'accueillir Céline Bayer, CTO de Lemonway, l'un des acteurs majeurs de Paymon Europe que vous connaissez certainement. On va parler d'un sujet qui devrait résonner pour pas mal de tech leaders, CTO sous pression. Comment prendre les bonnes décisions dans un environnement incertain?

1:03 Alors, ça nous fait penser à l'IA générative qui bouscule les repères, aux contraintes réglementaires, aux cas de toffes budgétaires, aux enjeux de souveraineté, etc. Et avec Céline, on va essayer de démystifier tout ça par du concret. Et pour commencer, Céline, est-ce que tu peux nous parler de ton parcours et de ce qui t'a amené à prendre la direction de la tech chez Lemonway? Merci beaucoup Samir, ravi d'avoir cette discussion avec toi aujourd'hui. Moi, je suis dans la tech depuis 2006. J'ai commencé en tant que développeuse, puis évolué sur différents rôles. Et actuellement, je suis chez Lemonway, ça fait déjà deux ans, avec le rôle de CTO. Et ce que j'aime beaucoup, c'est d'avoir une vue globale. À la fois au niveau de l'infra, au niveau du dev, de la qualité. Et ça qui est vraiment hyper enrichissant et dans un domaine de la fintech qui bouge tout le temps. Il y a beaucoup de choses à faire, beaucoup d'enjeux techniques. Et c'est ça qui me motive au quotidien. Comme on a eu la discussion, je sais que c'est vraiment le profil parfait pour cet épisode parce que tu es plein dedans.

2:11 Il y a les sujets qu'on va aborder qui te concernent comme tout le monde. Mais avec ça, tu es dans un monde trop réglementé qui est le paiement. Et dans l'Europe, au sein de l'Europe, et donc ça tombe bien. Alors, avant d'aborder le vif de sujet, justement, je pense qu'il soit important, Céline, je ne sais pas si tu es d'accord avec moi, de prendre un peu de recul sur le rôle du CTO qui a pas mal évolué ces dernières années. Et si tu compares avec il y a cinq ans, par exemple, quels sont les points clés qui illustrent le mieux ce changement? C'est une bonne question parce qu'il y a cinq ans, j'étais dans une autre boîte, dans une autre fintech et je peux, en tout cas de mon point de vue, voir ce qui a changé. Par exemple, il y a cinq ans, le cloud dans les fintechs, ce n'était pas une évidence. Je pense que nous, en tant que... responsable technique, on savait qu'on allait tous vers le cloud, mais c'était encore difficile de convaincre des sociétés qui disaient non, il faut que ça soit on-prem, il faut que ça soit géré par nous et par personne d'autre.

3:11 Et là, c'était plutôt les banques qui menaient un peu cette orientation. Il y a eu quelques pionniers, je me souviens à l'époque j'avais discuté avec United qui avait déjà migré vers le cloud. Et pour moi, c'était une évidence qu'à un moment donné, il fallait aller vers le cloud. Donc, c'est un chantier que j'ai mené à ce moment-là. Mais quand je suis arrivée chez Lemonway, il y avait la volonté d'aller vers le cloud, parce qu'il y avait encore une partie qui était on-premise, une autre partie qui était déjà sur AWS. Et donc, c'est un projet que j'ai mené parce qu'il fallait absolument sortir de... C'est infraphysique et on a migré sur Azure toute la partie paiement. Je pense aussi aux contraintes réglementaires qui ont évolué. D'abord, il y a de plus en plus de mises à jour, de plus en plus souvent. En ce moment, on parle beaucoup d'Aura chez nous. On a aussi un environnement qui est PCI-DSA, donc il y a des évolutions de cette certification, qui a des implications techniques. Il y a cinq ans, il y avait aussi de la réglementation, mais ce que je vois, c'est que ça s'accélère.

4:16 Il y a de plus en plus de normes, mais elles sont là aussi pour le bien de tout ce qu'on produit, parce qu'il ne faut pas faire n'importe quoi. C'est important de respecter ces réglementations. Maintenant, la difficulté, c'est qu'il y en a beaucoup. Par exemple, chez Lemonway, on est aussi sur un terrain européen, donc il y a aussi des régulations locales. Il faut savoir s'adapter et assez vite. C'est ça. Il y a aussi l'IA. Exactement, j'allais te dire, le gros changement qu'il y a eu par rapport à il y a cinq ans, c'est que maintenant l'IA, tout le monde en parle. Ce n'est plus un sujet de niche technique. Tous les départements ont un avis là-dessus. On a tous envie, on se dit ça va. vraiment changer le monde. Moi, honnêtement, j'ai hâte que ça s'améliore encore. J'ai beaucoup d'attentes de l'IA. Aujourd'hui, clairement, ça ne remplace pas les développeurs. On passe plus de temps à relire et vérifier les hallucinations que de vraiment pouvoir remplacer tout le développement.

5:17 Mais par contre, ça fait déjà gagner énormément de temps. Sur des tâches qui ont peu de valeur ajoutée. Et je trouve que c'est un moment génial pour nous, en tout cas à la tech, et pour les leaders tech, de travailler dans ce monde qui évolue sans cesse, parce qu'il y a beaucoup de choses à faire. Oui, écoute, je suis entièrement d'accord avec toi sur ce sujet de l'IA. De toute façon, on a une question qu'on verra plus tard sur la hype et qui rejoint un peu le sujet du shomit, le sujet de base. Et je pense, j'ajouterais à ce que tu as dit, Céline, qu'aujourd'hui, je ne sais pas si tu es d'accord avec moi, qu'on doit de plus en plus décider plus vite avec beaucoup d'incertitudes et beaucoup de contraintes. Et ça, on ne l'avait pas. C'est-à-dire qu'il n'y avait pas très longtemps, on prenait des décisions sur la base de est-ce qu'on fait cette fonctionnalité, on ne fait pas cette fonctionnalité, est-ce qu'on fait ceci, est-ce qu'on prend cette direction ou pas. Mais il n'y avait pas toutes ces contraintes qui arrivent au même temps, qui soient même contradictoires parfois, parce que quand tu dis d'un côté, par exemple, là, on va prendre le duel d'innover

6:24 vite, sans trop être loqué, ça devient un peu compliqué. Et ça nous amène... Justement, à des sujets comme ça, par exemple, aujourd'hui, les hyperscalers, les clouds publics, Azure, AWS, GCP, ils offrent des services managés qui te permettent d'aller vite, mais en même temps, au risque de devenir trop lié à ces acteurs, à une solution qu'ils offrent, etc. Et déjà, qu'en penses-tu? Et est-ce que tu aurais quelques situations à partager à ce niveau? Oui, c'est vrai que je suis complètement d'accord avec toi. Il y a beaucoup de moments où on est obligé de prendre des décisions sans avoir toutes les clés, sans savoir tous les impacts, parce qu'il faut quand même avancer. Et donc, oui, il y a plein de moments où j'ai dû avancer. Parce qu'en fait, si tu es figé, finalement, tu vas régresser, ça ne fonctionne pas. Donc, tu es obligé de prendre une décision, même si elle est imparfaite, ça se fait avancer. Pour donner un exemple, si on parle du cloud, quand on a fait le lift and shift vers Azure, c'est vrai qu'on a favorisé de vite sortir de l'infrapysique qui nous posait des gros problèmes.

7:34 On n'a pas tout retransformé d'un coup, on n'a pas fait tous les changements d'un coup. Et puis aujourd'hui, on est dans la deuxième phase où on se dit, est-ce qu'on va prendre des services managés ou pas? Parce que ça risque de nous loquer sur Azure. Alors qu'on a aussi une autre partie sur AWS. C'est vraiment des questions qui me sont posées au quotidien. Je n'ai pas la réponse ultime. Je pense qu'il faut être juste pragmatique. en avant très vite, il y a plein de services déjà tout fait qui font le job. Juste attention à monitorer combien ça coûte, est-ce que tu vas voir les personnes qui vont bien comprendre l'archi et vont pouvoir gérer ça. Mais en tout cas, je ne regrette pas d'avoir fait le move, même si c'était compliqué et imparfait, même si là, ça laisse des chantiers encore à faire. Parce que sinon, on sera encore à se poser la question, quelle est la meilleure méthode pour sortir de l'infraphysique? Et en fait, on aurait encore de plus gros problèmes, je pense.

8:38 Est-ce que tu ne penses pas que, par exemple, des stratégies aujourd'hui qui deviennent de plus en plus, je dirais, utilisées ou adoptées, ce qu'on appelle les clouds agonistiques, les solutions basées sur Kubernetes, comme ça, qui ne te permettent pas d'être vraiment locké à un cloud provider, mais plutôt tu peux in fine prendre le service manager qui est offert par n'importe lequel, parce qu'aujourd'hui on peut trouver chez ScaleOS, chez OVH, chez même Infomaniac, acteur suisse, des services managers Kubernetes, et je peux en même temps rester chez AWS ou chez Azure parce qu'ils offrent pas mal de fonctionnalités, mais en même temps je peux migrer si jamais demain la contrainte de souveraineté m'attrape. Je ne serai pas vraiment... trop loqué à ces hyper-scalers. Oui, on a eu beaucoup de débats en interne sur Cube ou pas Cube. On n'a pas opté pour Cube, en tout cas à date.

9:41 Je ne dis pas que ça ne peut pas changer dans les prochains mois ou années. Les raisons, on avait peu de compétences en interne qui maîtrisaient bien Cube. Parce que moi, ce que je comprends, c'est qu'il faut une bonne connaissance de Cube. Même si on avait externalisé, après, il faut quand même pouvoir manager le système. Le système. J'ai eu des retours d'expérience aussi, dont j'en ai discuté autour de moi, de« il faut bien aussi gérer les coûts que ça peut engendrer». Mal fait, il y aura encore d'autres soucis. Donc oui, pour ces raisons-là, on n'est pas allé vers Cube. On a continué la docurisation, on a continué certains services managés, mais on n'a pas tout orchestré avec Cube. J'ai un autre exemple, on a racheté une boîte en juin dernier qui s'appelle Paygreen. Et eux, ils ont tout sur GCP et Kubernetes, donc c'est un peu différent de... De ce qu'on a, nous, installé sur Azure et AWS.

10:43 On pourrait envisager, se dire, on a GCP, on arrête GCP, on le met sur un autre cloud. Après une petite étude, avoir discuté avec les équipes, il y a quand même des adaptations à faire. Donc, ce n'est pas si portable que ça, ou en tout cas dans l'implémentation qu'ils en ont fait, je ne sais pas. Oui, c'est à discuter. Et la décision, ça a été, comme on a beaucoup de projets en cours, ne passons pas non plus beaucoup d'énergie à les juste porter pour porter, parce que, de toute façon, on ne va pas mutualiser sur les autres services qu'on a actuellement sur AWS, si on passait de GCP vers AWS. Donc, pour l'instant, c'est encore sur GCP, en mode cube. Bien sûr, je n'ai pas dit on arrête Cube et on enlève tout ça, parce que ce système fonctionne bien à l'heure actuelle. Je comprends, je comprends. Je comprends et je t'assure que moi, on a pas mal de clients qui optent aussi pour rester enfin sur un seul cloud provider. J'ai peu de clients que je connais qui sont réellement multi-cloud. D'abord, ça, je ne connais pas trop.

11:44 C'est vrai qu'on en parle, mais réellement, il n'y en a pas trop. Généralement, ce qu'on fait sur du multi-cloud, c'est soit des CDN, tu vois, pour faire de la distribution du contenu qui soit vraiment cheap, etc. Ou alors, on fait des stratégies de DRP, des disaster recovery plans, que si jamais il y a un truc qui brûle ou qu'il arrive quelque chose de vraiment grave, on peut migrer sur notre cloud. Et c'est là où des solutions comme Pub peuvent aussi aider, parce qu'au lieu de repartir en plusieurs jours, tu peux le faire en quelques-uns. C'est vrai qu'il y a des adaptations à faire, et je te rejoins parfaitement là-dessus, ce n'est pas 100% portable. Mais tu peux industrialiser cette partie de migration. Si tu veux faire tourner ton infra sur GCP de base et tu veux, en cas de problème, la faire tourner sur Scaleway, Tu peux tout préparer en amont. Ça, c'est possible. C'est vrai que c'est possible. Nous, notre stratégie DRP, là, pour le coup, on a utilisé les services d'Azur.

12:50 Donc là, oui, on est loqué par rapport à ça. Mais bon, c'est des services assez critiques et c'était plus simple à mettre en place. Que d'aller refaire une infra ou de... Parce que là, on a beaucoup de VM à gérer. En fait, on est encore en mode VM. Tout n'est pas dockerisé. Tout n'est pas... C'est encore des choses à refaire. Mais oui, je vois où tu veux en venir. En fait, je pense qu'à la réponse à un problème, il y en a plusieurs. Plusieurs réponses possibles. C'est ça qui est génial dans notre métier, c'est qu'il n'y a pas une réponse, mais on peut avoir différentes stratégies. C'est tout l'objet de cet épisode. On va essayer, comme je disais, d'avoir du concret, des retours d'expérience. Alors, ça nous mène au deuxième sujet. Qui est justement la gestion de priorité entre trop de choses qui arrivent urgentes d'un coup et qui sont hétérogènes. Je ne sais pas si tu es d'accord avec moi encore, mais il y a quelques années, les CTO ne chômaient pas non plus.

13:55 Ce n'est pas parce qu'il y a eu l'IA. Et parce qu'il y a eu la souveraineté, parce qu'il y a eu toutes ces contraintes réglementaires, que le CTO devient d'un coup saturé, il doit prendre des décisions, etc. C'était toujours le rôle du CTO de le faire. Sauf que ce qui change vraiment, en tout cas à mon avis, c'est aujourd'hui, avec ces sujets qu'on a l'habitude de gérer, qui est la dette technique, le delivery sur le backlog, faire monter en compétence les équipes, les fédérer, arriver à emborder, à embaucher au bon moment, etc. Là, il y a des nouveaux sujets qui émergent, qui sont très hétérogènes. et en même temps prise immature, et en même temps, on doit prendre des décisions urgentes là-dessus. Je pense, si jamais tu es attrapé par une contrainte réglementaire de DMA, de RGPD, ou que tu dois renforcer la sécurité parce qu'on a peur que la Russie fasse un truc comme la France, par exemple, ou parce que tu dois utiliser des verrous pour qu'il n'y ait pas trop de code qui est généré par l'IA, par tes devs, et qui ne soit pas contrôlé.

15:00 Est-ce que tu peux partager quelques situations vécues à ce niveau ? C'est-à-dire comment tu gères les priorités, tu prends des décisions alors qu'il y a plusieurs priorités qui prennent différentes orientations et différentes directions. Tu as complètement raison. Il y a quelques années, enfin même dans toute ma carrière, à aucun moment la CTO ne se met, il y avait toujours beaucoup de sujets en même temps. C'est vrai que là, on en rajoute encore. Tu parlais de l'IA, il y a beaucoup de choses à prendre en compte. On ne prend pas que des décisions techniques, comme tu disais, on accompagne aussi nos collaborateurs. En fait, les décisions, moi, je les prends souvent en concertation avec le business. Je me dis où est-ce qu'on a de la valeur. Parfois, on a des sujets de fonds qu'il faut faire. On ne voit pas tout de suite, ce n'est pas une fonctionnalité produit, une fonctionnalité qui va rentrer dans les mains du client. Mais de voir certaines fondations comme l'infrastructure, c'est très important parce qu'en fait, sans ces fondations-là, tu ne peux rien construire. Je me souviens d'une décision qui a été difficile à prendre.

16:03 Je parlais beaucoup de cette migration de l'ift and shift vers Adir. On a basculé, c'était il y a presque un an, c'était en décembre de 2024. Et suite à ça, malgré tout ce que j'avais entendu, malgré ce qu'on avait commencé à regarder, toute la partie Finopt a mal été gérée. Et je prends aussi ma part de responsabilité là-dessus. Et en fait, à partir de là, j'ai mis un stop sur beaucoup de projets. venu très important. On allait même carrément mettre la boîte en risque en ayant des factures incroyables et absolument inattendues au niveau d'Azur. Et là, c'était difficile à faire comprendre aux équipes qu'il y a des projets qu'on allait mettre en pause. On n'allait pas du tout pouvoir les délivrer. On allait devoir ralentir des releases. Des personnes qui avaient travaillé sur un projet en fin d'année ne verraient pas du tout le jour de ce projet avant six mois.

17:03 Donc, il y a des prestataires qui ont travaillé sur un sujet en particulier. On a arrêté la prestation, mais ils n'ont pas vu le résultat. Donc, c'était frustrant pour les équipes. Et en même temps, on a beaucoup appris. Finalement, ça a soudé tout le monde. On parle là de la partie Finop sur Azure, mais ça a motivé les autres équipes à regarder de plus près aussi les coûts qu'on avait sur AWS. Et donc, finalement, d'une contrainte, on a fait nos opportunités de s'améliorer collectivement. Et je pense que ça a sensibilisé tout le monde. Après, si je reviens sur le sujet de la priorisation, moi, j'ai déjà connu dans toutes les boîtes où je suis passée, tous les projets sont urgents. Donc, c'est à nous de faire suffisamment le tri et le tampon pour ne pas que les équipes le ressentent trop, parce que tu ne peux pas mettre les équipes sous pression en permanence. C'est obligé d'avoir des moments où ça va un peu moins vite. Des périodes où ça va très vite, des périodes où les équipes sont focus, parce que le contexte switching, ça ne fonctionne pas du tout.

18:08 C'est vrai que c'est un défi au quotidien, en fait, de pouvoir prioriser, savoir dire non aussi, proposer des solutions tout en disant non, des alternatives. Mais c'est sûr que c'est un jeu d'équilibrisme. Comment tu as fait? Moi, ça m'intéresse de comprendre un peu plus, d'avoir ton tour d'expérience, parce que c'est vrai que la pire chose que tu fais à une équipe qui performe, c'est que tu viens leur dire« j'arrête un projet». Moi, je sais de quoi je parle. Et donc, d'un coup, tu as des gens qui étaient très motivés et qui deviennent d'un coup réticents et qui perdent même confiance. Des fois, on est incriminé des CTOs de dire qu'on entend trop les décisions des DAF, des CIO, etc. On a du mal. On a des technos en face qui ne comprennent rien à ces sujets et qui veulent juste faire de la techno et faire des bonnes choses. Et on va leur dire non, mais on ne peut pas financer ça, on ne peut plus financer ça. Moi, ça m'intéresse. Comment tu as fait? Sur l'exemple des coûts à sur, les coûts étaient vraiment tellement énormes que j'ai dit, moi, mon objectif, c'est certainement pas de devoir couper les postes au final.

19:14 Parce que si on continue comme ça, en fait, on met en risque vraiment toute la boîte. Je pense que tout le monde comprend quand on touche à ton contrat de travail, on te dit peut-être demain tu n'as plus de travail. Peut-être que j'exagère un peu le trait parce que ça n'a pas été jusque-là, mais les gens comprennent. même au-delà des projets techniques. Je pense à un projet en particulier, c'est un projet de mettre à disposition des bases de données à la demande, donc pouvoir récupérer des morceaux de certaines tables, par exemple, sur des environnements de dev, de staging, surtout de dev, et de les anonymiser. Pour pouvoir générer à la demande des environnements. Et donc ça, j'ai dit, ce projet, on va l'arrêter, parce qu'on a besoin de créer de nouvelles ressources. sur le nouvel environnement, qu'on ne maîtrise visiblement pas encore bien. D'un côté, faites bien l'étude de quelles ressources vous avez besoin pour qu'on puisse chiffrer. Et d'un autre, on se donne comme objectif d'atteindre cette target en dessous de laquelle c'est bon, on peut enfin respirer et à partir de laquelle on va pouvoir redémarrer le projet.

20:20 Et on a tenu parole, en fait. C'est vrai que ça a pris beaucoup de temps, mais ça a été suivi. Donc, je pense que quand tu donnes un cap à l'équipe, ce n'est pas juste couper pour couper. Tu donnes le contexte, tu donnes les jalons, même. Tu ne sais pas forcément à quelle échéance ça arrivera, mais donner un peu les KPI que tu suis pour te dire, c'est bon, c'est de nouveau le feu vert pour... Aller sur les projets et aussi les garde-fous qu'on met quand on lance un projet. On a besoin aussi de bien chiffrer les ressources dont on a besoin, pas que la facture de nouveau reflambe. Je pense qu'avec l'accompagnement, les équipes comprennent. J'ai des gens très intelligents et très compréhensifs dans les équipes et on est là pour apporter des solutions et pas simplement pour dire non à tout. Ah oui, clairement, je suis entièrement d'accord avec toi et je conclue peut-être que même au niveau des équipes, il faut que les CTO les éduquent, que désormais il n'y a plus des priorités qui ne changent plus, qu'on doit toujours s'attendre à des priorités qui changent et parce que c'est juste le contexte dans lequel on évolue tous.

21:25 Qui change très vite. C'est-à-dire qu'il faut... Il ne faut pas se dire que changer les priorités, c'est une mauvaise chose. Aujourd'hui, il faut embrasser ces changements. Il faut savoir vivre avec. Il faut bien les prendre. Et comme tu dis, il faut donner un cas. Il faut vraiment expliquer les choses, expliquer le contexte. Et on doit s'attendre, nous, CTO, à ce que nos équipes, comprennent. Et de toute façon, ils n'ont pas le choix. Ils doivent apprendre à comprendre. Et je le dis qu'ils n'ont pas le choix, mais c'est à nous de les éduquer, qu'ils apprennent à fonctionner de telle sorte. Oui, en tant que CTO, tu te donnes la direction, tu dis le résultat vers lequel tu vas arriver. Après, le comment est challengeable par les équipes. J'ai des équipes expérimentées et je compte vraiment sur eux pour être créatif et amener des solutions. Mais oui, c'est beaucoup de communication. En tout cas, c'est mon style de management. Où je fais participer beaucoup les équipes, parce que je n'ai pas du tout la prétention de tout savoir.

22:26 Écoute, là, on va s'intéresser à un autre sujet qui va être le sujet du summit, mais on va juste introduire peut-être certains sujets. C'est toute la hype autour de l'IA versus la réalité. Et qui m'a, moi personnellement, aujourd'hui je ne pratique pas le métier de CTO, mais j'ai beaucoup de clients qui ont des CTO, et même un CTO à moi qui est un peu plombé sur ce genre de choses. Alors parmi tous ces sujets, il y a particulièrement la HIPAA qui devient d'un coup le sujet de tout le monde, y compris et surtout les non-tech, or entre autres. ce que racontent les médias, les grands patrons, les GPT, les startups IA, plusieurs influenceurs. Et la réalité du terrain, on sait très bien qu'il y a un gap, comme tu le disais tout à l'heure, Yann ne remplace pas encore les développeurs et elle ne va pas le faire. Mais ce n'est pas ce qu'on raconte. On dit que, par exemple, dans les médias, on dit qu'il n'y a pas loin que quelques jours, le patron de Claude Code disait que 90% du travail des développeurs est fait par l'IA.

23:30 Ce n'est pas vrai. On sait que ce n'est pas vrai, nous. Et ça complique notre vie un peu plus. Quand il faut dire non à un projet trop hype, justement, comment arrives-tu à convaincre? D'un côté, la direction qui vient te dire, comment c'est faisable pour les autres, pas pour nous? Et du côté des équipes qui, eux, te disent, oui, tu as raison, parce que ce n'est pas la réalité, etc. Ce paradoxe-là, comment tu arrives à le gérer? C'est vrai que je l'ai entendu beaucoup. On va remplacer tous les techs par de l'IA. J'ai envie de dire pourquoi pas. J'ai envie d'y croire. Aujourd'hui, ce n'est pas du tout possible. On fait des expérimentations. Je pense qu'on pourrait aller plus loin, mais encore une fois, il faut arriver à dégager du temps. J'essaie de trouver des compromis en laissant la liberté aux équipes d'expérimenter, en sensibilisant. Mais en même temps, de toute façon, cet objectif de remplacer par l'IA, à l'heure d'aujourd'hui, c'est encore un peu utopique. Il y a des projets qu'on a faits en utilisant beaucoup d'IA ou beaucoup de LLM.

24:30 Et ce que je disais en début de podcast, c'est qu'on a passé aussi beaucoup de temps à bien relire, à re-challenger et à éviter les hallucinations. Je pense que tu ne peux pas faire confiance 100% à l'IA si tu ne maîtrises pas déjà ton sujet, parce que sinon l'IA va t'emmener n'importe où. En tout cas, on a beaucoup travaillé sur l'outillage, équiper les équipes avec des licences, faire du partage d'expérience dans les moments en rang. Je rassemble toute la tech. Il y a eu des démonstrations à plusieurs reprises de personnes qui ont utilisé Cursor, de personnes qui ont utilisé Nuitaine. Et en fait, ça a donné envie aussi aux autres de tester. Par exemple, j'ai une équipe qui était plutôt sceptique au départ à utiliser les outils d'IA. Et qui maintenant ne peut plus s'empêcher, n'utilise que le curseur et ne pourrait plus utiliser d'autres outils. Donc, je trouve qu'en tout cas, en interne, on pourrait être plus vocaux, nous, département texte, sur l'IA.

25:36 C'est vrai que moi-même, je dis beaucoup de choses autour du sujet, mais je ne le partage pas systématiquement. À la boîte ou même à mon codire, je pourrais faire ça beaucoup mieux. Parce que finalement, ceux qui parlent beaucoup de l'IA, c'est d'autres départements. Après, on a aussi la chance d'avoir une personne qui a été dédiée à ce sujet au sein de la boîte. Qui partagent son temps avec d'autres responsabilités, mais ça permet d'avoir un relais et régulièrement d'avoir l'IA dans notre quotidien. Il y a eu des outillages qui ont été mis en place au niveau de la boîte, des sensibilisations qui ont été mises en place au niveau de la boîte. De toute façon, je pense que ce n'est pas un sujet que tech. Et donc, comment dire non à la hype? On a fait des fois des compromis, des projets, on va utiliser un peu plus d'IA. D'autres fois, c'est un peu plus traditionnel, mais parce qu'on déroule des choses qui ont déjà été... Je ne sais pas, il n'y a pas de meilleure manière de faire, mais je pense qu'on peut toujours faire plus, mais ça demande un petit peu de temps d'exploration, de se tromper, de recommencer.

26:42 Puis comme les modèles évoluent vraiment très, très vite, il faut aussi avoir le temps de pouvoir comparer. Tu vois, quelque chose qui ne fonctionnait pas. Il y a trois mois, maintenant, des réponses complètement différentes. Écoute, je suis totalement d'accord avec toi. Et puis, le rôle de centraliser, en fait, chez quelqu'un ou une équipe. Moi, ce que j'ai fait, par exemple, chez Fondative, ici, on a une cellule qui s'occupe de… En fait, on a une R&D. Dans la R&D, il y a une cellule qui fait de l'IA. Et moi, la piste qu'on a empruntée, c'est de donner le cap par rapport aux choses, d'abord, qu'on ne veut pas faire. C'est-à-dire, il y avait des choses qui coûtaient énormément cher avant l'IA et qu'on ne pouvait pas faire. Par exemple, l'extrême programming. C'était un concept super bien, mais moi, je ne connais pas plusieurs CTO qui le font. Alors qu'on me dit que c'était efficace, moi personnellement je ne l'ai jamais pratiqué, je ne l'ai jamais réussi à le mettre en pratique tellement il coûtait cher. Aujourd'hui, tu peux utiliser ton assistant de codage comme quelqu'un avec qui tu extrins le programme.

27:45 Donc, tu peux implémenter ce concept et voir réellement ce que ça donne. Autre chose, par exemple, que les développeurs ne veulent pas faire, c'est documenter. Aujourd'hui, tu peux avoir une documentation exhaustive et qui font bien le job. Notre cas de figure, par exemple, les tests unitaires, pareil. Tu vois, on ne peut pas demander aux développeurs en même temps d'avancer vite, d'être exhaustif sur certains nombres de sujets et de garder vraiment leur implication là-dessus. Et donc, en tout cas, chez Fondative, on a orienté les choses vers ce qu'on ne veut pas faire, en fait. Parce que le développeur, il veut quand même coder. Ça l'anime, ça. Il veut le faire. Donc, on ne va pas lui piquer ça. De toute façon, ce n'est pas faisable. Aujourd'hui, l'état de l'art, ce n'est pas vrai. Et comme tu le dis, je suis d'accord avec toi, ça ne remplace pas le développeur. Et si tu prends du code qui est généré par de l'IA, sache que tu fais du legacy dès ta première ligne de code. On est d'accord là-dessus. Maintenant, tu peux être assisté pour faire mieux. Mieux, c'est-à-dire avoir des insights, avoir de la documentation, avoir des tests.

28:50 Ça va rentrer sur une technologie que tu ne maîtrises pas. Aujourd'hui, si tu as en face un truc qui est codé en COBOL, tu veux le faire en Python, tu peux te baser sur quelques plateformes agendiques pour pouvoir faire ça. Sur l'observabilité aussi, tu peux avoir des trucs prédictifs aujourd'hui sur des solutions comme Datadog ou Wattpad. Des choses prédictives qui vont te dire, attention, tu peux être en manque par rapport à ton espace d'ici quelques temps parce qu'il y a quelques patterns qu'il est en train de regarder sur les logs et toi que tu ne vois pas. Mais ça s'arrête là. En tout cas, pour le monde de l'informatique, ça s'arrête là. Donc, c'est bien. De toute façon, ça change notre façon de faire. C'est sûr. C'est là pour rester, c'est sûr. Mais on doit apprendre à faire avec, pas soit l'agent de codage, soit le développeur. Moi, je ne suis pas du tout dans cette optique-là. Il faut faire avec les deux. Le développeur doit savoir utiliser les agents. Ce n'est pas à faire l'un ou l'autre.

29:51 Je ne sais pas si tu es d'accord. Oui, je suis d'accord, c'est complémentaire. J'ajouterais aussi qu'en tant que développeur, on se plaint de faire… plein de choses rébarbatives, de faire du copier-coller, de revoir c'était quoi quel algo, ou des templates. C'est plus possible de se plaindre. Aujourd'hui, on a des outils IA qui nous facilitent la vie. On peut enfin se concentrer sur des choses à valeur ajoutée. Donc, il y a ça. Nous aussi, on utilise beaucoup. Les idées augmentées par l'IA pour générer des tests. Donc oui, ça, ça fait gagner du temps, c'est certain. Alors, il nous reste deux choses à voir. Je vois avec toi, surtout avec toi, les contraintes budgétaires et leurs impacts, parce qu'en fait, Et c'était d'ailleurs un sujet d'une des newsletters de Tech.Rocks. Il y a les contraintes budgétaires qui arrivent, la tendance à aller au downscaling, la tendance à aller au cut-off du budget. Mais on a de plus en plus d'attentes.

30:53 On attend de plus en plus de choses des techs. Sous tutelle de l'IA aussi qui va nous aider à faire des choses. Et on a dit que ce n'est pas le cas. Et donc, face à cette conjoncture-là, quels leviers t'ont permis à faire des vraies économies smart, je dirais, parce qu'il y a des économies qui ne servent à rien. Et est-ce que tu as eu à faire ça? Oui, clairement. Forcément, je repense au projet de migration cloud. Et on a dû mettre en place des pratiques FinOpt. Pour ça, les outils qui sont sur Azure, AWS ont beaucoup aidé, en tout cas à trouver les pistes d'optimisation. J'utilise un autre outil qui s'appelle CoStory et qui m'aide à avoir une vue agrégée, une vue que je peux partager avec mon directeur financier aussi, pour lui montrer l'avancement, est-ce qu'on est dans le rouge, est-ce qu'on n'est pas dans le rouge. Ça, c'est important, en fait. Et finalement, c'est partie de l'hygiène qu'on doit avoir. Donc, pas forcément dans une vue cut-off, mais plus de bien regarder au quotidien là où on dépense et trouver des pistes d'optimisation parce que ça peut vite s'enflammer.

32:00 Donc, ça, c'est pour la partie cloud. Je peux dire aussi que cette année, j'ai fait appel à beaucoup d'externalisation. Il y a eu des projets exceptionnels sur cette année. Et ça aussi, c'est des coûts que je regarde de près. D'abord, ça m'aide à identifier si finalement c'était que du projet ou si ça veut dire qu'il va falloir augmenter le staffing sur l'année prochaine. Parce que d'avoir des personnes à temps plein et que finalement, ils sont intervenus sur un peu tout et pas forcément que le projet phare, ça explique qu'on a besoin d'autres personnes. Puis forcément aussi challenger sur le nombre de personnes qu'on a dans les équipes. Et ce que j'explique, c'est que tous les efforts qu'on fait pour optimiser, par exemple, sur la partie qualité, production de tests, automatique, manuel, end-to-end, je pense que sans... Le travail de produire de plus en plus de testomatiques, d'augmenter cette couverture. En fait, on aurait dû augmenter aussi. le nombre de people, mais moi je ne veux pas qu'on augmente de manière linéaire, voire exponentielle, le nombre de personnes pour faire des choses qui peuvent être automatisées.

33:07 Donc on a réussi à maintenir une équipe qui n'a pas explosé en nombre de personnes, mais on a réussi à gérer plus de projets et plus de produits, de sous-produits et d'applications. Avec le même périmètre de nombre de personnes. C'est intéressant, mais écoute, est-ce que tu penses que tu as été aidé, je dirais, le temps comme ça, par le contexte général? Parce qu'avant, on avait du mal à faire passer ce message aux équipes, de leur dire qu'on ne va pas recruter, parce qu'on a beaucoup de travail à faire. Mais aujourd'hui, on peut se dire, regardez, il y a partout des contraintes budgétaires et on doit savoir faire mieux avec les moyens de bord. Est-ce que tu ne penses pas que ça a aidé? Quelque part. Oui, le contexte général aide parce qu'on ne se dit pas qu'on est les seuls dans le marché à essayer de réduire les coûts. Oui, je pense que ça aide parce que si on voit que toutes les sociétés embauchent à tour de bras et que nous, pas du tout, ce qui n'est pas le cas, on embauche quand même pas mal, mais nous, on voit surtout des sociétés qui s'arrêtent ou qui

34:19 divisent par deux leurs effectifs autour de nous et nous, ce n'est pas le cas. Je pense que ça, ça aide les équipes à se projeter, à rester chez les Monway longtemps, parce qu'on sait que... Le marché n'est pas forcément favorable en dehors. On a tous des problèmes de coûts, mais on essaie de les maîtriser pour ne pas en arriver à des extrêmes comme ça. Et de voir licencier la moitié des personnes. Très bien. Et donc, du coup, il n'y a plus de turnover. Ah si, il y a quand même du turnover. Il y a du turnover déjà parce que les gens, au bout d'un certain moment, ils veulent faire aussi une carrière. On n'est pas une très grosse boîte. On est moins de 200. Donc forcément, les évolutions carrières, malgré tout ce qu'on met en place pour faire de la mobilité interne, malgré ces dispositifs-là, ce n'est pas possible de proposer des opportunités à tout le monde. Donc, bien sûr, on fait attention à proposer des évolutions en interne, à recruter.

35:22 Mais des fois, ce n'est pas possible. Donc, il y a du turnover. Je ne dis pas qu'il n'y en a pas. Il y a eu aussi des sujets de sous-performance. Malheureusement, ça arrive. Quand il y a du turnover, il y a du turnover naturel aussi. Écoute, je pense qu'on a fait le tour de pas mal de sujets, Céline. Et j'espère qu'on a été utile, en tout cas qu'on comprend mieux pourquoi le CTO, le rôle du CTO n'a jamais été aussi stratégique ni aussi complexe. Et je propose de terminer sur un conseil pour les jeunes CTO qui nous écoutent aujourd'hui. Avec ton recul, quels conseils leur donnerais-tu pour affronter un nouveau monde, ce nouveau monde? Ça ne va pas être des conseils techniques, ça va être plus des conseils d'état d'esprit, des choses que j'aurais aimé entendre moi quand j'ai commencé. C'est rester bien dans l'observation et pas dans… dans la rapidité de se précipiter à faire des choses.

36:23 La résilience, ça m'a beaucoup aidée. De toute façon, ça change tout le temps. Donc, il faut savoir s'adapter aux changements. Sinon, tu es fin. T'es figé, t'avances pas. Et en fait, la vie, c'est ça. La vie, c'est tout le temps du changement. Et puis, on en parlait quand on avait préparé l'épisode, mais on était d'accord qu'il faut rester humble. En fait, on ne sait pas tout. Et le monde change en permanence. C'est ça que j'adore aussi dans mon métier, c'est que tous les jours c'est différent, tous les jours j'apprends, à la fois des technos qui évoluent, de l'IA qui change tous les mois, il y a un nouveau modèle, et puis aussi des personnes avec qui je travaille, tous les jours j'apprends. Et je pense qu'en ayant cette posture de curiosité aussi, ça aide ta carrière avancée, ça aide à prendre du recul et à prendre confiance en soi aussi. Super. Je note résilience, observation et rester humble. Merci beaucoup Céline. C'était un moment d'un grand plaisir, encore une fois, pour cet épisode, pour ces discussions.

37:31 On se retrouve tout le monde au Tech.Rocks Summit le 1er décembre 2025 au Théâtre de Paris. Pour ceux qui n'ont pas encore pris leur billet, je vous dis, c'est bien le moment. Si vous voulez qu'on se rencontre, moi j'y serai, Fondative sera, Céline j'espère aussi. J'ai prévu d'y aller aussi. Très bien. Donc, à très vite. Merci beaucoup Samir.