Gen AI & équipes tech : retours d'expérience et perspectives

0:03 Donc l'objectif, c'est quand même d'accélérer l'équipe et pas de générer de la dette technique à vitesse grand V. Et donc j'étais extrêmement frileux au début. Je vois aujourd'hui les high-cogen comme l'opportunité d'aller tester à moindre coût et de pouvoir avoir du feedback. Bonjour et bienvenue sur ce nouvel épisode du podcast Tech.Rocks. Je m'appelle Adnan Aita et je suis avec Thierry Abalea. Bonjour à tous. Pour vous expliquer un peu le contexte de cet épisode, nous avons gagné le jeu qui a été organisé lors de l'after work de Tech.Rocks le 10 avril dernier. Le jeu consistait à retrouver notre binôme avec qui nous avions trois challenges en commun. Il s'avère qu'on a été les premiers à reconstituer notre binôme avec ces trois enjeux. L'un était le fait qu'on a tous les deux travaillé en banque assurance, dont moi toujours actuellement. Nous sommes tous les deux entrepreneurs et on est tous les deux intéressés par la Gen AI, mais comme je suppose la plupart de ceux qui nous écoutent.

1:05 Je te laisse peut-être te présenter Thierry, ton parcours. Oui, ça marche. Je suis Thierry Abalea, j'ai 48 ans et ça fait à peu près 23 ans que je suis dans la tech. Pour brosser rapidement un peu mon parcours, j'ai bossé dans le conseil, j'ai fait 8 ans à la Société Générale en banque de finances, finances de marché, assez éloigné des expériences. En startup que j'ai vécu ces dernières années, mais très enrichissant, où j'ai découvert le goût du challenge. J'étais en gros technical leader, j'ai pas mal sur les technos à Java. Avant de commencer à travailler pour des startups en 2015. Ça fait 10 ans que j'évolue en startup. J'ai été CTO de deux petites startups, Fluo dans l'assurance, Crème de la crème, que vous connaissez peut-être, Marketplace de freelance. Et ensuite, j'ai travaillé pour des scale-up, Aircall, Telefonie, en tant qu'engineering manager. J'ai travaillé ici pour Alma, vraiment plusieurs fois. J'étais en gros VP engineering.

2:06 J'ai rejoint Alma en pleine croissance. Mes équipes sont passées de 8 à 90 personnes en l'espace d'un an. Très, très enrichissant. Et j'ai travaillé aussi pour Guide Guardian en VP Engineering, en cybersécurité. Et me voilà aujourd'hui fondateur et CEO de ShipFox, un developer tools autour de la continuous integration. On vient résoudre les problèmes qu'il y a autour de la CI, quand les équipes scellent des problèmes de performance, de fiabilité, de coût. Et donc, je change de casquette entre developer, engineering manager dans le passé, à CEO, où évidemment, c'est un produit tech. Et donc, j'échange beaucoup avec les techs, mais j'ai une casquette maintenant un peu sales et marketing entrepreneur. Voilà en gros qui je suis. C'est super. Et en fait, on a un profil. qui est assez proche parce que je ne suis pas tout jeune non plus. Je suis tombé dans la tech quand j'avais 6 ans, je suis sorti de l'EPITA en 2006 et je n'ai pas fait Société Générale, mais moi je suis allé

3:11 presque 10 ans chez BNP Paribas avec une coupure d'un an au milieu en tant que CTO pour faire des jeux sérieux et des réseaux sociaux d'entreprise 2009-2010. On était un peu tout saoul, on s'est lamentablement planté, mais c'était une belle expérience. Après BNP, j'ai voulu revenir à mes premiers amours qui étaient la tech, parce que finalement là-bas, je ne faisais pas vraiment de la tech. Et surtout, le statut du développeur avait changé, dans le sens où finalement, quand moi je suis sorti d'école, on voyait les développeurs un petit peu comme des barbus à mettre à la cave. On va dire le rapport de force a un tout petit peu changé. Je suis revenu dans la tech en tant que CTO d'une société qui s'appelle John Paul, qui faisait de la conciergerie privée, qui a été vendue à Accor. Je suis parti dans l'éducation en ligne pendant un an. Je suis parti chez un éditeur de finances de marché. On faisait des solutions complètes pour tout ce qui était asset management, depuis le passage d'ordre sur les marchés jusqu'à la comptabilité, avec tout ce qui se passe entre les deux.

4:14 Et puis, on a monté Sharelock avec mes deux associés, qui à la base avait pour mission de, enfin on a toujours cette mission-là, d'essayer de développer le vélo en milieu urbain, parce qu'on s'est aperçu que le frein principal était le vol et la peur du vol. Donc, on a un an. a voulu créer des infrastructures de s'assimiler sécurisé, sans génie civil, à l'échelle. Donc, on a développé ce produit-là. On a eu quelques petites difficultés avec les villes, mais on a eu quand même un gros déploiement à Nice pendant un an de 800 cadenas qui maillaient complètement le territoire. Et puis petit à petit, on a pivoté sur l'assurance vélo. Pourquoi? Parce que ça permet de se déployer directement partout en France sans infrastructure. Deuxièmement, le contexte de financement n'était pas vraiment en 2022 celui de 2010. Donc, il fallait quand même qu'on fasse un petit peu attention. Et troisièmement, c'était quelque chose qu'on avait déjà identifié, mais on ne s'attendait pas à ce que ça marche aussi fort. Et donc, en courant 2023, fin 2023, on a complètement pris le côté pour ne faire plus que de l'assurance vélo.

5:16 Alors, on a toujours les cadenas dans un bel entrepôt. Prêt au cas où il y a une ville qui se motive à déployer pour pas cher une infrastructure de stationnement vélo. Mais pour l'instant, on se concentre surtout sur l'assurance et pour assurer la survie et le développement de la boîte dans le futur. On avait envie avec Thierry. De parler de développement et de Gen AI. Pourquoi? Parce que c'est l'un des sujets, on va dire, chauds du moment. Je pense qu'il dépasse un peu la hype qu'on a pu voir sur ces 20 dernières années. Il y a eu la hype du big data, il y a eu la hype de l'ubérisation, il y a eu la hype de pas mal de choses. Mais j'avoue, moi, depuis 20-25 ans, c'est la première hype où je me dis, OK, ce n'est pas juste une hype, il y a vraiment une transformation qui est en train de se passer. Oui, peut-être pour préciser, parce qu'effectivement, les AI, c'est un sujet qui intéresse beaucoup de monde, nous en particulier. Les AI, c'est assez vaste, on peut le voir au niveau produit, comment on va utiliser les AI au niveau du produit, comment on peut utiliser les AI en termes de productivité.

6:28 Et c'est un peu là-dessus qu'on souhaite se focusser. Mais productivité au niveau des équipes produits, ingénierie, donc comment l'AI, code generation, comment l'AI transforme un peu le métier de développeur, de product manager, de tech leader, c'est l'idée. Et peut-être du coup, alors pour commencer, l'idée serait de discuter un petit peu de nos usages actuels. DI, est-ce que tu peux nous dire quel usage tu en fais dans tes équipes chez Sharelock? Peut-être aussi la taille de l'équipe tech? Alors nous, on est tout petit. L'équipe tech, c'est moins de 10 personnes, incluant toutes les fonctions connexes, UI, UI, product, tester et compagnie. Donc, on est vraiment tout petit aujourd'hui. Les AI, enfin la Gen AI plutôt, on est tombé dedans, ça fait un an et demi. Donc, on y allait à tâtons, on cherchait, on expérimentait des choses.

7:28 Mais c'est vrai qu'il y avait toujours cette... Cette insatisfaction. Et puis, j'ai été aller à l'événement qui était organisé chez Datadome, où il y a notamment Pierre Vannier et Gilles Walbro qui ont parlé un peu du sujet. Je me suis dit, OK, on va refaire des tests, on va se remettre dedans. Et là, j'ai été assez impressionné par l'évolution que ça a eu finalement en six mois, un an. Et la capacité où il y a finalement un an, Le code généré ou le travail effectué par la GNA était assez médiocre et souvent, au final, on avait cette dichotomie de se dire, est-ce que j'ai vraiment gagné du temps ou pas ? Autant maintenant, le gain de temps est assez évident, même si de temps en temps, ça part un petit peu en… sur la tangente, la diagonale, je ne sais pas comment on dit. Mais là, le gain de temps est clairement perceptible. Et donc, on s'est mis à cursor. Dans les équipes, il y en a quelques-uns qui sont sur copilote.

8:29 Même si officiellement, je leur ai dit que non, ils n'avaient pas le droit. On sait que les équipes font quand même un peu ce qu'elles veulent et je suis content qu'elles expérimentent quand même des choses. Mais aujourd'hui, on est principalement quand même sur Cursor et je suis en train petit à petit de border l'équipe. Et pour moi-même, j'ai fini par m'installer deux machines et je fais des allers-retours entre les deux machines à leur donner des promptes. Donc, c'est assez surprenant ce que c'est capable de faire. Est-ce que tu peux nous expliquer pourquoi tu as mis un peu quelques contraintes ou interdit un certain nombre de choses? Quel était l'objectif? En fait, l'un des trucs que je me suis rendu compte quand je m'y suis mis, c'est que la courbe d'apprentissage pour maîtriser ces outils est loin d'être évidente. L'idée, c'est quand même que l'outil permette de créer du code rapidement en respectant toutes les contraintes qui sont déjà en place, que ce soit de l'inting, de règles de développement, manière de faire les choses, de sécurité, de ceci, cela. Donc l'objectif, c'était quand même d'accélérer l'équipe et pas de générer de la...

9:30 d'être technique à vitesse grand V. J'étais extrêmement frileux au début et j'ai voulu jouer moi-même pour apprendre, définir correctement les règles, ces espèces de métapromptes qui viennent se rajouter automatiquement aux promptes pour essayer de cadrer un peu la Gen AI, de jouer un peu avec tout ce qui est MCP pour essayer de choisir les bons, voire d'en mettre un ou deux. Un tout petit peu custom pour aider, mais l'idée c'était de se dire Quand on y va de manière plus ou moins officielle, que l'outil, finalement, le gros du learning soit déjà absorbé et donc qu'on puisse gagner tous du temps au lieu de tous collectivement faire notre apprentissage de notre côté. Alors oui, ça a des inconvénients, mais étant donné qu'on était une toute petite équipe, je ne pouvais pas vraiment dire... Allez, on passe là-dessus et on ne fait rien d'autre pendant six mois parce que j'avais quand même un peu cette peur de me dire qu'on va perdre beaucoup de temps finalement à effectuer cet apprentissage.

10:32 Quand on est dans une toute petite boîte, il faut assurer le delivery, il faut que ça sorte là maintenant, les clients n'attendent pas, les besoins n'attendent pas. Donc, il y avait ça, mais là, petit à petit, on s'y met. Et tout le monde est quasiment opérationnel dessus. Est-ce que tu as toujours difficile à estimer le gain de productivité? Parce que je suppose que tu ne mesures pas précisément. C'est difficile à mesurer la productivité, mais si tu devais en pourcentage un peu te dire combien ça a accru en termes de... production, alors évidemment pas juste, notre but c'est pas de produire du code, mais de produire de la valeur, est-ce que ces game changeurs, est-ce qu'ils ont doublé de productivité, un peu moins? C'est compliqué parce que c'est pas capable de tout faire. Si j'avais à faire une estimation aux doigts mouillés, je pense qu'on serait aux alentours de 30% peut-être, ce qui est déjà énorme en soi, mais... Ce qui est déjà énorme en soi, mais ce qui est déjà énorme en soi, qui n'est peut-être pas ce qui est vendu entre guillemets dans les papiers que je peux lire.

11:34 Je pense qu'effectivement, 30% est un chiffre qui me paraît à peu près raisonnable. Le truc qui a changé, c'est que sur peu de choses, on gagne énormément de temps. Par exemple, tout ce qui est test unitaire, améliorer la couverture fonctionnelle, améliorer la documentation in-app pour la génération de documentation de SDK, ce genre de choses. Sur certains problèmes un peu spécifiques, sur des upgrades de version, de package, pour passer finalement et gérer les régressions qu'il pourrait y avoir. Tout ça, la Gen AI est assez forte et nous a fait gagner un temps phénoménal. Sur le développement de nouvelles fonctionnalités, sur des toutes petites choses, ça le fait assez bien. Sur des sujets un peu plus complexes, on n'a peut-être pas encore complètement dompté l'outil. Pour être capable de lui faire faire tout ce qu'on voulait. Ok, si ça te va, je peux te dire aussi un peu quel est l'usage chez Fox. On est une jeune startup avec peu de monde.

12:35 Il y a encore un mois, on n'était que tous les deux, mon cofondateur, CTO et moi-même. Moi, ça fait quand même de nombreux mois que je ne suis plus amené à coder. J'ai codé un tout petit peu au début. Et de mon côté, j'ai utilisé pas mal ChatGPT avec un certain succès. Évidemment, c'était assez variable selon ce que je voulais faire. Mais je ne pense pas que j'avais un gain de productivité non plus. effarant. Difficile à quantifier, mais effectivement, peut-être 20-30%. Du côté de Noé, qui développe la majorité du code, je sais qu'il utilise pas mal Copilot, en mode vraiment un peu completion on stéroïde. Donc là, il y a un gain. Un gain certain pour aller plus vite, mais quand même, la majorité du code est pensée par lui et non par les highs. Donc, il est assez plus de la complétion. La génération de tests, qui l'utilise beaucoup, est assez performante là-dessus.

13:35 Et là, depuis peu, il teste un peu Cursor. D'après le retour qu'il me fait, il faut le configurer. Il y a la notion de rules dans Cursor pour vraiment bien profiter. Et je pense qu'étonnamment, alors qu'on est une boîte tech for tech, on utilise encore assez peu les AI. Je pense qu'on va intensifier dans les mois à venir notre usage de l'AI. Là, on a parlé pas mal des techs. Comment tu vois en termes de product management? Parce que développer du produit, ce n'est pas juste développeur. Comment vous avez des PM chez Sharelock? Comment tu vois l'impact de l'AI là-dessus? Alors moi, je n'ai pas de PM. Et idéalement, si je pouvais rester dans une structure où je n'en ai pas, si on y arrive, je serais très content. Dans la pratique, c'est un vieux... parce qu'au bout d'un moment, il faut quand même avoir besoin d'organiser les choses. Aujourd'hui, les tâches du produit sont disséminées dans les équipes

14:43 opérationnelles, que ce soit le support client, que ce soit les sales, que ce soit les gens qui conçoivent les produits d'assurance, qui traitent les sinistres, etc. L'idée, c'est quand même qu'eux puissent dire chaque semaine, c'est quoi mon problème principal. Et est-ce que vous pouvez me dire, régler mon problème principal. Et aujourd'hui, soit le développeur va directement comprendre le problème et essayer d'adresser le problème en discutant avec lui. En ce sens-là, on essaye de reprendre un peu le manifeste agile. Il y a des avantages, c'est que ça fluidifie et effectivement, comme il n'y a pas de planification long terme, ça permet d'être agile dans le sens où finalement, si on était parti dans une direction, on peut très rapidement shifter pour partir dans une autre direction pour corriger le tir. Ça a des inconvénients, c'est que parfois, on produit quelque chose et finalement, on se rend compte que ce n'était pas la bonne chose à faire, etc. Mais je trouve que le temps perdu en créant ce« waste» nous fait perdre moins de temps que s'il fallait systématiquement tout cadrer en amont, tout anticiper en amont.

15:49 Parce que même en anticipant d'expérience, il y a parfois où on se trompe et où on se rend compte que ce n'est pas la bonne chose. On n'a pas vraiment de PM. Je rêve quand même de pouvoir, parce que mon UQI est en maladie et j'ai hâte qu'elle revienne, pas parce que j'ai envie qu'elle bosse, mieux vaut qu'elle se repose quand on est malade, mais parce que j'ai envie de voir justement à quel point la Gen AI pourrait l'aider dans son travail. Que ce soit pour la génération de maquettes, pour essayer de faire de l'adaptation là-dessus, essayer d'uniformiser un certain nombre de choses. Je suis assez curieux de voir qu'est-ce que ça pourrait donner. J'ai un remboursement. Remarquez quand même qu'on pouvait, je ne sais pas si c'est le cas, je n'ai pas testé avec Copilot, mais j'ai testé avec Cursor, on peut lui donner des images et des exemples de bases de code existantes. Et il est capable de finalement matérialiser sous forme de code le rendu de la maquette, ce qui est assez impressionnant. Alors, ce n'est pas toujours parfait, parfait, mais à 80%, ce n'est pas trop mal pour les sujets qui ne sont pas trop complexes.

16:54 Donc ça, ça a quand même un impact. Là où on se sert aussi pas mal du Gen AI, c'est pour les documentations finalement qu'on est obligé de mettre à jour. L'assurance, c'est un secteur réglementé. En plus, quand on est une startup et qu'on fait aussi pas mal d'innovations, on essaye de remplir un certain nombre de dossiers et de documentations. Et c'est vrai que là-dessus, Gen AI nous aide aussi à documenter et à écrire un certain nombre de documents. Pareil pour les documents de sécurité, pour passer notamment, on est en plein process pour passer ISO 27001. Ça nous aide à faire une première passe pour voir, ah tiens, on a oublié de documenter ci, on a oublié de documenter ça, ou pour générer une partie d'exemple pour gagner du temps, ou pour pointer des dysfonctionnements. C'est assez puissant, en même temps, on est toujours insatisfait, c'est-à-dire qu'on est amazed quand ça marche bien et on est toujours frustré quand ça ne marche pas. Mais c'est bien le signe qu'on en devient petit à petit dépendant.

17:56 Je pense que l'idée, c'est de découvrir là où ça fonctionne. On est bien et du coup, de maximiser l'usage de l'AI là-dessus. Peut-être de faire de la veille sur là où ça marche. Est-ce qu'il n'y a pas des moments où tu t'es dit ça ne va pas marcher et finalement, ça t'a surpris et ça a marché quand même? Oui, je ne peux pas dire quotidiennement, mais peut-être toutes les semaines, j'arrive à être surpris par l'AI. Je tente beaucoup. Je ne l'ai dit pas sur le code, mais in fine, j'ai quand même à produire des documents, des messages, des mails, des présentations. Et effectivement, il y a parfois où il se plante totalement, parfois je suis assez sceptique sur le fait qu'il va y arriver, et il arrive à produire. Ce qui est important surtout, c'est le prompt, l'expression de ce que tu attends, la qualité de ce qui sort. Est quand même dépendante de la qualité de ce que tu as en entrée de ton prompt. Ça, c'est important. Nous, sur le product management, on est un peu comme toi, dans le sens qu'on a une petite équipe et on n'a pas de product manager.

19:02 Le produit est aussi tech for tech, on fait un outil de CI et donc on est, comment on va dire, on comprend assez intimement la problématique que rencontrent les développeurs, on échange pas mal avec des techs là-dessus. Mais in fine, du coup, on a cette casquette un peu de, on fait du product management. L'idée est de comprendre les enjeux, les besoins et de les restituer, comment on va dire, et d'identifier. À des solutions, produits, tech. Du coup, on va être amené, on utilise pas mal Notion, et de faire des products PRD, product definition. Et écoute, la partie AI de Notion est assez bluffante. Et du coup, on va exprimer vraiment qu'est-ce qu'on a compris des problèmes, Quelle est la solution envisagée, les alternatives rejetées? En donnant ça en prompt, tu vas quand même avoir un document bien structuré. Évidemment, tu as toujours… Un peu à éditer à droite à gauche, mais ça permet quand même de pas mal avancer sur le PRD.

20:07 Tu le sais, les techs, ils n'aiment pas beaucoup produire de la doc. Ça permet d'accélérer là-dessus. Je pense que dans le futur, on sera amené à recruter des PM extrêmement tech. Pour moi, le PM, c'est quand même celui qui est au contact des utilisateurs. Quand l'équipe grandit, ça peut être difficile pour les développeurs de rester encore à ce contact-là. C'est quand même de faire le tri, la discovery. Et je pense que les AI, évidemment, peuvent aider beaucoup. J'ai vu, il y a Mistral AI qui, en gros, face à un meeting, ils enregistrent le meeting avec Dev, plusieurs PM. Et en gros, ils ont une sorte d'agent basé sur le chat et Jupyter Notebook, où ils vont en gros pouvoir donner ce transcript. Et ça va derrière leur produire un document, un PRD, des tâches qui vont être alimentées linéaires.

21:11 Après, je m'attends à ce que derrière, il peut y avoir quelques hallucinations et qu'il faille retravailler, mais je pense que ça peut accélérer quand même ce travail qui est fastidieux entre un échange, que ce soit avec les utilisateurs ou sur l'équipe, sur le produit, pour cadrer. Moi, j'ai un peu peur de ça parce que... Autant sur quelque chose qui est customer facing et qui n'est pas réglementé, S'il y a une légère imprécision du fait de la mauvaise interprétation de l'AI, ce n'est pas trop grave. Dans l'assurance ou même dans d'autres secteurs, la banque, dans tout ce qui est potentiellement réglementé, une petite imprécision, ça peut avoir des impacts assez massifs. Et j'avoue, aujourd'hui, je n'en suis pas encore à me dire, pour en tout cas des features qui concernent directement cette partie-là réglementée, que ce soit la souscription, la gestion de sinistre par exemple, je suis un peu frileux. Par contre, on est en train d'expérimenter effectivement les curseurs mode qui sont

22:14 arrivés il n'y a pas très longtemps, mais il y avait l'équivalent sur des systèmes comme Crow AI ou ce genre de choses qui permettent un peu de spécialiser certains agents pour typiquement générer du PRD, faire de l'estimation de complexité des tâches dans le PRD. Parce que nous, on ne fait pas en tant que développeur, parce que je trouve que perdre du temps à faire des estimations, c'est un peu dommage. Mais quand c'est l'AI qui le fait à la vitesse où elle le fait, en fait, le coût, il est marginal. Ça peut être intéressant pour justement pousser l'AI à redécouper ce qu'elle juge elle-même comme trop complexe et pour créer des feedback loops entre l'agent développeur AI et un agent PM AI avec le développeur qui dit« Ah ben non, là, j'ai pas…» assez d'éléments là-dessus. Pour l'instant, je suis un peu déçu du résultat, mais je me dis qu'il y a de fortes chances qu'on s'oriente quand même à terme vers ce genre de choses où finalement le PM et le développeur sont merdes en une seule fonction, tech, où finalement le dev se retrouve comme un orchestrateur d'agents.

23:22 Et un reviewer pour vérifier quand ça ne va pas, parce que mine de rien, il y a quand même un paquet de fois où l'IA, par exemple, l'infini, a essayé de s'autocorrect la même chose, et parfois, c'est un fail. Je suis assez convaincu, en fait, que ça va être vraiment cet outil-là, c'est-à-dire que ça va être, au lieu d'avoir un PM et cinq développeurs, il va y avoir... Un PM développeur et basta cosi. Ok, ok, intéressant, c'était un peu le sujet suivant du futur, comment tu vois le futur du développement. Et donc, en gros, certains prédisent qu'il n'y aura plus de développeurs. Toi, tu dis qu'il y aura toujours des développeurs, mais ils seront moins nombreux. C'est ça, mais c'est que dans la révolution industrielle, si tu veux, dans le début du 19e siècle, opérer une ferme, c'était des centaines de personnes pour faire pousser du forage, nourrir les chevaux, labourer la terre, etc. Et aujourd'hui, une ferme, c'est quelques personnes et beaucoup d'outillages. Pour assurer la production. Et je pense qu'on va être dans un système similaire où finalement tous ces outils, même s'ils sont relativement imparfaits, mais qui vont continuer à s'améliorer dans l'avenir,

24:30 vont être là pour supporter un nombre beaucoup plus restreint de personnes qui produisent et dont le job principal va évoluer, c'est-à-dire qu'il ne sera plus de labourer manuellement la terre, mais ils vont être de s'occuper à réparer le tracteur, donc à s'assurer que l'IA travaille correctement, à« tuner» l'IA, rajouter des règles, rajouter des systèmes de contrôle, mettre en place des feedbacks automatiques, ce genre de choses, pour finalement... entretenir la machine qui va se retrouver à produire. Alors, il faudra une compétence technique, il faudra sûrement un certain nombre de connaissances, y compris des connaissances qu'on n'a pas aujourd'hui et qu'il va falloir acquérir, mais il y aura toujours des développeurs. C'est juste qu'il y en aura besoin, je pense, beaucoup, beaucoup, beaucoup, beaucoup moins. Alors, il y a une deuxième hypothèse qui est de dire, non, en fait, il y aura besoin toujours autant de développeurs, c'est juste qu'on va produire 400 fois plus. Je ne suis pas super convaincu par cette hypothèse, parce qu'il y a quand même finalement le pourquoi on produit, qu'est-ce qu'on fait, à quoi ça sert.

25:33 Et je suis assez dubitatif de me dire que les nouveaux usages qu'on va devoir créer vont dépasser finalement ceux qui vont disparaître. Oui, sur cette partie-là, sur le fait d'aller produire beaucoup plus, je pense qu'on testera le développement logiciel. L'un des enjeux, c'est d'avoir du feedback rapide. Et on est quand même, le développement logiciel est très limitant. Coder, ça prend énormément de temps. Et si tu veux tester des hypothèses, avant les AI, on va dire, ça coûtait très, très cher. Je vois aujourd'hui les AI Cogen comme l'opportunité d'aller tester à moindre coût, pouvoir avoir du feedback. On voit déjà des product managers, certes avec un profil assez tech, mais qui vont se retrouver à utiliser du curseur et commencer à pouvoir produire une fonctionnalité ou modifier une fonctionnalité. fonctionnalités sans l'aide des développeurs et de pouvoir mettre ça en gros dans les mains de quelques utilisateurs et d'avoir du feedback.

26:37 Donc je pense qu'au final, évidemment, le but, ce n'est pas de produire cinq fois plus de fonctionnalités, mais c'est peut-être de tester à moindre coût. Et puis, il y a des choses qui vont effectivement sûrement être écartées. Et puis peut-être où les devs vont devoir reprendre, parce qu'à un moment, il faut m'en tenir ça. Ce qui est produit sans trop regarder, je pense qu'un PM qui produit, qui utilise Cursor, va très peu s'attacher à ce qui va être produit, à la structure, à l'architecture, là où un dev va vouloir probablement guider un peu plus les highs pour avoir quelque chose de moins simple. Mais est-ce qu'on n'avait pas déjà la même chose avec le no-code finalement? Et c'est juste que c'est l'étape suivante, mais avec les mêmes vis finalement que le no-code? Peut-être la différence, c'est effectivement le no-code, tu pouvais l'utiliser, mais c'était quand même un outil très à part. Il ne s'intégrait pas avec l'existant. Aujourd'hui, avec des windsurf et des cursors, tu peux travailler avec une base de données existante. Donc en gros, le PM, il n'a pas besoin de se dire, tiens, je fais quelque chose de totalement à côté. Je m'inscris un peu avec les technologies de l'équipe et je suis capable de produire des choses qui s'intègrent bien.

27:41 Tu es d'accord que tu veux intégrer du no-code et une base de code existante? C'est un challenge. Là, au moins, tu pars sur une même base, les mêmes technos, du code in fine, mais tu as des outils qui permettent d'être à un plus haut niveau. Oui, je ne sais pas. Quand je prends du recul, le no-code avait énormément d'avantages de pouvoir… Effectivement, beaucoup pour les interconnexions, mais pas que. Pouvoir faire beaucoup de choses assez rapidement. Et je trouvais que le travers principal, Tout le débat standard de ça, en no-code, on ne peut pas le faire parce qu'il faut rentrer dedans, parce que ce n'est pas prévu, parce que l'outil ne le prévoit pas. Moi, le problème principal que je constate au no-code, c'est qu'en fait, la plupart des gens qui en font oublient de gérer tous les cas limites, de rendre la chose complètement résiliente. De nettoyer un peu ce qui devient obsolète dans le temps. Et donc, les outils no-code, finalement, je trouve, périment un peu plus rapidement que les bases de code existantes parce que finalement, la rigueur nécessaire à la maintenance

28:45 là-dessus est assez vite catastrophique. Donc, souvent, les organisations commencent par bootstrapper du no-code. Et finalement, à terme, le no-code se retrouve maintenu par les développeurs. Et je pense que ça va être un peu la même tendance peut-être là-dessus aussi. C'est-à-dire que oui, certes, il y aura peut-être des non-techniques qui vont générer des choses à gauche, à droite, mais si on ne veut pas que ça périme extrêmement rapidement, sachant que ça va encore augmenter le cycle des itérations, Il faudra être extrêmement attentif à s'assurer à ce que les équipes techniques reprennent finalement assez rapidement la main dessus pour uniformiser, pour gérer les cas limites, pour rendre le système résilient. Je te propose qu'on conclue. Je vois l'horloge tourne. Est-ce que tu aurais... Une ou deux recos à faire sur ce sujet-là, nos auditeurs ? N'attendez pas. C'est-à-dire que plutôt que de laisser le train passer et de se dire« tiens, je vais aller prendre le vainqueur dans six mois, dans un an, dans deux ans, et comme ça, j'aurai gagné du temps dans l'expérimentation», je trouve que l'impact que ça peut avoir sur une organisation est trop important.

29:49 Parce que même si on dit« ok, c'est que 30%, 30% finalement, on est déçu, mais 30% c'est colossal en termes d'augmentation de productivité, mine de rien. Ça veut dire que pour... trois personnes quasiment, ça évite une quatrième. Donc c'est vraiment très important. Sans compter que je dis trois personnes, ça évite une quatrième, mais c'est même pire que ça parce que finalement, comme il y a un rendement décroissant au fur et à mesure qu'on rajoute des gens, là, on a moins ce sentiment-là de rendement décroissant parce qu'on peut garder des plus petites équipes et avec des cycles de communication beaucoup plus courts. Vraiment, n'attendez pas. Le deuxième point, et après je te laisse la main, c'est une phrase en anglais, mais c'est« raise the bar, do not lower it». C'est-à-dire qu'en gros, l'outil vous permet de faire plein de choses. L'idée, c'est d'en profiter pour vraiment monter la qualité logicielle, d'en profiter pour monter sur tout un tas de sujets qui peut-être étaient… négligé auparavant en mode, ça, on n'a pas le temps, ça, on n'a pas le temps, ça, on verra plus tard. Oui, là, avec l'IA, ça ne coûte pas plus cher finalement de gérer peut-être un paquet de choses en termes de qualité logicielle.

30:56 Donc, profitez-en pour monter la qualité logicielle, même si… vous n'avez pas forcément d'impact direct sur la future euro qui, tout d'un coup, du jour au lendemain, est magique et sublime. Si déjà, ça vous permet, dans le code que vous produisez au quotidien, de monter la qualité logicielle, faites-le. Ok, top. Moi, de mon côté, le conseil que je ferais, c'est... Vous, en tant que tech leader, testez, explorez, même si vous ne vous codez plus, ce n'est plus votre rôle. Peut-être même que vous avez laissé le code il y a un bon moment. Explorez, il y a pas mal de choses. outils, Cursor, Winsurf, Flowable, Vizero de Vercel. Essayez d'explorer un tout petit peu, histoire de comprendre, d'avoir des discussions intéressantes avec vos équipes. Et j'ai envie de dire aussi, essayez d'embarquer les autres membres des autres équipes, autres que la tech et le produit, que ce soit, je ne sais pas, le CFO, le CEO, et d'organiser peut-être une sorte un peu de petit hackathon pour leur faire explorer.

32:00 Je pense que c'est intéressant qu'ils voient qu'est-ce qui est possible avec les AI, notamment sur de la production de code, les limites, les hallucinations, histoire que ça ne reste pas juste, comment on va dire, avec pas mal de fantasmes et d'inquiétudes ou d'attentes de productivité démesurées. Donc, embarquer du monde à explorer le sujet. Surtout qu'ils sont exposés au full bullshit qu'ils entendent sur LinkedIn ou à gauche à droite, sans trop de recul par rapport à tous ces sujets-là. Donc, oui, je trouve que c'est un super bon conseil. Top. Eh bien, écoute, merci à toi. Merci à Tech.Rocks de nous avoir offert un peu cette tribune pour parler de ce sujet-là. Et j'espère que ça vous a plu. A bientôt. A bientôt.