Bruno:
A la grande époque du télégraphe, chaque mot envoyé coûtait de l'argent. Alors on apprenait à dire autant qu'on pouvait avec le moins de mots possibles. Les phrases devenaient des squelettes, la ponctuation était un luxe et le mot stop était devenu un art de vivre. On payait aux signes et donc on compressait. 150 ans plus tard, on a réinventé ce compteur qui tourne, on l'appelle le token et nos assistants de code en avalent par millions. Mais alors, comment dire plus avec moins sans jamais perdre le sens ? Faut-il vraiment un LLM pour comprimer ce qu'un autre LLM va relire ? Et surtout, est-ce qu'un simple coup de Rust peut faire trembler la facture d'anthropique ? Pour répondre à ces questions d'économie, je ne reçois pas James Bond, mais il s'y connaît en jeton. Patrick, bonjour.
Patrick:
Bonjour.
Bruno:
Alors Patrick, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Patrick:
Je suis Patrick Zimkoviak, ça fait 20 ans que je travaille dans l'IT, sur la partie infrastructure et puis montée des sociétés. Et j'ai créé RTK que j'ai mis en ligne le 22 janvier dernier.
Bruno:
Alors du coup, l'idée, c'est effectivement que tu nous parles un petit peu de ce qu'est RTK. Peut-être qu'un bon moyen de le faire, c'est de nous expliquer, de nous raconter un peu comment ça a commencé, qu'est-ce qui t'est venu, comment cette aventure a commencé.
Patrick:
Oui, alors j'étais en incubation sur Atec pour une société Kexa, qui est un CSPM open source sur la partie européenne pour vérifier les clouds américains. Et le Vibe Coding est arrivé petit à petit. J'ai démarré en juillet avec du Gemini sur les premières sessions de Vibe Coding qui ne marchaient pas vraiment en fait. Mais bon, on voyait déjà à peu près ce que ça pouvait donner. Et après, avec un collègue, il m'a dit d'essayer Cloud Code. Donc, c'est ce que j'ai fait en septembre. Et puis là, ça marchait vraiment bien en fait. Donc là, j'ai repris les anciens projets que j'avais mis un peu de côté, que j'ai repris tout seul. Et là, j'ai commencé à bien Vibe Coder avec Cloud Code. Et forcément j'avais le forfait à 20 dollars donc j'ai atteint très vite comme tout le monde les sessions, les fins de session avec vous avez plus de token, terminé, merci. Et puis je crois que c'était début novembre où je faisais comme ça une session et il a listé un peu les répertoires qu'il y avait, sur mon ordi et je voyais plusieurs fois Patrick qui était affiché homme Patrick, homme Patrick et à la fin j'avais une fin de session Je me suis dit, c'est con, en fait, j'ai envoyé plein de tokens et en fait, ça ne servait à rien. Et du coup, j'en ai plus. Et donc, j'ai commencé à me dire, je vais faire un truc où dès qu'il fait un listing, je vais éliminer ce qui ne sert à rien. Je vais le transformer. Pareil pour les tests, etc. Et d'abord, j'ai réfléchi à un LLM qui allait faire ça en local, parce que je me suis dit, sinon ça va être compliqué de faire toutes les commandes. Et ça n'a pas marché. Je l'ai fait deux fois. Mon poste n'était pas assez rapide, les LLM n'étaient pas assez performants. Ils ne comprenaient pas, ça ne marchait pas. Et donc après, j'ai su ce que je voulais faire. J'ai tout refait en Rust et en SQLite pour stocker des informations. Et j'ai commencé par une dizaine, une quinzaine de commandes. Je l'ai utilisée pour moi pendant trois semaines, un mois. Puis après, je me suis dit, je vais mettre en ligne directement pour voir si l'intéresse des gens. Et ça, c'était le 22 janvier. Très rapidement, il y a eu des stars. Il y a eu des gens qui sont venus contribuer. Et puis, ça a très vite démarré, en fait, par rapport aux autres projets que j'avais fait. Donc, je me suis dit, il y a vraiment quelque chose là. Et donc on a continué à le développer avec des contributeurs pendant un bon mois et puis après je commençais à faire un peu de pub en ligne donc le premier édit, on voyait un cargo test qui éliminait je crois 900 lignes de test en une seule ligne, il a fait 380 000 vues sur une gif animée et après la semaine d'après je crois que j'ai fait un LinkedIn qui était à plus de 150 000 vues aussi, sur le même truc en fait, et puis après ça s'est enchaîné, ça a été très vite, les stars ont très vite augmenté encore, j'ai passé des grosses journées sur les issues, sur les PR, et on a livré plein de trucs, et puis voilà maintenant on est à 67 000 stars je crois. On est à presque un trillion de tokens éliminés avec tous les utilisateurs. Donc, 1,10 puissance, 12 tokens éliminés avec tous les utilisateurs. Ça devient assez délirant. On se demande à quoi ça ressemble. Donc, oui, oui, un beau chemin. On est dans les 300, je crois peut-être un peu plus bas maintenant, projets de tous les temps sur GitHub. Donc, Cocorico. On a réussi à faire un beau projet open source en France avant les Américains. Et voilà.
Bruno:
OK. quel an ? Alors déjà, il faut juste préciser aussi parce que cet épisode devrait être diffusé en septembre, voire peut-être même en octobre parce que j'ai déjà une file d'attente qui s'est bien remplie mais on enregistre en étant début juillet donc il faut préciser que du coup, il y a peut-être des choses qui vont se passer entre le moment où on enregistre et le moment où l'épisode va sortir, donc cet exploitant, tu as quand même évoqué du coup un trillion de tokens qui ont été économisés tu sais aujourd'hui à peu près quel est le nombre de personnes qui l'utilisent de manière.
Patrick:
Quotidienne ça dépend de la télémétrie la télémétrie, on peut la désactiver il y a une question dès qu'on l'installe je ne sais pas dire combien de gens activent la télémétrie je sais juste voir ce qui remonte de la télémétrie après il faudrait faire une estimation entre le nombre de downloads de GitHub, donc sur les dernières versions je crois qu'on est à 135 000 maintenant, de téléchargement sur une version qui est sortie. Et sur la télémétrie, je crois qu'on est à 5 ou 6 000. Donc tu vois, il y a un sacré gap. Donc quand je dis un trion, c'est juste qui est remonté avec la télémétrie. En vérité, c'est beaucoup plus.
Bruno:
Donc pour revenir un peu sur l'origine de RTK, est-ce que tu as dû un peu, on va dire, décortiquer un peu comment est-ce que fonctionnait Claude pour comprendre, à quel moment il allait cramer du toquel, entre guillemets, pour rien, pour aller te brancher au bon endroit ou tout ça était relativement accessible ?
Patrick:
En fait, ça ne fait que six mois. Et il y a plus de 150 contributeurs. Donc, il y a eu... Au début, j'ai codé sur la partie de mes commandes. Après, Florian a codé pas mal sur des commandes et des gains. Et puis après, en fait, ça s'est enchaîné. Il y a plein de gens qui ont mis des PR. Et on a passé beaucoup de temps à vérifier toutes les commandes qui arrivaient, à vérifier. Donc on a un benchmark, on vérifie combien ça économise de tokens, etc. On est allé trop loin, je crois, au bout de deux, trois mois. Et après, on s'est dit, il y a eu des consommations, des cuts qui allaient trop loin. Donc, on est revenu en arrière. Et là, on refait des benchmarks aussi sur toute la partie des commandes et sur la partie compréhension des LLM qu'on va certainement rendre public. Donc, voilà, ça s'est passé comme ça, en fait. Donc, ça a été très vite. Et puis, on a appris de ce qui se passait sur la partie... Quand tu fais un cargo test, c'est assez simple à comprendre. Tu suppliques une ligne où c'est écrit OK. Il y a des trucs où c'est beaucoup plus compliqué, en fait. Et par contre, après, oui, il y a eu toute la partie hook qui maintenant a été faite sur plusieurs IA tools. Au début, il n'y avait que Cloud Code. Donc, on mettait directement dans une markdown. Maintenant, on a changé tout ça sur plusieurs IA tools, en fait.
Bruno:
Donc, le fonctionnement, si je comprends, c'est que toutes les commandes que va exécuter Cloud sur ma machine, effectivement, pour lancer des tests ou pour parcourir une arborescence ou lire des fichiers, en fait tu vas entre guillemets intercepter le résultat de cette commande pour nettoyer un peu tout ce qui va lui bouffer du token pour rien c'est ça.
Patrick:
C'est déterministe c'est pas probabilitique parce que j'ai essayé de le faire et ça marchait pas peut-être que ça marchera plus tard si on a un M5 et puis les bons modèles etc, mais pour l'instant c'est pas le cas et donc c'est absolument des règles déterministes, qui sont faites par nous vérifiées par les contributeurs vérifiées par nous et après revérifiées sur des benchmarks en fait.
Bruno:
Donc ce qui veut dire que comme c'est déterministe il faut que tu aies la connaissance d'un panel d'outils assez.
Patrick:
Vaste parce que.
Bruno:
L'output d'un, geste ne va pas être le même que d'un PHP unit ou ce genre de choses donc il faut pouvoir s'adapter à tout ça.
Patrick:
Ouais mais tu vois là on a PHP qui arrive et ben on a reçu l'APR et c'est le corps contributeur de PHP qui fait l'APR ok donc je pense qu'il connait le truc. Donc, voilà. Donc, tu vois, c'est le genre de PR qu'on peut avoir. C'est vraiment... Les gens, ils vont pas faire n'importe... Enfin, il y en a qui font du webcoding et qui vérifient rien. Mais il y en a qui font des trucs qui sont carrément super bien faits, quoi.
Bruno:
Oui, parce que c'est ça aussi qui est fascinant dans ton projet. C'est qu'il y a quand même eu un engouement extrêmement fort. Donc, effectivement, t'as des contributeurs. La référence est quand même pas mal. Effectivement, un des corps contributeurs de PHP qui vient contribuer, on sent qu'il y a quand même du fait. Il y a du beau monde, on pourrait dire, qui va contribuer.
Patrick:
Oui, il y a des bons noms qui vont contribuer.
Bruno:
Comment tu expliques ce succès-là ? Tu penses que tous les développeurs et développeuses veulent utiliser CloudCode, mais n'ont pas forcément 4000 euros à lâcher tous les deux mois en budget token ?
Patrick:
Moi, du retour que j'ai eu des utilisateurs, puis même des gens qui me disent « c'est souvent bravo, c'est super, machin truc », donc ils sont très contents du produit, ils l'installent, ça marche, et ça correspond à ce qui s'attendait en fait. C'est toujours le retour que j'ai en général.
Bruno:
Et puis ça revient aussi en fait, c'est faire revenir un peu le principe qu'on essaie d'appliquer tous en tant que développeurs ou développeuses, c'est le keep it simple stupid. Il faut arrêter en fait de charger la mule avec des tas de considérations et autres. Parfois il faut juste effectivement simplifier un peu ce qu'on prend en considération.
Patrick:
Ouais, alors après les commandes elles avaient été faites pour les humains. Comme tu l'as dit au début, on est revenu au mode où le coût du mot, maintenant va coûter très cher et de plus en plus cher donc c'est ça qui fait que RTK a été positionné au bon moment au bon endroit puis après on était les premiers juste dans l'explosion parce que je me souviens quand j'ai commencé, j'étais sur des Slack donc des DevWavevi que tu connais et, il y avait quand même une sensation d'early adopter sur Cloud Code au début, Et là, quand je suis revenu dans des co-working ou quoi, 80% ou 85% des gens utilisent CloudCode. Et maintenant, c'est quoi ? T'as encore lancé un Visual Studio ? Enfin, un Visual Code. Pourquoi ? Donc, il y a eu une bascule quand même super rapide, je crois en 6 mois, qui est assez incroyable.
Bruno:
Il faut dire aussi que CloudCode a quand même amené un truc, parce que tu l'as dit, quand t'as fait tes premiers tests il y a un an sur Jimmy Lai, c'était sympa. Moi, quand j'ai commencé à bosser avec Cursor, je l'ai déjà dit plusieurs fois sur ce podcast, j'avais la sensation que c'était, un autocompli sous stéroïde.
Patrick:
Mais j'avais pas.
Bruno:
La sensation de quelque chose de vraiment alors que quand tu passes à Cloud Code moi j'ai commencé en octobre-novembre je crois il y avait un step qui a été.
Patrick:
Franchi.
Bruno:
Qui était colossal il y a forcément un moment moi tous les devs que j'ai connus qui étaient réticents sur l'usage de l'IA quand ils ont commencé à tester Cloud Code on change tous d'avis.
Patrick:
C'est vraiment impressionnant il n'y a pas d'autre mot à ça et ça transforme, je pense qu'on se rend pas encore compte à quel point ça transforme tous les métiers en fait parce que là on parle des développeurs mais nous, j'ai déjà créé une boîte au mois de mars pour la partie RTK Cloud donc on commence à avoir des sociétés et en fait tout le monde est en train d'utiliser CloudCode mais du CEO, du marketing, du sales, enfin partout quoi en fait et là enfin le... Enfin, je ne sais pas ce que ça va donner, mais c'est incroyable la capacité que tout le monde va avoir à faire plein de choses.
Bruno:
Alors oui, ça, c'est quelque chose. Alors je ne peux pas dire qui me l'a dit parce que l'info est plus ou moins confidentielle. Mais il y a des gens qui ont constaté qu'un des changements de paradigme qui a aussi amené Claude, c'est qu'effectivement, comme Claude est aussi accessible en mode agent classique et puis aussi CloudCore et compagnie. Il y a les CEOs qui souvent l'utilisent aussi, les CFO, les CMO qui vont s'y trouver, qui font plein de choses avec Cloud et qui du coup vont pousser auprès des développeurs pour utiliser CloudCode. Et ça, c'est assez nouveau que ce type d'outil qui soit pertinent pour les développeurs soit proposé par des gens qui ne sont pas issus du monde de développeurs. Et donc ça a changé pas mal de choses dans l'écosystème et dans les marchés de ces outils.
Patrick:
Et ça crée... Un changement sur la partie dev qui va finalement, on a l'impression qu'il va être le garde-fou de toutes ces personnes ou tous ces gens qui vont faire plein de choses, en fait, mais qui connaissent pas. Ils connaissent très bien leur métier. Ils connaissent très bien ce qu'ils veulent. Ils connaissent très bien comment améliorer les choses, mais ils savent pas comment le déployer, comment le sécuriser, etc. Donc le métier de dev va changer par rapport à ça. Quand on dit le métier de dev va disparaître, on entend souvent ça, on aura moins de devs et tout. Je ne suis pas sûr. Après coup, je ne suis pas sûr.
Bruno:
Il va changer, mais je pense qu'on aura plus de gens qui feront ce que sera le métier plus tard que ce qu'on en a aujourd'hui.
Patrick:
Et peut-être spécialisé dans certains domaines aussi, sur certaines choses plus que généralistes.
Bruno:
Pour revenir du coup sur RTK mais juste en restant quand même un peu sur la partie cloud de général est-ce que du coup avec, RTK est-ce que ça peut aussi avoir un impact sur cloud cowork qui a aussi tendance à les taper un peu partout sur une machine ou est-ce que ça pourrait éventuellement aller améliorer les performances de cloud cowork.
Patrick:
Là on est en train de faire un truc pour cloud desktop pour que ça soit directement sur la partie enfin à l'intérieur de la box qui est utilisée par cloud desktop parce que ça ça a fonctionné pas donc en oui on va essayer de l'étendre à plus, et puis d'étendre aussi la compression parce qu'aujourd'hui on est juste sur, l'output des tokens d'ailleurs donc on va essayer d'augmenter cette partie là en fait pour avoir plus d'outils en fait.
Bruno:
Pour revenir aussi sur l'historique, parce que tu as évoqué le fait que tu avais au début aussi avec des LLM et que tu avais vu que ça ne marchait pas, et tu as évoqué le côté déterministe, j'ai quand même envie de dire que se dire en 2026 que tu préfères faire des regex plutôt que de passer par un LLM, ça paraît antinomique ou presque arriéré, ou archaïque, pardon, c'est ça le mot que je cherchais. Tu peux nous expliquer du coup un peu comment ce cheminement s'est fait ?
Patrick:
C'est par la rapidité, en fait. Comme je t'ai dit, c'est juste que ça ne marchait pas en termes de rapidité. Je crois qu'on était sur... Alors, sur mon poste, j'avais un M2. On était à 2 ou 3 secondes sur un LM qui était assez puissant pour comprendre qu'il pouvait éliminer certains trucs qui étaient nécessaires. Donc, ce n'est pas du tout faisable, en fait.
Bruno:
C'était juste une question de latence, pas tant de qualité des résultats derrière.
Patrick:
En fait, plus tu mets un modèle, plus ça pouvait donner quelque chose mais encore c'est vrai que comment il sait pour un terraforme comment il sait pour un php comment il sait pour, à creuser mais c'est pas pour tout de suite mais là on est sur sur sur des temps extrêmement rapide avec rtk parce que c'est du reste et puis c'est des règles, donc ça fait le job maintenant c'est vrai qu'il y a plein de commandes et du coup il y a plein de choses, il y a plein de PR il y a plein d'issues parce qu'il y a plein de commandes, il y a plein d'arguments donc oui.
Bruno:
Et alors sur l'usage de ce LLM local, je sais pas si t'as vu je crois que c'était la semaine dernière ou la semaine d'avant je sais pas qui, je sais plus qui a annoncé un LLM avec un mode de diffusion qui permet du coup de balancer plusieurs milliers de mots en fait par seconde.
Patrick:
C'est à San Francisco, c'est une boîte mais ça fait déjà un mois ou deux je l'avais testé en ligne c'est incroyable.
Bruno:
Ça a tous les mots d'un coup et est-ce que du coup ça pourrait remplacer, ce mode de regex que vous avez aujourd'hui ou est-ce que tu penses que c'est peut-être trop tard pour...
Patrick:
De toute façon on n'est qu'au début je pense, je pense que j'ai ouvert un marché on va dire ce que j'ai remarqué c'est qu'on n'en parlait pas trop et maintenant c'est la folie des tokens les prix ils ont augmenté aussi donc on en parle partout, oui RTK va évoluer on va évoluer sur les produits on verra bien ce qu'on pourra faire en termes de matériel peut-être même il y aura des nouvelles puces qui vont sortir avec Mac qui seront juste incroyables et on pourra faire des choses qu'on ne peut pas faire aujourd'hui, en tout cas RTK est sur la partie post, plus que sur une partie API donc, ce que je veux dire c'est que ça peut être traité l'input, l'output directement sur le post de manière sécurisée sans que nous, on ait aucune information de quoi que ce soit. Ce qui ne sera pas possible avec une entreprise qui vous propose une API, en fait. Et puis, du coup, c'est absolument pas pareil, quoi.
Bruno:
Et puis, du coup, les données partent, quoi qu'il arrive.
Patrick:
Nous, tu restes sur le poste, en fait. Si tu fais avec une API...
Bruno:
Ça part chez quelqu'un.
Patrick:
Ça part chez quelqu'un, et il faut que tu lui fasses confiance.
Bruno:
En fait. Juste vite fait, RTK, tu peux nous rappeler l'origine des trois lettres ?
Patrick:
Rust Token Killer. Ça a toujours été écrit en Rust ? Ouais, toujours. Sauf les deux trucs qui étaient avant, quand ils sont partis à la poubelle, où c'était du biton. Mais non, Rust Token Killer.
Bruno:
Et pourquoi le choix de Rust, dès le début ?
Patrick:
Parce que j'avais fait quelques programmes sur Rost, que je trouvais déjà incroyables en termes de rapidité. Et puis le système de mémoire, ça m'avait bluffé par rapport à d'autres langages que j'avais faits. Et puis, je voulais changer. Du coup, je me suis dit, c'est parfait, ça va super vite et tout. Alors, j'avais commencé à réfléchir à ZIG. J'avais fait quelques programmes en ZIG. Sauf que c'est vachement bas. Et il n'y a pas beaucoup de framework ou d'autres trucs. Donc, je me suis dit que ça allait être bloquant. Donc, là, je n'ai pas pris ZIG.
Bruno:
Après, Rust avait toujours été reconnu comme étant un excellent langage. Extrêmement robuste et très agréable à utiliser. Et je crois qu'avec l'arrivée de Cloud Code, en fait... Parce que ça s'adapte extrêmement bien au LLM, le Rust avec son compilot.
Patrick:
Franchement, là, quand on fait des trucs, on fait tout en Rust. Pourquoi ? J'ai eu plusieurs expériences de créer des choses. Je le fais depuis un peu le début de ma carrière professionnelle. J'ai fait des trucs en C Sharp, C Sharp Blazor. J'ai fait des trucs en OGS, en Python. Et en fait l'élème ça permet même si tu connais pas hyper bien le langage d'avoir un truc qui est fonctionnel, et très rapide très petit versus tu vas faire du Node.js tu vas être 10 fois plus gros et en fait la complexité du langage, est-ce qu'elle a encore est-ce que c'est encore un frein en fait je dis pas de faire de l'assembleur ou du C++ mais en tout cas si on peut avoir la même chose qu'avec du Python, avec un truc qui fait 5 MB et qui va 10 fois plus vite, quel est l'intérêt de faire du Python ?
Bruno:
Je trouve qu'il y a un truc que je note sur la popularité de Rust. C'est que comme ils ont un compilateur qui est extrêmement verbeux, qui explique énormément de choses sur pourquoi ça ne compite pas et compagnie, pour un LLM, c'est de l'or, cet output. Je trouve que c'est hyper adapté. Et à mon avis, c'est un des facteurs de l'explosion des succès de Rust. C'est l'arrivée de CloudCode et de tous les confrères qui sont arrivés derrière.
Patrick:
Oui, c'est vrai. Je ne l'avais pas vu comme ça, mais c'est carrément vrai.
Bruno:
Et d'ailleurs aussi sur les effets de bord, parce que le principe de base de RTK, c'est de voir sa facture moins exploser, ou en tout cas de pouvoir avoir des sessions qui durent un peu plus longtemps.
Patrick:
Enfin, diminuer son contexte aussi.
Bruno:
Oui, parce que justement, c'est ça que j'allais dire, c'est qu'on assert des contextes Windows qui explosent complètement aujourd'hui avec les différents modèles, mais de ce qu'on voit, c'est quand tu mets un million de tokens dans ton contexte, tout ce qui est au milieu n'est pas forcément hyper pris en considération, et donc toi, en nettoyant tout ça, tu permets aussi au LLM d'être plus pertinent, parce qu'il y a moins de bruit.
Patrick:
Tu fais ton cargo test à mille lignes, t'enlèves mille lignes de tous tes tests, est-ce que ça sert ? Sinon, c'est répété à chaque requête à chaque fois. Et donc oui, il y a des études qui disent que plus tu diminues ton contexte, plus tu auras une performance en fait. Après, il faut que ça soit bien équilibré, et c'est ce qu'on regarde côté RTK, pour que tous les élèves comprennent et qu'à un moment donné, ils ne se disent pas « non, je ne comprends pas ». Ceci dit, à chaque fois, il peut rappeler aussi la commande entière si jamais il ne comprend pas en fait.
Bruno:
— Parce que oui, donc vous faites des benchmarks sur lesquels vous mesurez, j'imagine, autant la quantité de tokens que t'économises que la qualité de la réponse qui est fournie derrière.
Patrick:
— La compréhension du LLM, oui. Et après, on va intégrer aussi... Oh, ça va arriver. Des notions d'agressivité, de compression, en fait, pour les gens qui veulent un peu moins, un moyen ou plus agressif, en fait. Et puis ça dépend aussi de l'usage entre Data Analyst, Ops, Dev, etc.
Bruno:
Comment est-ce que tu mesures la qualité de la compréhension du LLM ?
Patrick:
Eh bien, on déroule... Alors c'est très compliqué. C'est très compliqué. J'imagine. Parce que c'est non déterministe, justement. Et c'est un travail qu'on fait avec Adrien. Et, globalement, on déroule une commande. On demande au LLM, qu'est-ce que tu as compris dans le output, ça correspond à quoi ? Et on vérifie que ça correspond à ça. Mais en fait, on voit des fois des benchmarks, on dit, j'ai fait un benchmark, RTK fait ci, fait ça, etc. Ou la compression, c'est ci, c'est ça. En fait, il faut le faire sur des sessions longues, moyennes, courtes, et c'est jamais la même chose. Et donc, en fait, c'est vraiment un travail assez compliqué. Je pense que limite à un moment donné, il faudrait se dire, je ne sais pas avec mes concurrents, mais en tout cas sur ceux qui sont sur la compression de token de se dire, on va créer une espèce de norme de labo, de je ne sais pas quoi pour dire comment on mesure vraiment la compression de token, c'est pas un gars qui se lève un matin sur Twitter et qui dit j'ai vérifié la compression de token, ça ne marche pas pour machin mais moi ma solution que je viens de sortir, elle marche bien. C'est un sujet qui est compliqué et la compréhension aussi parce qu'on peut avoir une bonne compression mais une très mauvaise compréhension. Et du coup, la qualité, elle va avec la dégradation de ce que tu enlèves, en fait. Et c'est encore plus dur. Alors, c'est assez simple sur les output shells, on va dire. Parce que bon, il y a des commandes qui sont très verbeuses. Mais c'est encore plus dur sur un texte. Tu vois, si on prend directement un texte d'input, on va dire, je vais le résumer, comme on faisait au collège ou au lycée. Et je vais enlever carrément des morceaux. Mais alors, la compréhension, là, qu'on ne s'est pas encore attaqué à ça, mais on va le faire. Il y a déjà des solutions qui le font. Je ne sais pas comment ils mesurent la qualité derrière après. Donc ce sera un vrai sujet.
Bruno:
Cette mesure de la qualité, de la compréhension du coup du LLM, c'est un truc que tu avais dès la version 1 où tu as été obligé de t'y atteler parce qu'en fait...
Patrick:
Pas du tout. Je l'ai fait pour moi et du coup, moi, je n'ai pas eu de soucis. Et après, en rajoutant des commandes, on a eu des commandes qui bouclaient, on a eu des retours et on a eu des échoues. Oui, oui, c'est des trucs qu'on a appris au fur et à mesure. On va dire on était novice dans la compression de token maintenant on commence à monter en expertise sur ce sujet là et comme tu peux te dire je fais rédige moi une api en rust, et puis tu le fais une fois puis voilà il a répondu ça j'ai eu telle compression super mais non mais en fait tu le fais cinq fois c'est pas pareil si tu fais dix fois c'est pas pareil si tu fais sur un truc qui est super long c'est pas pareil, et donc en fait faut apprendre sur comment les lm traitent tout ça et comment tu peux benchmarker tout ça. C'est un vrai sujet.
Bruno:
Est-ce que du coup, c'est des logiques de compression qui sont similaires à ce qu'on retrouve sur la compréhension d'images avec les formats JPEG, PNG, tout ce qu'on peut imaginer, ou la compréhension type ZIP ?
Patrick:
Non, pas du tout.
Bruno:
La compréhension, c'est des sujets qu'on a depuis longtemps en informatique.
Patrick:
Pas du tout. En plus, il y a une autre problématique, c'est le cache. Cloud Code fait repayer beaucoup plus cher quand tu exploses le cache. Donc, il faut faire attention à ça mais il y en a enfin tu pourrais te dire je fais une compression type oufman où je récupère tu sais ce qu'on a fait à la fac mais je vais faire un tableau de correspondance et puis je vais je dès que j'ai les mots je vais faire si je vais faire ça, Mais si tu prends la requête qui est arrivée et puis tu t'amuses à faire ça, tu exploses ton cash et du coup, tu vas repayer d'un coup toute la partie cash. Et du coup, les requêtes suivantes, il faut qu'elles correspondent à cette requête que maintenant tu as changée avec ton tableau de compression et ça ne marchera pas, en fait. Donc non, ce n'est pas pareil.
Bruno:
OK. Donc Théo, vous êtes obligé de, je ne vais pas dire de réinventer la roue, mais en tout cas d'avoir une approche de compression différente de ce qui a été fait jusque-là.
Patrick:
C'est tout un domaine qui démarre en fait je pense et il y a déjà maintenant des gens qui s'y mettent aux Etats-Unis sur ça et d'autres en France, et on verra bien où ça va nous mener en fait.
Bruno:
Est-ce que du coup ça vous amène à vous poser des questions, alors je vais pas dire ésotériques parce, que tu as pris le cas de quand on était au collège et qu'on devait faire un résumé de texte c'est ça en fait votre sujet, c'est qu'il faut résumer le sens, enfin il faut réduire la taille d'un texte sans en perdre le sens ce qui effectivement fait des logiques un peu différentes de réduire la compression d'une photo, qu'est-ce que je sais pas ça t'a amené à t'intéresser à des sujets qui sont plutôt de la littérature ou des, c'est pas de l'écriture symbolique mais il y a un truc en philosophie qui permet aussi de représenter des éléments logiques je sais pas si du coup tu vas chercher dans les endroits complètement non.
Patrick:
Mais je vais peut-être le faire, bonne idée non non justement on est en plein dedans, parce qu'on était vraiment nous sur les output shell, là on démarre les nouvelles méthodes de compression donc là on est en plein dedans à réfléchir exactement ce qu'on va faire sur cette partie là.
Bruno:
Parce que donc en fait au début tu simplement tu retirais des parties, si on prend les tests effectivement tu retires les tests qui sont ok mais en fait il faut aussi pouvoir c'est pas juste retirer des choses parfois il faut essayer de réduire la place qui est prise.
Patrick:
En fait sur ça dépend de ton utilisation tu prends des développeurs, ça marche très bien parce qu'ils font beaucoup de commandes, des développeurs Go ou Rust qui font beaucoup de tests, etc. Ça va marcher très bien. Puis maintenant, tu prends un Data Analyst ou tu prends un SEL sur Cloud Desktop. Ce n'est pas du tout la même utilisation. Tu vas avoir beaucoup de reads, beaucoup de greppes peut-être, surtout du read, en fait. Et du coup, c'est beaucoup de texte. Et du coup, il va falloir faire un algorithme qui est complètement différent par rapport à ce qu'on avait pour la partie développeur, en fait.
Bruno:
OK. Sur cette évolution des règles, t'as un projet aujourd'hui avec beaucoup de contributeurs. Est-ce que t'as dû poser des règles sur l'évolution des règles ? Comment s'est construit cette communauté et toutes ces contributions ?
Patrick:
Au fur et à mesure, oui, on a mis des règles pour contribuer, mais on se pose encore des, Je ne sais pas comment, et je pense qu'il y a beaucoup de gens sur la partie open source qui se posent ces mêmes questions. Je ne sais pas si tu as vu le gars de Zig qui a complètement interdit les PR faites en IA. Bon, déjà, je ne sais pas comment il fait. Comment il sait que c'est fait en IA ? Mais c'est surtout qu'on a des PR qui sont, enfin, des contributeurs qui mettent des PR maintenant avec de l'IA qui n'ont pas du tout de test, etc. Donc il faudrait trouver une espèce de méthode où on dit, avant de contribuer, il faut bien vérifier ci, bien vérifier ça, etc. Donc la qualité, il y a des très bonnes qualités, puis il y a des PR où c'est plus compliqué, en fait. Tu me diras, avant c'était peut-être le cas aussi, mais dans une moindre mesure, là il y en a vraiment beaucoup, en fait.
Bruno:
Ça je trouve assez surprenant, parce que tu n'es pas le premier à me le dire, c'est que malgré le fait qu'on utilise de l'IA qui génère du code, qui peut chier des milliers de code sans problème les devs ne génèrent toujours pas de test alors que je trouve que la relation au test, chez les développeurs et développés c'est quelque chose de très particulier parce que on est tous d'accord pour dire que les tests c'est nécessaire et quand il n'y en a pas on gueule parce qu'on sait que c'est chiant et pourtant à l'époque on n'en faisait pas parce que ça nous cassait les pieds et aujourd'hui qu'on a des outils qui peuvent les plondre, à la volée on n'en fait toujours pas.
Patrick:
Simplement parce que Maintenant, t'as plus de devs qu'avant, en fait, parce que c'est plus simple de devs, en fait. Tu vois, n'importe qui peut faire du dev, en fait. Avant... Enfin, du coup... Tu peux rentrer dans le monde du dev parce que c'est vraiment plus compliqué, mais tu n'as peut-être pas toute la méthodologie qu'il te faudrait pour fournir une bonne qualité. Et donc c'est là qu'on voit maintenant la différence entre un bon dev qui va vraiment performer et en plus fournir du code qui est bon, qui est maintenable, facilement changeable par rapport à un autre qui va donner une commande. Et puis après, déjà, l'algorithme, il n'est pas forcément bon. Et puis, en plus, c'est absolument pas maintenable, en fait. Et donc, c'est juste sur la méthode, en effet, qui n'est pas diffusée partout.
Bruno:
Donc, tu penses que les gens qui ne génèrent pas leurs tests, ce sont des non-devs ? Enfin, des non-devs. Je ne sais pas. Des gens qui ne sont pas issus de la formation, on va dire ?
Patrick:
Ils n'ont pas la même pratique que d'autres devs, en fait, qui, eux, font... Ils ont tous le même outil. Donc, ils n'ont juste pas les mêmes méthodes, je pense, à un moment donné. Après peut-être que ça sera directement intégré dans Cloud sur certaines méthodes, enfin après tu peux déjà le faire avec des skills etc j'ai pas de réponse à ça mais on voit très bien qu'il y a des PR qui sont super bien faites et d'autres ça va pas.
Bruno:
Alors du coup tu as parlé des skills effectivement c'était ma question, est-ce que du coup dans le projet RTK t'as des skills pour que en fait tout le monde qui génère des PR via un agent quel qu'il soit, du coup en fait il y a une skill qui lui permet de faire les choses comme tu aimerais que ce soit fait ?
Patrick:
Alors, on en a, mais je t'avouerais qu'on ne les a pas en forcés. On a des codes review, etc., des modes d'agents et tout. Mais oui, on n'a pas dit aux gens « vous êtes obligés de faire ci ou obligés de faire ça, en fait ». D'ailleurs, ce serait un truc que je devrais faire peut-être avec d'autres gros projets open source, c'est savoir comment ils gèrent toute cette marée de PR qui arrive. Parce que tu peux avoir un mec qui te fait 10 PR et il n'y a rien qui va. Et comment tu traites ça ? Parce qu'il faut passer ton temps à regarder et tu ne découvres pas tout de suite que non, ce n'est pas bon. Et le pire des fois c'est que tu as des PR où t'as un titre qui va changer le bon truc mais derrière il va te rajouter plein de choses parce que Lya elle aime bien faire ça en fait ah mais j'ai vu un autre truc je vais faire ça elle.
Bruno:
A une pratique de Boy Scouts on pourrait.
Patrick:
Dire c'est ça ouais et du coup elle te rajoute un truc qui a rien à voir et si tu regardes pas bah c'est parti c'est compliqué c'est compliqué.
Bruno:
Parce que du coup toi tu te retrouves quand même en quelques mois parce qu'au final t'as commencé en janvier tu te retrouves en quelques mois avec un projet avec énormément de stars et donc forcément pas mal de contributions.
Patrick:
Et
Bruno:
Pas mal de vues, tu avais déjà eu lancer des projets open source qui avaient eu un tel succès ou participer à des projets open source qui avaient eu un tel succès ?
Patrick:
Le plus gros, c'était Kexa. On a fait 350 stars.
Bruno:
Une autre échelle, on va dire.
Patrick:
Une autre échelle. Donc, on avait quand même vu un peu... Mais pas comme ça. À un moment donné, je crois qu'on était une issue par heure, une PR tous les deux heures, un truc comme ça. Ça, c'est une marée, en fait. Bon, après, maintenant, on a des gens, comme Nicolas qui est arrivé sur le projet qui nous aide pour maintenir Adrien qui est une personne avec qui je travaille depuis 4 ans qui vient dans la société pour travailler sur la partie open source, donc voilà on va s'étoffer petit à petit et puis on va déblayer toutes ces issues, toutes ces PR et puis rajouter plus de projets plus, de sujets sur la partie compression et sur la partie pro pour nous faire vivre aussi en fait.
Bruno:
Et structurer peut-être aussi une communauté de corps contributeurs ou des choses comme ça pour essayer de continuer à faire vivre le projet parce qu'en mode open source aussi quand même, ça va rester à priori.
Patrick:
Il y en a à chaque fois qu'ils nous disent qu'ils n'auraient bien contribué mais on n'a pas encore trouvé justement on était en train de se dire que je vais faire un appel à contribution, à savoir qui voudrait mais c'est dur, enfin il faut trouver les bonnes personnes quoi. C'est pas évident.
Bruno:
Et puis tu te retrouves direct propulsé dans la cour des grands presque j'ai envie de dire quoi.
Patrick:
Et il ne faut pas faire de conneries.
Bruno:
Clairement. Comment est-ce que toi tu vois l'avenir dans la guerre du token ? Enfin je ne sais pas, pour toi est-ce que le token va rester un truc primordial, central ? Est-ce que les coûts vont complètement exploser ? C'est quoi ta vision de ce truc là ?
Patrick:
Je pense que oui malheureusement. Enfin après si vous voyez le prix de la RAM je ne vois pas comment ça pourrait baisser. La RAM faisant marcher les machines et les GPU enfin... Non, je pense que ça va augmenter pendant un moment. Après, on voit clairement que Mac va se positionner sur des machines très puissantes pour faire du LLM local, parce qu'ils ont pris une personne qui, en gros, fait du CPU-GPU, il ne fait pas du logiciel. Donc il faut voir comment ça va se passer aussi avec les LLM open source des Chinois, qui sont maintenant performants mais ils sont quand même pas enfin de toute façon derrière en termes de hardware t'as plein de cartes H100 ou H200 pour ce qu'on consomme sur Cloud Code versus un Mac, il y a quand même une grosse différence pour le moment donc je pense que ça va rester quand même encore un petit moment comme ça.
Bruno:
Est-ce que tu penses qu'on va atteindre un moment d'un prix du token tellement élevé qu'on va devoir se poser la question parfois de est-ce qu'on code à la main ou est-ce qu'on code avec de l'IA ?
Patrick:
Et... Ça dépend pour qui. Pour les entreprises, s'ils ont de l'argent, ben non. Pour les développeurs solo, oui, certainement.
Bruno:
Ça veut dire qu'on a certains qui vont avancer extrêmement lentement par rapport à d'autres. Donc il y aura un désavantage extrêmement fort, au moins fortuné, on va dire.
Patrick:
Oui, tout à fait. Après, c'est un sujet qu'on discute avec des gens à Lille. Ceux qui vont enfin ceux qui vont avoir le pouvoir c'est ceux qui ont l'infra, et c'est eux qui vont quand même tout rafler entre guillemets, parce que si t'as l'infra et que ça te coûte pas cher bah t'as les modèles et si t'as les modèles et puis t'as la capacité à développer bah finalement tu peux copier rapidement et fournir rapidement à n'importe qui je pense qu'Elon Musk il a compris ça en fait, et donc oui c'est ce qui risque d'arriver donc les plus Les personnes qui ont plus d'infrastructures, tu le vois avec Cloud Design. Il a sorti le produit comme ça. Je serais curieux de voir les parts de marché maintenant par rapport à Figma. Ils ont sorti un produit comme ça. Et demain, je pense que tu auras peut-être du Google ou d'autres trucs qui vont sortir des produits qui vont destructurer des marchés très rapidement.
Bruno:
Tu parles d'Elan Musk et du coup, ça me fait penser à Curseur. Ça me fait penser à une question que j'ai pas pensé à te poser parce, que RTK a commencé pour Cloud mais aujourd'hui c'est pas dispo que sur Cloud, à quel point ça a été complexe de se passer à ces autres outils où au final, ils ont tous copié Cloud et du coup ça fonctionne un peu pareil.
Patrick:
Ils ont bien copié Cloud et ça fonctionne un peu pareil, mais il y en a qui n'ont toujours rien du tout, en fait. Après, ça a été assez complexe dans le sens... Après, il y a quand même nos contributeurs qui l'utilisent et de co-ils font des PR. On espère qu'ils ont bien vérifié le truc, mais on revérifie, nous, en installant les produits et en vérifiant que ça marche. On a eu quelques quacks sur certains produits, mais je crois qu'on est à 14 maintenant. Il y a Tools supporté.
Bruno:
Je ne pense même pas en connaître 14.
Patrick:
Eh bien non, il y en a un peu de tout. Comme du windsurf, moi je ne l'utilisais pas du tout, ou il y a d'autres produits.
Bruno:
Ok, intéressant. Alors du coup, c'est quoi l'avenir pour RTK ? Tu nous as parlé très brièvement, tu as glissé au milieu d'une phrase, c'est solutions entreprises. Mais c'est quoi du coup l'avenir de RTK ?
Patrick:
Donc nous, j'ai eu pas mal de retours. À partir du mois de mars, j'ai créé une société. Puis j'ai commencé à développer ça. C'est pour ça que j'ai moins contribué sur la partie open source depuis le mois de mars. Une solution pour les entreprises donc aujourd'hui les développeurs sont plus en mode silo là l'idée c'est vraiment d'être en mode d'avoir une tour de contrôle qui permet de voir tout ce qui se passe en termina dans ton entreprise sur de l'observabilité, et puis positionner des règles de policy ou de skills, avoir du rewrite de secret à la volée ou peut-être demain des données confidentielles qui sont rewrite à la volée pour envoyer donc on est en train de se mettre sur un panel complet pour aider les entreprises sur la partie IAO.
Bruno:
Est-ce qu'il y a des recherches ? Est-ce qu'il y a des recherches qui sont faites sur des je ne sais pas, des risques cyber parce que comme il y a quand même une réécriture, de ce qui est envoyé à un LLM qui va générer du code derrière il peut y avoir des gens un peu malveillants qui arrivent peut-être d'une certaine manière à injecter des choses soit dans les règles de RTK soit qui arrivent, enfin tu vois, comment est-ce que vous gérez ces sujets-là ?
Patrick:
Il y a des gens qui nous envoient des CVE qui sont confidentiels, qui arrivent sur GitHub, puis après on les traite, et puis après on fait des releases. Mais oui, tous les logiciels ont des CVE depuis tous les temps, et RTK, oui, ça arrive. C'est sûr.
Bruno:
Ça a été quoi la CVE dont tu peux nous parler, où tu te dis, ah ouais, quand même, il y a des gens qui sont malins d'avoir réussi à créer ce truc-là, tu as retrouvé ce truc-là ?
Patrick:
— Ah non, on n'a pas eu de 9.5 ou de 9.8. Après, c'est toujours le LLM obéi. Donc tu vas injecter des règles. Ou après, si tu as accès au poste, tu vas pouvoir écrire des trucs. Mais nous, on est déjà sur le poste. Il faut avoir un certain droit pour changer le truc. Mais oui, il y a des gens qui passent leur temps à chercher et à trouver des trucs. C'est leur boulot. Non, j'en ai plus en tête comme ça.
Bruno:
Ça marche. Top. Et donc toi, l'objectif, maintenant, c'est de pouvoir vivre de ce projet-là, aussi longtemps que l'écosystème le permet.
Patrick:
Oui. Et puis toujours avancer sur l'optimisation des tokens, l'optimisation des LLM. Et puis fournir une couche sur la partie entreprise. Parce qu'on voit pour l'instant que le travail est en silo et nous, on aimerait bien un peu exploser ça et faire augmenter la possibilité d'observabilité sur toute l'entreprise, en fait. Et donc, en même temps, continuer à contribuer sur la partie OSS. Donc, il faut absolument avoir un produit payant, sinon on ne pourra pas vivre de ça, en fait. Donc voilà, on améliorera la partie open source en même temps que la partie enterprise qui fournira l'argent pour la partie open source.
Bruno:
Et l'actualité est plutôt en votre faveur. Je ne sais plus quelle boîte a annoncé il n'y a pas très longtemps qu'ils ont consommé quasiment la totalité de leur budget. C'est Uber. Uber, c'est la question.
Patrick:
Ouais mais en fait si tu creuses il avait fait un leaderboard à l'intérieur pour dire consommez consommez de lia à gogo et puis ils sont allés jusqu'à 25000 de l'arche pour un truc comme ça par personne et oui ils ont explosé les trucs ouais c'est que ça.
Bruno:
Forcément si tu mets un si tu gamifie le truc aux sens des développeurs et développeuses y en a qui.
Patrick:
Vont.
Bruno:
Aller gruger un peu leur capacité quoi.
Patrick:
Ça serait intéressant de voir s'ils avaient même pas des prix ou des trucs comme ça tellement ils utilisaient l'IA. Et donc là, après, je crois, s'il est faux, etc., ils se sont dit « Ouais, bon, les gars, on est allés un peu trop loin, quoi. », Les forfaits développeurs, c'est bien, parce que nous, finalement, on ne paye pas si cher que ça. Quand tu vois les coûts de Cloud Code, forfaits API par entreprise, ça coûte super cher, en fait.
Bruno:
Oui, parce que même le forfait max à 200 balles, quand tu vois la quantité de choses que tu peux faire, si tu le penses vraiment à fond, au final, pour 200 balles par mois, ce n'est pas si cher payé.
Patrick:
Non, il faudrait qu'il y ait quelqu'un qui s'amuse à faire un projet dans le 200 balles, et puis après qu'ils fassent le même projet avec la pièce et voir la différence de coût.
Bruno:
Il y a moins que ça pique.
Patrick:
Il y a moins que ça pique ouais c'est clair.
Bruno:
J'avais une dernière question qui m'a échappé c'était sur le coût des tokens, oui qu'est-ce que tu penses de j'oublie toujours son nom le CEO de Nvidia qui avait fait une interview il n'y a pas très longtemps il disait que s'il a un ingénieur, qui paye 200 000 dollars par an mais qui consomme moins de 100 000 dollars de token par an C'est qu'il y a un problème, c'est que le gars n'est pas assez productif et autres. Est-ce que pour toi le token doit devenir un nouvel indicateur de la performance des développeurs et développeuses ?
Patrick:
Non. Je dirais même que je ne suis pas un ayatollah. C'est marrant, après, je pense que comme beaucoup de devs, j'étais à fond de septembre, à fond dans l'IA, le vibe coding et tout. Mais là, je ralentis un peu plus et je me dis, ouais, il y a eu quand même des problèmes de qualité et tout. Je n'ai pas trouvé le juste milieu entre... Ah, tu vois, l'IA, c'est comme un bonbonbon ou de la malbouffe. Tu prends un burger, c'est bon, mais ce n'est pas bon pour toi, en fait. Eh bien, pour les développeurs, c'est pareil. Tu sais que c'est bon, mais ce n'est pas bon. Et on ne sait pas comment... Donc, l'histoire de dire, ouais, consommer plus de tokens, enfin, entre guillemets, acheter aussi du GPU à Google, bon ça c'est du marketing américain et ça marche bien ils ont raison mais, la vraie question c'est tu craches de l'IA est ce que c'est maintenable et est ce que derrière ça te coûte pas plus cher parce qu'il ya eu des rapports aussi qui disaient ça augmente pas la productivité, c'est compliqué c'est un nouvel outil qui vient d'arriver je suis pas sûr qu'on ait encore toutes les clés qu'on ait tout compris et qu'on est bien, on est bien capturé si on fait beaucoup plus de performance Oui, on a l'impression d'aller beaucoup plus vite, mais combien de fois on revient sur des choses qui ont été mal faites ou qu'il faut corriger, etc. Et ça, on n'arrive pas à le quantifier parce qu'en fait, on est toujours en train de coder. On voit toujours le truc qui code. Voilà, c'est mon avis.
Bruno:
Et puis en plus, on a... Tous les deux mois, il y a un nouveau truc qui sort. On a eu le AI Engineering, le AI Assisted Coding. Après, on a eu le Context Engineering. Là, maintenant, on est sur du Harness Engineering.
Patrick:
Et la Loop aussi.
Bruno:
On a un métier qui change toutes les 6 semaines à peu près donc effectivement on n'est pas encore c'est même pas qu'on n'a pas assez d'expérience il y a encore de la poussière partout la poussière n'est pas retombée.
Patrick:
Donc en fait il faut utiliser ces nouveaux outils parce qu'ils sont quand même incroyables vraiment incroyables, mais il faut rester quand même pragmatique voir si ça correspond à ce que vous faites voir si ça améliore ce que vous faites, et puis bon bah après, Il y aura des trucs bien et des trucs moins bien, mais c'est l'innovation. Et voilà, je pense pas... On reviendra pas en arrière, à mon avis.
Bruno:
Je pense pas.
Patrick:
Je pense pas qu'on reviendra en arrière. Enfin, voilà. C'est un peu... Mais c'est pas tout à fait pareil, mais... Tu sais, quand on codait en assembleur, puis après, on a commencé à arrêter de faire de l'assembleur et aller vers du C++ ou du C... Tu dis, mais vous êtes fous, vous allez plus savoir coder, etc. Bon, là, c'est une autre échelle, mais c'est un peu ça, quand même.
Bruno:
Je suis complètement d'accord. Je suis complètement aligné. merci beaucoup Patrick pour toute cette discussion j'aurais deux dernières questions pour toi qui sont les questions rituelles du podcast, la première c'est est-ce qu'il y a un contenu que tu veux partager avec l'ensemble des auditoristes ?
Patrick:
Ouais c'est un grand classique en fait c'est 1984 je pense qu'on est on est à un moment où il faut le relire effectivement.
Bruno:
Bon conseil et dernière question, la plus importante de ce podcast, Patrick est-ce que tu es plutôt espace ou tabulation ?
Patrick:
J'aurais dit retour chariot mais bon retour chariot Linux très bien.
Bruno:
Merci beaucoup Patrick merci, au revoir et merci à tous d'avoir suivi cet épisode. Je pense que là on est en septembre 2026 en tout cas quand vous écoutez cet épisode je pense que vous utilisez forcément des outils d'idées génératives, n'hésitez pas à aller, utiliser RTK parce que vraiment ça va changer la durée de vos sessions, vraiment ça vaut vraiment le coup, c'est un moyen de faire une idée aussi des économies, peut-être en passant du forfait de 200 au forfait peut-être pas 20, mais en tout cas de trouver une échelle intermédiaire. Comme toujours, je vous remercie beaucoup de partager ce podcast autour de vous. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
