Plonger dans les coulisses du rôle de Developer Advocate

0:03 La partie, je dirais, un peu visible de l'iceberg, c'est le côté communiquant parce qu'effectivement, on va à des conférences, on présente des sujets, on peut créer aussi des ateliers, etc. Mais derrière, le socle de ces présentations, de ces démos, de ces ateliers, etc., il faut de solides bases techniques. On va être des développeurs augmentés grâce à ces agents de codage. Et je pense que c'est aujourd'hui qu'il faut s'y préparer parce qu'ils vont être partout. Bienvenue dans un nouvel épisode de notre série thématique dédiée à nos speakers de notre prochain Tech Rock Summit qui se tiendra les 1er et 2 décembre 2025 au Théâtre de Paris. Je suis Philippe Ensarguet, VP Software Engineering chez Orange et aujourd'hui j'ai la chance d'accueillir Guillaume Laforge, Developer Advocate chez Google Cloud. Guillaume, ce que je te propose c'est peut-être de commencer par te présenter et comprendre ton parcours.

1:04 Je suis sûr que ça sera très instructif pour nos auditeurs et nos auditrices. Tout d'abord, peux-tu peut-être te présenter en quelques mots? Eh bien, déjà, merci de m'avoir invité. Je suis content de pouvoir vous rejoindre sur Tech.Rocks. Ça va être ma toute première fois. Et donc, comme tu l'as dit, je m'appelle Guillaume, je suis Developer Advocate chez Google Cloud depuis maintenant 9 ans déjà. J'ai un parcours à la base de développeur Java, d'ailleurs. J'ai toujours utilisé Java pendant toute ma carrière. Je suis passé par différents types de rôles de développeur, architecte, consultant, chef de projet, product manager, développeur advocate. J'ai fait un petit peu... En tout cas, pas mal de rôles un petit peu différents. J'ai beaucoup travaillé aussi dans les communautés open source de manière générale et j'ai passé beaucoup de temps sur un projet qui s'appelle Apache Groovy, un langage de programmation qui est un langage qui est compatible, qui tourne sur les machines virtuelles Java.

2:07 C'est, je dirais, au travers de cette expérience-là où j'ai fait beaucoup de rencontres, beaucoup appris et ce qui m'a permis après plus tard de rejoindre Google. Et chez Google, je me suis toujours intéressé à tout ce qui était développement d'applications, déploiement, architecture, tout ce qui est orienté événement. Et puis aussi depuis un peu plus de deux ans et demi, tout ce qui est Generative AI, IA générative en français. Et ça m'a permis aussi de refaire même de l'open source, d'ailleurs, parce que je contribue à un projet qui s'appelle Longchain 4G. C'est pareil que Longchain pour Python, mais pour Java. Donc les développeurs Java sont contents. Et aussi un autre framework, cette fois-ci de Google, qui s'appelle ADK, Agent Development Kit, qui permet de créer des agents en Java, les déployer, etc. Merci Guillaume pour cette introduction. Et d'ailleurs, j'en profite pour partager l'excellent blog que tu tiens avec des publications de très, très grande qualité.

3:10 Et je les adore parce qu'elles sont très en zone. Et moi, elles me permettent de pouvoir activer pas mal de démos. Je suis sûr que tu pourrais nous indiquer le nom du blog pour ceux qui seraient curieux. Tout à fait. C'est jelaforge.dev. Donc, c'est assez facile à retenir. J'ai la première lettre de mon prénom, Laforge.dev. Et effectivement, j'essaie de partager régulièrement. Idéalement plusieurs fois par mois. Dans les articles. Et c'est vrai que c'est là que j'ai essayé de partager en tout cas ce que j'ai appris avec les développeurs, avec mes lecteurs. J'aime beaucoup ça, pouvoir partager. Une question que j'aimerais te poser par curiosité, en fait, en tant que developer advocate, comment est-ce que tu décrirais ton rôle au quotidien? Est-ce que finalement, c'est plus de la technique, de la communication, un mélange des deux? Parce que finalement, derrière cette notion de developer advocate, il peut y avoir plusieurs interprétations. Tout à fait. Alors, il y a clairement deux points super importants, donc la technique, bien sûr, et effectivement, comme tu dis, la communication.

4:16 La partie, je dirais, un peu visible de l'iceberg, c'est le côté communiquant parce qu'effectivement, on va à des conférences, on présente des sujets, on peut créer aussi des ateliers, etc. Mais derrière, le socle de ces présentations, de ces démos, de ces ateliers, etc., il faut de solides bases techniques et donc développer, explorer les sujets, les outils, les frameworks, les plateformes qu'on utilise. Donc, il faut être très, très bon côté technique. Chez Google, c'est vraiment un rôle d'ingénieur. Je sais que dans certaines sociétés, parfois, les développeurs advocates, on les retrouve des fois attachés à la fonction marketing. Chez Google, ce n'est pas vraiment partie de l'engineering. L'autre partie qu'on ne voit peut-être pas, je disais la partie visible de l'iceberg, dans la partie invisible, celle qui est sous la ligne de flottaison, c'est aussi le fait qu'on est en première ligne, en tout cas pour tester, développer les nouveaux produits, les nouvelles fonctionnalités.

5:19 Donc, on est un peu le bêta-testeur, le client zéro, qui allons tester des nouvelles choses qu'on va développer. Par exemple, j'ai travaillé, tout à l'heure, je te parlais du framework ADK pour créer des agents IA, qui sont en Java. Moi, je me suis focalisé avant le lancement, lors de Google I.O., le lancement de la version Java. On avait annoncé la version Python un petit peu plus tôt à Google Cloud Next, les deux grands messes de Google. Et en fait, j'avais participé au développement, à la préparation de ce framework avant qu'il soit sorti. De même, quand c'est… Donc là, c'est de l'open source, mais quand on a des nouvelles fonctionnalités de produits, par exemple, j'ai bossé pas mal il y a 2-3 ans sur Workflows, Google Cloud Workflows, ou sur Cloud Run, sur les Cloud Functions aussi, tout ça sur Google Cloud. J'étais dans ceux qui testaient, donnaient du feedback, il y a une partie aussi intéressante dans notre rôle de développeur advocate.

6:21 En fait, on est advocate pour les utilisateurs qu'on représente, pour les développeurs, c'est-à-dire que peut-être que je vais discuter un événement, rendez-vous client ou autre avec des développeurs qui vont dire ah oui mais comment je peux faire ça j'aimerais bien qu'il y ait telle fonctionnalité dans ce produit donc l'idée c'est aussi d'essayer d'influer sur la roadmap des produits, des services et des projets open source auxquels on contribue. Qu'est-ce qui t'a conduit à devenir Developer Advocate chez Google Cloud? Alors, ce qui est amusant, c'est que c'est vrai que ça fait longtemps que je fais le genre de choses que font les développeurs advocates, sans que, à l'époque en tout cas, sans que ce soit mon rôle en soi. Par exemple, à l'époque où je travaillais beaucoup, là je suis beaucoup moins impliqué dessus, mais à l'époque où je travaillais sur le projet Groovy, le projet open source, moi ce que je voulais c'était aussi promouvoir ce projet et le présenter aux développeurs. Donc j'allais à des conférences, j'écrivais des articles, etc. Qui est la partie très communiquante du rôle de développeur advocate.

7:23 Donc, j'ai toujours eu cet aspect communiquant d'essayer de promouvoir les choses auxquelles je crois, sur lesquelles je travaille. Il y a aussi l'aspect, bien sûr, l'aspect technique, c'est-à-dire de développer, de travailler sur tous ces projets, ces produits, etc. Et puis, un jour, en fait, s'est présentée l'opportunité. Je connaissais quelqu'un depuis longtemps dans l'écosystème Java qui avait rejoint Google et qui m'a dit, mais en fait, ce que tu fais, toi, pour les différentes technologies que tu représentes, c'est un boulot de développeur d'avocat. Et chez Google, à ce moment-là, il y avait un peu... de développeur advocate et il m'a dit tu ne veux pas en faire ton métier parce qu'en fait tu te débrouilles bien et c'est comme ça que j'ai rejoint Google pour faire développeur advocate Écoute Guillaume, quand on t'écoute, on sent déjà beaucoup de passion, on sent énormément de curiosité, un besoin d'exploration, mais en même temps de rationalisation et de pragmatisme. Et en fait, ça me conduit à la question suivante qui me tient vraiment à cœur, c'est qu'est-ce qu'il y a des moments ou des rencontres ou des découvertes particulières qui finalement,

8:36 dans ton histoire professionnelle, ont été des moments vraiment clés, des moments de tournant. À quoi ou à qui est-ce que tu penserais? Déjà, je pense au tout premier job que j'ai fait au tout début de ma carrière. J'avais un de mes collègues qui était un petit peu mon mentor dans la sphère, dans le développement en Java pour créer des applications Java d'entreprise de qualité, bien testées, bien documentées aussi. Et donc, cette personne-là, Christopher, s'il nous écoute, il m'a vraiment donné ce goût de la qualité, de l'effort et de faire en sorte de rajouter des choses, d'implémenter des choses qui vont être utiles et bien pensées, etc. Côté user experience et autres. Donc, il y a déjà eu cette... Voilà, essayer de... Un bon développeur, mais pour arriver à faire vraiment du code de qualité qu'on peut déployer en prod, ça s'apprend.

9:38 Et d'avoir un bon mentor, ça aide beaucoup, parce qu'il avait déjà pas mal d'expérience. Et ensuite, il y a une deuxième personne. En fait, c'est quand je me suis mis à m'impliquer dans l'open source. Il y avait le cofondateur, j'ai cofondé le projet Groovy avec lui, mais c'est lui qui avait eu l'idée originale, James Strachan, il s'appelait, qui avait des... J'ai déjà travaillé sur pas mal de projets open source avant celui-là. Et en fait, il m'a vraiment appris cette contribution, ce partage au sein d'une communauté, comment arriver à attirer des utilisateurs, comment... En fait, mes premières contributions, c'est amusant, mais il y a le côté peer pressure, c'est-à-dire, oulala, mon code, il va être dans un projet open source, il va être visible par tout le monde, il n'y a pas d'intérêt. Parce que quand on fait du code en interne pour une entreprise, bon, il est visible en interne, mais je veux dire, il n'y a pas toute la planète qui peut voir ce qu'on fait. Tandis que là, dans l'open source, tout le monde peut voir ce qu'on fait. Et je me suis dit, oulala, il faut vraiment que la qualité soit encore meilleure que ce que je fais d'habitude.

10:40 Et donc voilà, le côté, l'amour du code bien fait, bien écrit, bien testé, j'ai continué à le développer grâce à mes contributions open source, grâce à cette personne-là en particulier. Puis voilà, une chose aussi qui m'a aussi amené à écrire des articles de blog, de faire des présentations, etc. C'est aussi ça, le fait que créer par exemple une nouvelle fonctionnalité dans un projet open source ou dans un produit, si cette fonctionnalité n'est pas expliquée, documentée, présentée, en fait elle n'existe pas, personne ne peut la découvrir, personne ne sait comment l'utiliser ou ne sait pas forcément même qu'elle existe du tout. Donc, le côté partage vient aussi de là, c'est-à-dire que ça peut être au travers de la documentation, d'articles, de présentations, etc. Mais j'ai toujours eu à cœur, en tout cas, de mettre... en avant et de présenter ce sur quoi je travaillais. Super. Ensuite, ce serait intéressant peut-être de comprendre les projets qui ont été peut-être pour toi les plus significatifs, les plus passionnants.

11:40 Alors après, tu nous as donné quand même quelques clés de lecture, puisqu'on sent bien que la partie open source et groovy, notamment, je pense, était très structurante, mais peut-être qu'il y en a d'autres en fait. En tout cas, c'est vrai que c'est celui où j'ai passé quand même le plus de temps. Après, il y a effectivement d'autres choses communautaires, on va dire, auxquelles le podcast Les Castes Codeurs, que je fais depuis pas loin de 15 ans avec d'autres amis, d'autres développeurs dans la sphère Java, souvent, principalement, en tout cas. Je sais que ça m'a aussi... Beaucoup appris et toujours le côté partage a toujours été important en tout cas de ce côté-là. Donc je suis un Java Champion, je fais partie de ceux qui ont été élus ou à qui on a décerné ce titre de Java Champion, qui est une reconnaissance dans la sphère, dans l'écosystème Java, parce qu'on reconnaît le travail que j'ai pu faire de promotion, etc.,

12:42 d'expertise dans ce domaine-là. Et ça m'a permis aussi de faire encore plein d'autres rencontres, sans parler de tous les événements, les meet-ups, les conférences auxquelles j'ai pu assister. Toutes ces rencontres, c'est tellement enrichissant. Moi, j'encourage les gens aussi à présenter. à des conférences et pas être simplement un simple spectateur, mais d'avoir l'occasion de parler de ce qu'on fait, de ce qu'on a appris, etc. Je pense que c'est des choses super importantes. Très bien. Alors pour moi, une des qualités essentielles d'un developer advocate, en fait, c'est sa capacité devant une audience à potentiellement être capable de toucher un peu tout le monde. Et on sait que c'est un exercice qui n'est pas si simple parce qu'on a des ninjas 5 étoiles et puis on a aussi des padawans qui commencent. Et je trouve que quelque chose qui fait ressortir la qualité première d'un developer advocate, finalement, c'est sa capacité unique à embarquer ou de toucher, et de toucher tout le monde dans la salle.

13:46 Du coup, la question que j'ai envie de te poser, c'est est-ce qu'avec toute l'expérience que tu as pu gagner dans ce domaine-là, est-ce qu'il y a une ou des stratégies que tu utilises finalement pour rendre des fois des concepts qui peuvent être vraiment complexes, finalement accessibles à tous dans cette quête d'inclusivité et d'embrasser un maximum de personnes. Que j'ai remarqué, en fait, c'est que si c'était compliqué et difficile d'expliquer quelque chose, c'est que ce quelque chose est intrinsèquement compliqué, bien sûr, mais que c'est problématique, en tout cas. C'est-à-dire que peut-être, donc j'ai aussi co-écrit... un livre où j'expliquais certaines fonctionnalités, c'était à l'époque du langage Groovy, où je m'apercevais que quelque chose était compliqué à expliquer parce que, de manière inhérente, c'était compliqué et peut-être qu'il y avait un travail à faire pour rendre cette fonctionnalité-là plus simple.

14:46 Et en fait, c'est dans l'exercice même d'essayer d'expliquer, que ce soit un article, que ce soit une présentation, Si je me rends compte que, oh là là, comment je vais faire, par où je vais commencer, il y a trop de choses à expliquer, je me meurs. Soit que ça ne va pas. Donc, il faut que j'arrive à trouver, je ne sais pas si j'ai vraiment des astuces en soi, mais c'est le fait de faire ce travail de vouloir expliquer fait que pour que ce soit simple et que j'arrive moi à l'exprimer, il faut que je tourne les choses d'une manière plus simple et qui semblait en tout cas mieux perçue par les auditeurs, l'audience, etc. Donc, c'est arriver à simplifier au maximum ce que je dois expliquer et introduire quand même tous les concepts au fur et à mesure parce que sinon, je veux dire, les gens vont être perdus. Donc, je ne sais pas si je n'ai pas vraiment de recette de cuisine en soi, mais je m'aperçois quand c'est compliqué et j'essaie de trouver comment décomposer les choses, comment toujours résumer au mieux les choses.

15:49 Après, il y a l'aspect s'adapter effectivement à son audience. Donc, si je vais à une conférence Java, oui, les gens sont des développeurs Java, donc il y a plein de choses que je n'ai pas besoin d'expliquer par rapport au langage. Mais par contre, si j'ai fait pas mal de présentations pour vulgariser aussi ce qu'était l'intelligence artificielle générative, j'ai aussi des approches où j'essaie de faire des analogies. J'aime beaucoup aussi faire des diagrammes et des illustrations parce que souvent, même si je donne des explications avec des mots, si on peut rattacher à un diagramme avec des choses qui s'animent, etc., ça aide aussi à la compréhension. Donc ça peut être... L'aspect visuel aussi, je pense, qui font partie des petites choses que j'essaie de faire pour simplifier et rendre les choses plus claires. Peut-être une dernière question pour pouvoir clôturer cette première partie qui était vraiment là pour permettre à nos auditrices et à nos auditeurs de mieux te connaître dans ton parcours. On a bien compris que la technologie et l'exploration dans la technologie est vraiment au cœur de ton quotidien.

16:55 Puis même, on sent bien la passion que tu as quand tu en parles. Du coup, moi, je serais curieux peut-être que tu nous parles des tendances ou des technologies émergentes que tu vois vraiment transformer le quotidien de la sphère tech et surtout des développeurs, puisque c'est quand même le cœur de ton audience. Je ne sais pas, moi, sans être à 3-5 ans, pour toi, quelles sont vraiment les technologies émergentes que tu vois transformer le quotidien des développeurs? Déjà, simplement en regardant deux, trois ans en arrière, ce qui est arrivé avec tout ce qui est Generative AI, les chats GPT, Gemini, etc. Et puis, on a vu arriver des choses comme le RAG, Retrieval Augmented Generation. Et là, cette année, c'est les agents IA. Et on voit aussi les agents aussi, donc pas forcément que les agents qu'on déploie et qui vont faire des interfaces de chatbot, des agents qui vont tourner en tâche de fond, mais aussi les agents qui aident pour le codage, pour la programmation. On voit qu'ils commencent à arriver à maturité et je pense que ça va continuer.

18:00 évidemment, et je vois bien dans cette tendance-là une amélioration de tous ces outils qui vont être de mieux en mieux intégrés dans les workflows, dans les étapes de développement de projets pour les développeurs. Donc, je pense que c'est important aujourd'hui. De mettre les mains dans le cambouis, d'essayer des Gemini CLI, des Cloud Code, des Codex, etc. D'essayer d'appréhender, d'expérimenter avec ces outils-là, parce que dans les prochaines années, ça va être... On va être des développeurs augmentés grâce à ces agents de codage. Et je pense que c'est aujourd'hui qu'il faut s'y préparer parce qu'ils vont être partout. Et du coup, ça va être très important pour chacun d'entre nous de savoir les maîtriser au mieux. Ça me paraît clair en tout cas. Justement, si on essaye de creuser un tout petit peu le point que tu mets en avant et auquel je souscris complètement, la partie Agent IKI après la vague de Generative AI,

19:03 Aujourd'hui, on a deux grands protocoles, en tout cas tendance, une intégration horizontale, une intégration verticale. Notamment pour l'intégration horizontale, Google est super actif avec Agent to Agent, si ma mémoire est bonne. On a MCP sur une intégration peut-être plus verticale. Est-ce que tu as des conseils à donner si on avait des personnes autour du pont qui voudraient commencer à expérimenter? ou à essayer de toucher le potentiel derrière cette partie agent IKEA. Quels seraient pour toi les premiers conseils que tu pourrais leur apporter? Déjà, en tout cas, dans ce que j'appelle l'équation des agents IA, Donc, il y a différents éléments. Il faut un LLM, il faut de la mémoire pour pouvoir gérer les interactions avec les agents. Mais il y a aussi l'aspect, on appelle ça function calling, tool use, etc. C'est le fait que le LLM en lui-même, est limité par son apprentissage, ce qu'il a appris, et on veut qu'il puisse interagir avec le monde extérieur en lui adjoignant des outils.

20:11 Le protocole qui a permis de standardiser plus facilement les outils, c'est MCP, modèle contexte protocole, que tu as cité, et qui permet en fait à, par exemple, qu'est-ce que je vais prendre comme exemple de serveur MCP, imaginons on veut intégrer dans un agent IA des fonctionnalités pour faire des recherches géographiques, etc. On peut utiliser un serveur MCP qui s'intègre avec Google Maps, mais plutôt que chaque projet qui a besoin de faire des intégrations avec Google Maps crée face à sa propre sauce pour interagir avec les API de Google Maps, Maintenant, on a un serveur, quelqu'un a développé, alors ça peut être Google eux-mêmes, ça peut être un développeur, ça peut être un projet open source, mais il y a des serveurs MCP qui existent, qu'on peut utiliser et intégrer et configurer avec les agents IA pour n'avoir à faire ce travail d'intégration finalement qu'une seule fois. Donc MCP, j'aime bien ce côté standard pour essayer de faire interagir les LLM des agents qu'on utilise avec le monde extérieur pour faire tout un tas de choses, de faire des recherches,

21:18 de faire même, pourquoi pas, envoyer des emails, etc. On peut faire des serveurs MCP pour faire tout et n'importe quoi. Et le petit truc que je trouve sympa à faire, tout à l'heure, juste avant l'envoi, du podcast, j'étais en train de développer un petit serveur MCP parce que je voulais tester un framework que j'aime beaucoup utiliser, c'est Micronaut pour développer des applications, serveurs, en ligne de commande et autres. Et ils ont rajouté récemment le support de MCP. Je me suis dit, tiens, je vais me faire mon petit serveur MCP qu'après je peux configurer avec Gemini CLI, avec mon agent de codage que j'aime bien. Un cloud desktop et autres. Du coup, j'encourage les gens à développer un petit serveur MCP, par exemple, pour voir comment ça fonctionne. Ça, vraiment, je pense que c'est super important. Et tu parlais aussi de A2A, Agent to Agent, qui est l'autre protocole, effectivement, qui a pas mal le vent en poupe. Je dirais qu'il est peut-être... Alors, les deux ne sont pas forcément... Ça reste des... Protocoles encore en pleine évolution.

22:20 Donc, il va y avoir encore des nouvelles fonctionnalités, des choses qui vont peut-être casser, qui vont évoluer, etc. Par exemple, dans MCP, il y a deux types de serveurs, les serveurs qui tournent en local, mais il y a aussi les serveurs distants. Et les serveurs distants, les serveurs HTTP, utilisaient. Server sent events, mais là on a dit maintenant, ah non, maintenant il faut faire du streamable HTTP, c'est mieux. Donc on voit que c'est des protocoles en pleine évolution. Et là, dans agent to agent protocol, là il y a quelques, quand est-ce que c'était? Il y a quelques semaines, il y a IBM qui a dit, ah moi aussi je veux rejoindre ce protocole-là, et eux avaient développé, Agent Communication Protocol. Et donc, il va y avoir aussi de la consolidation parmi ces protocoles-là. Et là, on est vraiment dans une phase super intéressante parce que les choses bougent beaucoup, évoluent beaucoup. Et il y a peut-être quand même un petit côté important, un petit peu de veille technologique à faire par tout un chacun pour essayer de voir où est-ce que ça va, quelles sont les nouvelles fonctionnalités, pour être prêt

23:24 à les intégrer, à faire interagir des agents ensemble, etc. Ce qui est intéressant dans ce que tu as décrit, Guillaume, et puis en tout cas, là où moi, ça me fait vibrer aussi, et c'est comme si c'était une pure bouffée d'air frais, alors toute proportion gardée. Moi, j'ai eu la chance de connaître certainement, presque comme toi peut-être, les débuts du web et de l'Internet il y a plus de 30 ans, assumant notre âge. Et en fait, je retrouve des questions, des cheminements qu'on a pu avoir à cette époque-là sur comment structurer. Et moi, concrètement, je vois vraiment une évolution avec un décalage d'une expérience utilisateur où on était vraiment dans quelque chose qui était graphique, visuel, où on avait quelque chose qui est beaucoup plus conversationnel. Et ce que je trouve intéressant, c'est que dans cette transition, ça fait poser plein de questions. On se rend compte que tous les paradigmes qu'on utilise en termes de UI, d'UX, concrètement, sont vraiment challengés.

24:27 On se rend compte que les développeurs front-end, peut-être sont en train d'évoluer vers des architectes d'interface IA pour permettre à un monde agentique IA d'avoir des capacités de navigation et surtout de qualité d'échange et de données beaucoup plus avancées. Moi, je serais curieux d'avoir ton avis sur cette transformation d'un design visuel à finalement une approche plus conversationnelle. Comment tu vois arriver cette partie-là avec la volonté d'extraction sémantique? pour venir nourrir nos modèles. Je vais tout de suite prendre un petit contrepoint. On voit effectivement ces interfaces conversationnelles poindre vraiment partout. Et peut-être qu'on est dans cette phase d'abus de cette interface conversationnelle. Dans le sens où, dans beaucoup d'entreprises, le leadership va dire« Ah, mais il faut absolument qu'on rajoute un chatbot à notre application, à notre interface.

25:28 Parce que c'est la nouvelle manière de converser avec nous, pour nos clients, nos utilisateurs, etc. Mais malgré tout, bien souvent, il faut voir que tout ce qui est agentique, tout ce qui est generative AI, on peut en tirer parti et améliorer l'expérience utilisateur de nos applications, de nos services, de nos applis web, etc., de manière différente, en tout cas sans forcément créer une interface de type chatbot. Il ne faudrait pas rajouter un chatbot juste parce qu'il faut qu'on soit conversationnel. Mais il y a parfois des applications, je vais juste prendre peut-être quelques exemples, mais par exemple dans Gmail, on va voir des fonctionnalités de résumé d'email ou dans Google Chat de discussion. On peut rajouter aussi, on voit des outils aussi comme Notebook LM qui permettent, ok, on prend plein de documents, mais derrière, on essaie de trouver la substantifique moelle et d'essayer d'extraire les informations ou de créer, ça peut être une...

26:30 visualisation de type mind map pour comprendre le contenu de tous ces documents, etc. Moi, je suis assez curieux de voir, au-delà des interfaces conversationnelles, quels vont être ces nouveaux patterns, ces nouvelles intégrations des agents et des interfaces agentiques, au-delà même du chatbot et de la conversation pure et simple. Je suis assez curieux de voir ça. Merci beaucoup Guillaume par rapport à ce que tu viens de nous partager, parce que finalement, cette capacité de projection, c'est aussi ce qu'on va aller chercher lors du Tech Rock Summit 2025. Je propose qu'on passe à la deuxième partie de notre échange pour ce podcast. Tu sais que cette année, le thème du Tech Rock Summit 2025 du 1 et 2 décembre, c'est AI, de la hype à la réalité. Donc vraiment, on colle complètement à l'histoire de Tech.Rocks, c'est no bullshit, on a vraiment envie d'avoir des femmes et des hommes engagés sur scène pour nous parler de cette thématique-là.

27:34 Comment est-ce que tu pourrais teaser, sans donner trop de détails, c'est toute la subtilité de l'exercice, finalement ton intervention et quel va être le sujet de ta conférence? Évidemment, on parlera de ces nouveaux protocoles. On a parlé de MCP, de A2A, etc. Parce que c'est effectivement important de bien comprendre les enjeux qu'il y a derrière et ce qu'apportent ces protocoles, ces technologies. de voir aussi, donc on parle beaucoup d'agents, qu'est-ce que c'est qu'un agent? Il y a aussi, tu parlais de tout ce qui était no bullshit, etc. Parce qu'il y a un peu une certaine science-fiction, je trouve, derrière les agents, qui est, les agents, ça va être magique, ça va tout faire, on leur dit juste, fais ça, et ils vont se rendre compte tout seuls de tout ce qu'il y a à faire, comment découper les choses en tâches, ils vont être complètement autonomes et tout, mais en vrai, quand on fait des agents, on s'aperçoit que, Ce n'est pas si simple que ça. Donc moi, mon but, c'est aussi d'expliquer et de montrer là où la science-fiction rencontre le dur et le vrai et que ça ne se passe pas toujours aussi bien qu'on l'espère.

28:45 Donc voilà, tout ce qui est par exemple le planning, les IA vont deviner tout ce qu'il y a à faire. En fait, il faut les aider un petit peu plus que ça pour qu'ils arrivent à faire leur propre travail. Donc, voilà, on parlera d'agents, on parlera de bonnes pratiques, on parlera un petit peu des patterns, anti-patterns, des protocoles. Voilà, un peu de tout ça. Et puis, je pense que ce que je disais tout à l'heure, tu vois, sur… Le fait qu'on essaie de mettre des interfaces conversationnelles un peu partout, oui, mais il y a aussi des limites. Donc, je voudrais aussi pouvoir expliquer qu'il y a la science-fiction, il y a ce qui est vrai, il y a ce qui marche. Nous, ce qu'on veut, je pense à un Tech.Rocks, c'est ce qui marche surtout, et de comprendre ou d'éviter certains... écueils si on a été informé au préalable que oui, il y a certaines choses qui sont plus de la science-fiction que de la réalité. Merci, c'est très clair. Peut-être une dernière question. Finalement, pourquoi est-ce que tu as à cœur de prendre la parole sur ce sujet, et en particulier lors du Tech.Rocks Summit?

29:51 Alors Tech.Rocks, du coup, je n'y suis jamais allé, ça va être ma toute première fois. Donc je suis vraiment très curieux de découvrir cet événement. Donc, j'espère trouver aussi des gens peut-être différents de ceux que je crois, parce que je fais quand même beaucoup, beaucoup d'événements, de meet-ups, de conférences très, très développeurs. Là, c'est aussi des profils un petit peu différents. Donc, j'ai envie que ce soit des gens qui fassent aussi bien des startups, des grands projets, des entreprises, etc. Donc, voir un petit peu un panel un petit peu plus élargi que ce que je fais d'habitude. Donc, je trouve ça assez cool. Après, le sujet en lui-même, ça fait un petit moment que je travaille dessus, que j'ai mes idées. On a parlé de... Interface conversationnelle, tout ça. J'ai envie de partager un petit peu avec tout le monde ça. J'ai interagi avec d'autres personnes que tu connais bien, par exemple Didier Girard, etc.

30:54 Sur LinkedIn ou autre. On a souvent de très bonnes conversations. Donc voilà, j'ai envie de faire sortir un peu ces conversations qu'on a parfois entre nous et de les partager avec encore plus de monde et des gens encore plus variés. Donc à Tech.Rocks Summit, je pense que ça va être top et je vais bien m'éclater. J'ai hâte d'y être et de tous vous rencontrer. Écoute, moi je dis que le partage que tu proposes, c'est une sacrée bonne idée et on est vraiment impatients de t'avoir. Écoute, Guillaume, nous sommes arrivés à la fin de l'enregistrement de notre... J'ai juste envie de te donner un immense merci. C'était une belle découverte que ce moment passait avec toi, comprendre ton parcours, ton profil, quels ont été tes actionneurs. On a senti plein de passion, de curiosité, cette volonté d'explorer. Et je suis certain que les 1er et 2 décembre, lors du Tech.Rocks Summit, ça sera au cœur de ta conférence.

31:54 Donc un immense merci, Guillaume. Et puis pour nos auditrices et nos auditeurs, j'ai juste envie de vous dire que nous nous retrouvons pour le Tech.Rocks Summit 2025, donc les 1er et 2 décembre au Théâtre de Paris. A très bientôt.