Juste avant de démarrer l'épisode, un petit mot pour ceux qui ont déjà pensé à mettre leur logement sur Airbnb,
le partenaire de cet épisode, mais qui se disent que ça fait un peu trop de travail.
Eh ben, Airbnb propose un truc plutôt malin.
Le réseau de CoAute.
J'ai des potes qui font ça parfois le week-end à Paris et c'est très pratique.
Imaginez, pendant que vous êtes absent, un CoAute expérimenté s'occupe de presque tout.
La remise des clés, le ménage, les échanges avec les voyageurs,
même la gestion du calendrier ou des photos si besoin.
Ça vous permet de générer un petit peu d'argent pour vous faire plaisir sans avoir à vous en occuper.
Alors, trouvez un CoAute sur rbnb.fr slash haute.
H-O-T-E.
Merci Airbnb et bon épisode.
Peut-être que vous connaissez Zapier, Make ou N8N,
ces outils d'automatisation qui promettent de vous faire gagner des heures chaque semaine
en connectant simplement quelques blocs dans une interface toute jolie.
La réalité, c'est que l'automatisation, même avec ces outils no-code,
reste extrêmement proche de la programmation.
Ça demande des experts, du bidouillage constant et surtout un temps de développement non négligeable
pour créer ces workflows.
C'est un peu un gouffre à temps en vrai.
Mais ça, c'était peut-être une ère révolue.
Parce que, en ce moment même, il se passe quelque chose de fondamental dans le monde de l'automatisation.
Un changement profond qui explique pourquoi absolument
toutes les startups de Y combinateur de cette année parlent d'agents.
Pour en parler, on a invité Shubham qui a développé une expertise sur ce sujet
quand il était chez Konto et à travers ses clients.
Il va nous expliquer ce qui est en train de changer
et pourquoi cette vague d'agents déferle maintenant et pas avant.
Et surtout, il va nous montrer concrètement comment des automatisations
qui prenaient des jours à construire peuvent maintenant se créer en quelques minutes
juste en parlant.
On aura même une démo sur Blender.
On s'imagine il y a encore quelques années, j'ai besoin d'automatiser des trucs dans l'entreprise.
Personnellement, je n'ai pas des compétences de développeurs.
C'était quoi l'ancien monde dans l'automatisation ?
Déjà, l'ancien monde il y a 15 ans, pour automatiser, c'est simple.
Tu vas voir un développeur, tu dis, on a des fichiers PDF,
il faut en faire quelque chose et créer un script.
Donc en fait, très peu accessible, très cher, très difficile à maintenir
et surtout, surtout, surtout, en fait, tu ne veux jamais vraiment y investir
parce qu'il y a des humains qui le font.
Parce qu'en fait, le dev coûte beaucoup plus cher que les humains.
Et surtout quand c'est des tâches répétitives.
Et notamment, il y avait Amazon, MechanicalTor, que je ne sais pas ça vous parle,
c'est des gens qui littéralement font des clics-clics-clics
et c'est un service d'Amazon où il y a des gens qui font des clics-clics-clics.
Ça, c'était il y a 15 ans.
Puis un moment donné, il y a eu la vague d'outils d'automatisation
qui n'a fait que grandir avec zappure d'un premier temps,
outils de création d'automatisation visuelle.
Donc si il se passe ça, fait ça, exemple,
si j'ai un nouvel email et qu'il y a le mot clé invitation dedans,
ajoute-le dans une spreadsheet ou envoie-le dans Slack, etc.
Ça, tu pouvais le faire depuis dix ans à peu près.
Mais les boîtes étaient encore un peu frileuses d'y aller
parce qu'elles se disaient, putain, j'ai envie de le faire,
mais c'était pas dans les meurs, etc.
Les gens avaient un peu peur et petit à petit,
plus il y a eu d'applications connectées avec zappure,
plus les gens ont voulu y aller.
Parce que zappure a fait un gros effort de connecter
plus de maintenant 5 000 applications, je crois,
que tu peux automatiser et en rendant le truc très simple.
Ce que pour comprendre la grosse valeur ajoutée,
c'est déjà t'as pas besoin d'être développeur puisque c'est des nœuds
que tu connectes ensemble, en fait.
Et le deuxième truc, c'est, si je me trompe pas,
quand t'es développeur,
une grosse partie de la complexité, c'est dans l'interconnexion
et l'interopérabilité des services.
En fait, si je prends, il y a 10 ans,
si on te dit, si par exemple tu dis à quelqu'un de ton équipe,
bon, il faut absolument qu'on connecte Notion
pour que quand quelqu'un a pu sur un bouton,
que ça upload la miniature directement sur YouTube,
eh bien, il fallait que la personne qui code
s'intéresse à l'API de YouTube
et qui s'intéresse à l'API de Notion.
Et on n'a jamais vraiment réussi à trouver de standards
et de manières de créer les APIs.
En fait, et du coup, la personne fallait qu'elle bosse
sur deux coins pour après arriver à un truc
et donc, c'était beaucoup d'efforts.
Donc, Zapier a fait un gros travail
de connecter toutes les APIs de tout le monde
et de créer une interface hyper simple
pour faire ce genre d'automates sessions.
Et puis, petit à petit,
il y a plusieurs plus d'outils qui sont développés.
Il y a eu, donc, Integromat, et maintenant, ça s'appelle Make,
il y a eu PipeDream,
tous ces outils-là vont dans ce sens,
ce qu'on appelle un peu du Visual Programming,
donc réussir à créer des workflows en Visual.
C'est quoi, toi, les trucs que tu as vus le plus fréquent
qui marchent réellement,
qui sont très adaptés, justement, à ce genre d'outils,
et peut-être d'autres qui sont des mauvaises idées
et que des boîtes essaient d'automatiser,
mais en fait, ça marche pas bien, c'est pas fait pour.
En fait, tu vois, tu prends n'importe quelle entreprise.
Il y a des tâches qu'elle fait pour pouvoir exister,
pour pouvoir créer de la valeur,
et ces tâches sont toujours les mêmes.
Bah tu vois, par exemple, set up les caméras, allumer,
allumer la régie, faire un tout un tas de checklists,
j'imagine que vous avez une checklist de voici ce qu'il faut faire.
Prendre les rushs, les uploader sur un site.
Exactement.
On voyait un message au monteur.

Ça, c'est des tâches run.
En fait, c'est des tâches obligatoires.
Elles apportent de la valeur,
mais c'est pas nécessairement obligatoire,
c'est un être humain qui le fasse.
Parce qu'en fait, il apprend rien en le faisant.
Littéralement, ils fonctionnent comme une machine
pour pouvoir faire ces tâches-là.
Et de l'autre côté, on a des tâches build,
donc de création, en tout cas, de construction,
et là, ça va être typiquement
les notes que t'as pris en regardant des vidéos
pour pouvoir préparer une chronique.
C'est le moment où vous allez vous poser
pour voir le calendrier éditorial,
la conversation pour l'ouverture avec d'autres sponsors.
Donc ça, c'est du build.
Mais sauf qu'on ne se rend pas compte de la complexité
que ça peut représenter
et le nombre de micro décisions
qu'on prend tout au long de ça.
C'est-à-dire que de loin,
tu as l'impression que ton problème
est de simple automatisé,
mais en fait, au fur et à mesure que tu l'implémente,
tu réalises que tu as une grande complexité
que tu gérais toi-même facilement.
Exactement.
Et qu'en réalité, ça va te prendre un mois
de développer ce workflow.

Et le fait de catégoriser ces tâches-là,
ça nous donne du coup une indication sur...
OK.
Où est-ce qu'est ma vraie valeur ajoutée,
en tant que boîte, en fait ?
Où est-ce que là où les humains
vont vraiment contribuer à faire grandir le truc ?
Et pas juste à pédaler, en fait, tu vois.
Donc ça, on va dire, c'est ce qui existait déjà.
À quel point LIA a changé quelque chose d'important
dans le monde de l'automasiation ?
Parce que, évidemment, tous les outils que tu m'en souviens,
certains en huit ans, dix ans,
étaient déjà énormément utilisés.
C'est pas des outils qui sont nés exactement dans LIA.
À quel point les modèles de langue ont eu un impact fort, faible ?
Il y a eu tous ces outils-là
qui ont voulu l'intégrer dans un premier temps, un peu, sur la hype.
Donc ils ont voulu faire leur propre chatbot de...
Par exemple, M.A.I.C. a voulu faire son chatbot.
Genre, crée-moi une automatisation de trucs.
En fait, ça marche une fois sur deux, comme dans toute V1, je dirais.
Là, on est un peu un tournant, notamment avec NuitN.
Et là, je parle pour les gens qui vont plutôt être techniques,
donc CamToie, etc.
Donc on va pouvoir, avec de LIA, générer des automatisations.
Par exemple, une automatisation qui fait des miniatures,
tu vas pouvoir demander à Claude, Chatchapetet,
génère-moi le blueprint,
donc entre guillemets l'espèce de langage
qui va décrire cette automatisation,
tu vas pouvoir copier coller sur NuitN.
Donc ça, ta V1 va être hyper rapide.
Donc ça, dans la construction, on gagne beaucoup de temps.
Après, il y a l'IA à l'intérieur de ces outils-là,
ou même pour ces outils-là,
la connexion avec d'autres outils a été beaucoup plus simple.
Et puis à l'intérieur, en fait, depuis qu'il y a eu le NEO,
Chatchapetet, le NEO-Claude, en tout cas,
ou même OpenRouter maintenant, avec tous les LLM qui sont connectés,
ça a permis à plein, plein de monde de faire des automatisations
qui n'étaient pas possible avant.
Ça, ma impression, c'est que tu as toute une gamme d'automatisations
qui passe de impossible, infesable, jamais à...
Maintenant, c'est bon.
Donc tu as donné l'exemple du tri de mail,
mais par exemple, tu as essayé de faire du tri de mail en repérant un mot-clé.
C'est bien plus compliqué.
C'est horrible.
Ça n'arrive à rien.
Aujourd'hui, tu peux faire un système avec des promptes
qui vont regarder chacun de tes mails
et de manière très fine pouvoir te le mettre dans telle ou telle catégorie.
Nous, on le fait, typiquement, avec la boîte mail, le manant de la boîte,
où on va avoir un mail.
Est-ce que c'est une demande d'un abonné,
ou est-ce que c'est une invitation, un événement,
ou est-ce que c'est un partenaire, un sponsor qui veut parler avec nous ?
C'est extrêmement complexe, en fait, de faire un filtre
avant l'air de lia pour ce genre de choses.
Mais c'est clair.
Et maintenant, c'est possible.
En fait, il faut se dire que tout ce qu'on tape sur un chatbot,
je ne sais pas sur votre interface, cette GPT, tout ce qu'on va taper,
les données d'entrée qu'on va mettre,
on peut les connecter directement à une automatisation.
Donc, une fois qu'on a trouvé le bon prompt,
on peut juste mettre ce nœud,
tu as le PT ou ce nœud Claude ou quoi que ce soit,
dans une automatisation, et puis ça va le faire à l'infini.
Et pas au salon à ce que ce n'est pas dans le workflow
que le LLM a sa vraie finalité ?
Est-ce que ce n'est pas là qu'il est le plus puissant ?
Selon moi, oui.
Parce qu'en fait, encore une fois, je reviens toujours à ces tâches build & run.
Et pour moi, la répétition d'une tâche si elle est faite sur un LLM,
ça veut dire que à chaque fois, si pour répondre à un sponsor,
tu dois copier-coller le message du truc et tu vas dire,
bon, selon ce que je dis d'habitude,
répond-lui avec ma manière de répondre
et fait en sorte qu'il n'est pas relancé.
Par exemple, si cette tâche, tu l'as fait dix fois,
il y a un moment donné, tu peux l'encapsuler dans un workflow
pour éviter de l'affaire.
Moi, par exemple, j'ai un business de formation,
tu vois sur lequel je forme les gens à Make, Notion, etc.
Et il y a plein de gens qui me posent toujours la même question.
Comment est-ce que ce lien-là,
il ne marche pas ou alors comment est-ce que je peux accéder
à cette ressource-là, etc.
Et tu vois, j'ai une grosse FAQ.
Et du coup, la manière dont l'agent va venir répondre,
donc le LLM en question va créer le draft en question,
donc le brouillon, il va lire la question,
il va le mettre dans une catégorie,
il va regarder dans mon espèce de FAQ qu'est-ce qu'il y a marqué ?
En fait, qu'est-ce qu'il faut faire ?
Et donc là, il y a marqué qu'il faut aller scorer un peu la réponse
en fonction de la personne qui contente ou pas contente,
en fonction de si elle vous voit où tu tois,
et va créer un draft.
Et en fait, si il y a un score suffisant de certitude,
il l'envoie automatiquement.
Moi, ce que je trouve bien dans l'approche,
parce que c'est toujours un sujet à débat,
en mode on va parler des agents,
la réalité c'est que moi, quand je suis sur un site,
et que je vois un agent, que je pose une question,
en mode j'ai-t-elle le truc qui marche pas,
et que j'obtiens la bonne réponse instantanément,
c'est incroyable.
La raison pour laquelle on déteste les chatbots automatiques,
c'est que ça marche pas.
C'est qu'en fait, pas seulement ils sont plus performants,
en réalité, c'est génial.
En fait, le support client,
en tout cas l'aide aux agents de support,
parce qu'on garde les gens qui vont quand même superviser tout ça,
c'est le premier truc,
en train d'être massivement automatisé,
où en fait, les gens sont plus contents.
Tu vois ?
Oui, la satisfaction client augmente en fait.
Ce qui est intéressant, c'est qu'il y a autre chose qui,
j'ai l'impression qu'il est en train de se produire,
c'est que cette idée que justement,
les automatisations vont être décrites
avec des briques assez similaires à de la programmation,
ça, c'est en train d'être mis en question aussi.
Le futur, j'ai l'impression,
tu me dis si c'est cette impression aussi,
mais ça pourrait être que
une automatisation, ce soit un texte,
où tu demandes des trucs,
et l'agent le fait.
Une des raisons qui laisse penser ça,
c'est ce nouveau protocole qui s'appelle MCP,
vous avez peut-être entendu parler,
et les IA qui vont avec pour le faire marcher.
Je fais ce préambule parce que,
je ne sais pas, quand moi j'ai vu les news de MCP,
je me suis dit c'est sympa.
C'est une belle jambe, c'est super.
C'est des API un peu mieux,
c'est de chat GPT un peu mieux,
mais après ce que j'ai vu justement,
c'est comment en fait,
grâce au concept du MCP et de ces nouveaux modèles,
il est possible de créer des automatisations ultra-puissantes
en leur 5 minutes chrono.
En fait, le besoin, c'est tout business
qui a compris qu'en fait,
ou tout entrepreneur,
soit le preneur ou ce que tu veux,
qui a compris qu'il n'a pas envie de faire des tâches récurantes,
et des trucs qu'il a envie,
que l'ordinateur fasse automatiquement
et qu'il n'a pas la compétence de programmer l'ordinateur,
il a envie de les faire,
et il sait que c'est possible.
Et ces outils-là viennent en réponse à ça.
En fait, c'est moi, je suis sales, commercial,
voici ma liste de prospects que j'ai eue hier.
Va regarder le LinkedIn de tout le monde,
regarde le dernier poste,
commande sur son dernier poste,
essaye de savoir un petit peu
dans le passé de la personne,
dans quelle école il a fait,
fais une blague là-dessus et écrit lui un email.
En fait, la personne ne savait pas faire ça avant.
Et maintenant,
vu que ça devient de plus en plus simple
de créer des automatisations,
donc ça se passe derrière, le rideau,
eh bien ces gens-là pourront,
on n'y est pas encore, c'est le début,
c'est les boîtes qui commencent à promettre ça,
mais la promesse est là
et je pense qu'on va y arriver.
Et justement, pour comprendre
qu'est-ce qui a changé,
qu'est-ce qui fait qu'avant,
c'était pas possible et maintenant,
ça le devient,
il faut qu'on parle un petit peu,
justement, du MCP.
Est-ce que c'est juste une API un peu mieux ?
En quoi c'est vraiment nouveau
de ce qui a toujours existé ?
Et pourquoi c'est un truc
qui peut avoir un impact important ?
Tu vois, on a parlé en effet
d'API tout à l'heure,
on a vu que le plus compliqué,
en fait, dans les APIs,
c'était que chaque API était différente.
Demain, si Wanker Studio
veut faire une API ou n'importe quelle boîte
veut faire une API,
eh bien il faut bosser dessus,
tu vois, il faut définir
les différents manières de faire cet API.
Ce nouveau protocole,
MCP, qui a été lancé par Anthropique,
enfin nouveau,
ça fait un petit moment maintenant,
mais en tout cas, c'est vraiment que là,
sur je dirais,
les deux, trois derniers mois,
qu'on voit vraiment l'impact
en fait de ce protocole.
En gros, comme t'as dit,
c'est API amélioré,
mais qui n'est pas fait pour des humains
pour qu'ils lisent la doc
et qu'ils intègrent
dans un script, en fait.
Elle n'est pas faite pour des humains.
En fait, ce protocole,
il n'est pas fait pour des humains.
Il est fait pour des LLM.
Grosièrement,
c'est une manière de connecter
des applications ensemble
qui est standardisée.
C'est quand même une multiprise universelle.
N'importe quelle application,
maintenant, si elle est compatible
avec le protocole MCP,
et du coup, peut se connecter à un LLM.
Et quand ça veut dire
peut se connecter à un LLM,
ça veut dire quoi qu'un LLM, du coup,
quand tu lui demandes,
est-ce que tu peux envoyer ce email
pour moi une fois
que tu as demandé
comment il a été rédigé
ou comment est-ce que tu pouvais le rédigé ?
Et bah, en fait,
il sait,
parce qu'il est connecté avec le protocole,
comment demander à Gmail,
Outlook, Thunderbird ou ce que tu veux,
comment est-ce qu'on envoie un email ?
Ok, donc très concrètement,
dans le backend d'entropique, par exemple,
qu'est-ce que le modèle voit ?
Moi, de mes souvenirs,
avant les MCP,
il y avait déjà le concept d'outils.
Oui.
Et donc, concrètement,
la manière dont on a toujours fait
c'est qu'on a appris au modèle
à créer des données structurées.
Donc, typiquement, à créer des formages JSON
ou des objets
où on peut définir,
comme dans un tableur,
des données qui ont une structure.
Donc, on peut dire, ok, par exemple,
on fait un outil mail
dedans, il y a l'expéditeur,
le dessin acteur,
le contenu du mail.
Et les LLM,
en petit à petit,
étaient de mieux, de plus en plus
compétents pour créer,
justement, des objets valides
qui marchent à tous les coups
et qui s'appellent à peu près au bon moment,
etc.
MCP,
c'est quoi la différence ?
Tu vois, tu parlais du
du LLM qui essaye de créer son JSON
ou en tout cas, tu lui donnes un JSON,
il va remplir à l'intérieur
le dessin acteur, etc.
Et cette structure-là,
en fait, tu l'as inventée
ou tu l'as créée.
Elle n'était pas standardisée.
Et du coup,
on entrepris qu'à proposer un standard
qui a été adopté,
qui est de,
écoute,
on va avoir toujours une architecture client-server.
Le client, c'est ton interface cloud.
Le serveur, c'est le serveur MCP
qui est lié à l'application.
Tu vois.
Et en fait, ils vont se discuter ensemble.
Le client,
il a accès à trois choses.
Il a accès aux ressources, aux outils et aux prontes.
Donc, grossièrement, c'est les trois,
tu vois, trois endroits dans lesquels,
en fait, tu dis à ton LLM,
bah, est-ce que tu peux envoyer un mail ?
Il dit, écoute, je vais essayer de faire.
Il dit, bah,
ouais, il y a gmail.
OK, bon, je vais essayer de voir.
C'est quoi, déjà, tes tools ?
Et là, il va dire,
bah, je peux lire, envoyer,
supprimer, mettre embryon, etc.
Et ça, il fait, ah, cool.
Et comment on utilise en voix ?
Il va dire, bah, voici comment j'utilise en voix.
Donc, tu peux avoir,
parce que tu peux toi-même,
créer un serveur, un MCPS, tu vois,
et bah, ça doit respecter
une certaine certaine standard.
Et du coup,
ça code la discussion entre les LLM et LLM.
En fait, ça donne la manière de discuter.
Et ce qui est vraiment intéressant,
c'est que la différence avec une API,
c'est que ou avec les outils,
comme on les utilise avant,
c'est que tu donnais tout d'emblée.
Globalement, tu disais, voilà,
tous les outils que tu as à ta disposition.
Et donc, techniquement,
ça peut impacter très négativement
les performances des modèles.
Oui, parce qu'il faut qu'ils cherchent tout le contexte.
Et on sait qu'au-delà de 4, 5, 6 outils,
ça commence à se dégrader,
leur capacité d'utiliser le bon outil,
justement, se pète la gueule complètement.
Ouais.
Et puis, ce qui est très intéressant aussi,
c'est que ça rend la conversation dynamique.
C'est-à-dire que ton serveur,
il peut décider de t'envoyer uniquement
une partie des outils
en fonction d'un certain contexte.
Et typiquement,
si tu regardes la manière dont Notion
fait le, font leur serveur MCP,
ils exposent pas toute la pays.
Ce serait impossible.
Tu vois, le modèle,
il serait complètement à genoux.
L'interdue.
L'interdue.
Et donc, il y a beaucoup d'ingénieurs et de logiques
pour simplifier au maximum l'interface
pour que de manière textuelle,
juste avec 5, 6 outils ou 4, 5 outils,
tu puisses à peu près tout faire dans Notion.
Ok.
Tu as un outil recherche.
Tu n'as pas genre recherche dans une bête de nez,
recherche dans ma charge.
Juste, c'est un tout le recherche.
Et tu dis recherche dans tout Notion.
Et il y a aussi un autre avantage
parce que c'est un des sujets, c'était le versioning.
Par exemple, tu vois, la Paix de Notion,
récemment ils ont changé la manière de faire les bases de données
et c'est un bordel.
Bah, il n'y a pas de sujet de versioning
parce qu'en fait c'est le serveur MCP qui se gère.
Ton LLM, il va demander,
« Comment on fait pour avoir une base de données ? »
Bah, la réponse sera différente et c'est ok.
C'est ça.
Il n'y a pas de contrat sur le format des données que tu renvoies.
Comme c'est un LLM qui ultra adaptable.
En fait, il s'adapte à n'importe quelle donnée que tu lui renvoies.
En fait, c'est le maître d'hôtel qui t'accueille à l'hôtel, qui sait tout.
Même s'il y a des chutes, des changements en interne.
Et toi, tu lui parles juste au maître d'hôtel.
Exactement.
Pour aider aussi à comprendre pourquoi
ce n'est pas une hype ou une ennemime bulle inintéressante, les MCP.
La réalité, c'est que ça répond à un vrai problème
qui est de faire un protocole, une interface très simple
qui va pas péter dans le temps, qui est robuste,
sur lequel tout le monde peut travailler.
Et justement, ce que t'expliques, c'est que c'est sorti il y a deux ans,
mais c'est que maintenant qu'on est en train de voir le résultat.
Ouais.
Peut-être pas deux ans, mais peut-être un an,
ou je n'ai pas la date exacte.
Mais ce qui est clair, c'est qu'au début, c'était un truc de cool.
On a un nouveau protocole.
On ne sait pas trop comment l'utiliser,
mais maintenant, de plus en plus, DLM commence à être compatible.
En tout cas, d'interface sont compatibles.
Et notamment, les agents qui codent.
En fait, le vrai usage, en tout cas,
que moi, j'en fais dans tout ce que je fais aujourd'hui,
d'exploration, on va dire plutôt tech, c'est pour les devs.
Avoir un MCP GitHub, c'est quand même bien plus cool que de devoir taper.
Git, commit, push, blame, enfin tous ces trucs-là, tu vois.
Parce qu'en fait, c'est tellement plus simple de demander à ton MCP.
Dis, tu veux bien push ce code et est-ce que tu veux bien regarder
si je n'oublie pas un fichier et être certain de respecter le Gitignore, etc.
que de taper toi-même.
Ouais, c'est pour expliquer aux gens qui ne sont pas développeurs.
La raison pour laquelle ça arrive avant dans les outils de développeur
et après ailleurs, c'est aussi que tu peux faire des interfaces plus simples.
Et donc, il y a notamment un outil qui a tout explosé sur les cidres animois
qui s'appelle le Cloud Code.
En fait, c'est une interface dans un terminal.
Donc forcément, c'est très, très rapide d'itérer, de développer le truc.
Et pour le coup, il manquait les modèles aussi, qui savaient l'utiliser.
Donc, c'est une sorte de cercle vertueux où l'un et l'autre évoluent ensemble.
Et aujourd'hui, dans Cloud Code, globalement, on voit un premier usage de CMCP.
Est-ce que tu as d'autres exemples qui peuvent parler peut-être aussi au nom développeur ?
C'est vrai que les exemples un peu waouh, c'est typiquement Blender
où tu pouvais demander à Cloud designement un château par exemple.
Donc là, le château, c'est pas moi qui le fais.
Et il l'a fait à la voix en plus.
Vraiment, il parle à son Cloud et il y a un château qui apparaît sur son Blender en direct.
Oui, j'ai beaucoup de speech-to-texte.
Et du coup, au fur et à mesure, lui, il était...
Moi, par contre, c'est moi qui changeait les angles de caméra.
Ça, pour le coup, c'est moi qui le faisais.
Typiquement là, en château, j'ai donné une image de château.
Genre, il te reproduit le château.
Oui, mais pas aussi bien, mais il me reproduit le château.
Surtout, tu ne codées pas Blender.
Moi, j'ai jamais fait de 3D.
C'est fini, j'ai jamais fait de 3D.
Voilà, c'est le côté un peu waouh, un peu...
Mais par exemple, il y a un outil de formulaire qui s'appelle Tali.
Tu as besoin de faire un formulaire pour demander le feedback de ton audience.
Avant, t'aurais fait quoi ? T'aurais été sur typeform, t'aurais chant, type texte.
Je mets un truc.
Attends, il n'est pas très large.
Attends, je le mets.
C'est là, il est obligatoire ou pas ?
L'email ou l'olà, c'est le type email, ce n'est pas type...
En fait, c'est hyper galère.
Là, tu décris à ton NLM.
Écoute, j'aimerais bien faire un formulaire pour demander comment était cet épisode.
Du coup, il y a certainement un truc avec des étoiles.
Il y a aussi le nom prénom.
Il y a un fil caché dedans.
Tu fais entrer.
Ça va discuter avec le NCP de Tali.
Et dire, OK, je te propose de créer ces chants-là
avec ces types-là en étant obligatoires ou pas, etc.
Et ça, c'est insane.
Du coup, la création de formulaire, c'est hyper rapide, par exemple.
Et là, c'est très inception, ce que je veux dire, le dernier exemple.
Mais vu qu'il y a aussi un MCP N8N,
tu peux demander à ton NLM de dire,
écoute, fais-moi une automatisation qui, en entrée, c'est un formulaire
qui a deux champs de type, idée de la vidéo, contexte de la vidéo.
Après, elle doit aller taper sur l'API de cette boîte-là
pour pouvoir générer une image.
Ensuite, cette image, elle doit être uploadée dans Notion.
Et ensuite, je dois recevoir un mail avec les images.
Tu dis ça.
Et en fait, vu que N8N, la manière dont les nœuds sont connectés, c'est un JSON,
et du coup, il va te créer le JSON,
mais il va aussi aller appeler ton instance N8N,
dire, écoute, j'ai la possibilité de te créer une automatisation.
Oui, OK, est-ce que je peux donner ce JSON ?
OK, oui. Est-ce que tu peux la lancer ?
Oui.
Attends, il va valider que ça marche bien.
Oui.
Ou à de...
Est-ce que tu peux regarder les erreurs ?
OK, attends, excuse-moi, je me suis planté.
Non, non, et mieux encore, vu que la manière de générer ce JSON,
elle est assez standardisée par N8N.
Et en fait, il y a un MCP qui s'appelle Contextaban,
qui a toutes les docs du monde.
Bah tu peux aller...
La documentation, des librairies pour les développeurs, etc.
Voilà. Et donc, il y a une documentation qui est celle d'N8N.
Du coup, il peut savoir à l'avance qu'elle est la manière de créer ce JSON.
Et du coup, limiter le nombre d'erreurs.
Et donc, il va run cette automatisation,
il va prendre les erreurs, il va s'auto-iterrer,
et il va te donner un truc pas trop mal.
Ce n'est pas parfait, mais il va être documenté.
Très que tu fais jamais de...
Il va être documenté, il va être structuré,
et après, tu vas pouvoir commencer sur une base.
Et ça, c'est génial.
Et ça, donc en plus, là, c'est que des usages de MCP
dans le cadre d'une conversation avec ChargerPT,
comme les gens peuvent la connaître.
Exactement.
Maintenant, il y a encore une étape après.
Ou là, on passe de la discussion à des systèmes plus autonomes, en fait.
Qui marchent en arrière-plan, sans que tu es toi-même à y penser,
et qui vont justement combiner des agents,
combiner des LLM, et des MCP, des connecteurs.
C'est aussi appelé connecteur, parfois.
Qu'est-ce que ces boîtes essaient de résoudre comme problème ?
Et est-ce qu'on peut essayer d'imaginer ce sera quoi l'impact
pour les valets de gens qui ont aujourd'hui un job à peu près normal,
qui sont non-dèvres, vous voyez ?
En fait, toutes ces boîtes, ce qu'elles essaient de faire par industrie,
c'est de leur donner le pouvoir de créer des automates.
De créer de l'automation.
Pour pouvoir faire ça.
Et les MCP aident, parce que du coup, quand tu dis valir ma boîte mail,
le programme en question ou la boîte,
elle va essayer d'une fois que tu as connecté ton Gmail,
d'aller discuter avec le MCP, voir s'il peut en tirer quelque chose.
Et donc, en fait, on crée une couche d'abstraction.
C'est ce qu'on a déjà parlé.
Maintenant, à quoi ça pourrait ressembler ?
Et en tout cas, vers où on va, selon moi,
on va vers, typiquement, de moins en moins de runs et de plus en plus de builds.
Ça veut dire que je pense que la manière dont ces colblancs,
ou en tout cas de knowledge worker, comme ils les appellent aux US,
on va de plus en plus se concentrer sur, OK, quels sont les choses que je réfléchais au quotidien,
quelle est mon expérience et comment est-ce que je vais pouvoir l'utiliser
pour créer du nouveau, pour créer, pour bâtir par-dessus,
plutôt que de juste pédaler.
Donc si mon travail ressemble à, je reçois les mêmes mails,
je t'écharge les mêmes pièces jointes, j'envoie,
je les analyse vite fait et je les envoie
et je ne fais que déplacer de la matière,
mais sans injecter dedans de la réflexion critique et spécifique,
c'est que ça doit être automatisé.
Et du coup, on va, et évidemment, ça va se faire par une transition,
mais que ces gens-là arrivent à capter assez rapidement
qu'en fait, c'est une bonne chose de l'automatiser,
comme ça, je peux me concentrer sur de la valeur ajoutée.
C'est vers ça qu'on va.
Et le problème de ça, c'est que c'est encore,
et pour parler avec plein de boîtes et pour parler à la fois
à des CEO et des Syllable qui sont plutôt,
donc on va dire des scellenaires stratégiques
et à des gens qui sont dans le l'opérationnel,
il y a à la fois des étoiles dans les yeux de Syllable
parce qu'ils sont en mode, oh mon Dieu, ça va tout automatiser.
Et les opérations, ils sont en mode,
ouais, mais c'est un peu ce que je fais tous les jours,
donc c'est un peu flippant.
Et du coup, je pense que déjà le switch, il est plus dans la tête
parce qu'il y a les usages, il y a les outils,
ils sont encore très niche, mais plus ils arrivent,
plus on va devoir trouver de la place,
on va devoir réfléchir à notre manière de travailler
et à va se faire que sur du build principalement du coup.
Je trouve qu'à chaque fois qu'on parle de description comme ça,
il y a un truc à distinguer entre ce qui va se produire
et ce qu'on aimerait qu'il se produise.
Donc là, si tu ne nous dis pas,
j'ai grave envie de mettre à 80% de la France au chômage.
Ce que tu dis, c'est ça se produit.
La question, c'est comment on peut réfléchir déjà à l'avenir
pour anticiper et à titre personnel,
développer des compétences qui vont être utiles pour la suite ?
C'est ça la manière de voir les choses, en fait,
pour rester dans le game, c'est un peu cette question.
Oui, mais au-delà de rester dans la course,
en tant qu'humain et quand tu te parles,
on a plein de micro décisions et d'appel à notre propre manière de faire,
qui sont instantané et on ne se rend pas compte.
Mais je trouve que c'est cette approche
où tu as une approche sur le travail qui n'est pas juste celle de pédaler,
de faire tourner la machine, mais de construire le vélo.
Et c'est deux approches complètement différentes.
En fait, on va changer de métier, on va arrêter d'aller,
on va juste réfléchir à quel système on construit,
plutôt qu'on travaille dans le système.
Pour le dev, ça va être ça l'analyse,
c'est au lieu de tous les jours d'être dans mon éditeur de code
et de faire à chaque fois les mêmes raccourcis de...
Mais en fait, je vais complètement éditer
et customiser mon éditeur de code pour plus faire ça.
Et du coup, je ne réfléchis pas à comment je peux taper plus vite,
mais comment je peux prendre du recul et recréer mon espace de travail.
C'est vraiment ce paradigm shift là.
Ce que je trouve intéressant aussi, c'est de se dire
que même les gens qui potentiellement aiment bien tout automatiser,
les Angers, les Dev et tout machin,
jusqu'ici, il y avait un curseur de « Est-ce que ça vaut le coup ? »
Et bon, parfois, tu le faisais aussi un peu par kiff,
de tomber une cisez, de configurer un Ocean, on a tous fait ça.
Mais ça ne valait pas forcément le coup au temps passé.
Et en fait, tu me disais que ce temps, il est amené à se réduire
et donc de plus en plus, ça va valoir le coup d'automatiser
des choses qui nous paraissent aujourd'hui,
« Non, on ne va pas l'automatiser,
ça ne va pas me faire gagner assez de temps. »
Et que ça nous donnait encore plus d'excuses pour optimiser.
Et ça, c'est chouette !
Si ça vous a intéressé,
je vous conseille vivement notre interview d'une chercheuse en IA
qui nous a présenté une question assez peu abordée
et pourtant préoccupante de l'auto-empoisonnement des IA
et de ce qui pourrait arriver dans quelques années.
C'était dans cette vidéo.