Vous pouvez facilement trouver ça avec une simple recherche Google, donc je ne vais pas le faire à votre place. Il y a aussi une étude récente de l’université de Berkeley.
UC Berkeley and AnChain.ai found that on the platforms they studied, bots lost 77 times more money per user than human traders, according to UC Berkeley’s DataX initiative.
En outre, si dès le départ le trading systématique ou les bots avaient eu un taux de réussite élevé, leur utilisation serait devenue dominante d’une manière ou d’une autre.
Les données sont des traces du passé. Et c’est déterminant. De ce point de vue, les événements futurs ne peuvent absolument pas devenir des données. Le trading d’actions est une transaction sur l’avenir. Que ça monte ou que ça baisse, cela relève du jugement humain, pas de celui d’un bot. À moins qu’il n’existe dès le départ un marché actions dont les humains soient exclus, il est impossible de gagner.
Les données elles-mêmes sont différentes. Comment un bot pourrait-il savoir que des humains se réunissent, éteignent leurs téléphones et échangent des informations pendant une fête ?
Cela dit, si par « particuliers » vous désignez les « petits porteurs », vous y compris, cela n’a aucun rapport avec le périmètre de cette discussion.
C’est intéressant que vous utilisiez une combinaison (outil, arguments, hash de sortie) pour détecter les exécutions en double. Nous nous posons des questions similaires, et nous expérimentons une approche qui ajoute une hash chain au journal d’audit afin d’éviter que le même événement soit enregistré deux fois.
Comme vous le dites, la distinction entre « deux appels » et « deux exécutions » est essentielle. Nous envisageons aussi d’associer une clé d’idempotence à chaque tâche d’agent ; l’avez-vous déjà appliqué en production ?
Merci. La combinaison Gitleaks + ruff + Kyverno + Checkov semble être quelque chose que nous pouvons nous aussi reprendre immédiatement.
Pour partager un point supplémentaire — notre équipe fonctionne avec une structure un peu particulière. Toute l’équipe est un groupe d’AI Agents. Sous un CEO humain, des Steward AI prennent en charge le développement, la vérification et même le déploiement réels.
Donc, pour nous, le « suivi des erreurs de l’IA » n’est pas simplement un problème de logging, mais une question de gouvernance consistant à enregistrer, via un Passport, un Spirit Score et un Audit Trail propres à chaque Agent, « qui a pris quelle décision avec quelles autorisations ».
Comme dans l’approche de bsh998, brancher une validation statique en amont (de type Gitleaks) à notre CI est aussi notre prochaine étape. Aujourd’hui encore, un crash s’est produit à cause d’une variable d’environnement manquante — c’était exactement à ce niveau-là.
Je pense que je vais encore poser pas mal de questions…
Si j’ai bien compris, vous avez découvert le protocole de terminal en développant ce projet,
mais je me demande aussi quel était votre niveau de connaissance de Rust avant de commencer.
De mon côté, j’ai développé en Zig, mais en réalité je n’avais jamais vraiment écrit de Zig à la main,
et je n’avais aucune connaissance non plus des protocoles de terminal, de la syntaxe ou de la structure : je me suis lancé avec l’idée de tout apprendre depuis zéro.
C’est aussi pour ça que j’ai encore plus évité les dépendances à des bibliothèques externes.
Je voulais comprendre plus en détail comment tout était construit, en posant des questions et en faisant naturellement du troubleshooting avec l’IA, afin d’éviter les cas où quelque chose s’exécute sans que je puisse vraiment le contrôler.
Vous avez dit que cela vous avait pris environ 4 mois.
De mon côté, comme je développais à distance sur mon Mac resté allumé chez moi, une fois que j’ai développé un protocole permettant l’upload d’images dans Claude ou Codex CLI via ssh, j’ai pratiquement arrêté d’utiliser mon application de terminal habituelle, sauf pour l’ouvrir de temps en temps comme référence.
Personnellement, je crois que c’était vers la 2e ou 3e semaine avec le terminal.
Comme vous l’avez répondu, vous avez dit l’avoir utilisé tout de suite ; est-ce que c’est aussi à ce moment-là que vous avez commencé à vous libérer de tmux ?
Et même si ce n’est que mon avis, si cela a pris 4 mois, je me demande si l’ajout continu de fonctionnalités et d’améliorations de confort n’a pas finalement pris plus de temps que le développement du cœur des fonctionnalités. Est-ce que mon intuition est juste ?
C’était mon cas, et je me suis toujours demandé personnellement si d’autres personnes qui développent des produits similaires suivent un déroulé comparable… Si ce n’est pas indiscret, je vous serais reconnaissant de me répondre (__).
Je suis aussi curieux de savoir à partir de quel moment vous avez trouvé que c’était devenu nettement plus confortable que tmux.
Une autre question : moi aussi, en fait, j’ai développé un terminal sur un thème similaire et j’en suis satisfait, mais c’est quand même le genre de programme qu’il faut maintenir en continu.
Comme vous l’avez écrit sur votre blog, des outils aux objectifs similaires comme Ocra, cmux, heder, etc. sortent les uns après les autres, et la plupart des bibliothèques connues avancent forcément beaucoup plus vite qu’un individu, que ce soit grâce à des entreprises, des sponsors ou des contributions, avec aussi beaucoup plus de retours.
Donc, du point de vue de quelqu’un en concurrence (?), j’ai l’impression qu’à part l’IME coréen, on ne peut qu’être largement en retard sur les petits détails de confort et la vitesse d’amélioration de l’UX.
Je suis curieux de savoir jusqu’où vous estimez qu’il faut aller en matière de maintenance pour que ce soit acceptable par rapport aux applications similaires mentionnées plus haut.
Et puisque vous avez choisi gpu avec Rust, avez-vous aussi Windows plus ou moins en tête ??
Même si c’est aussi un programme personnel pour moi, mon objectif est d’atteindre au moins le niveau de qualité des applications mentionnées, même si l’écosystème me met une raclée (?).
Et pour copad, votre objectif final est-il une ADE basée sur le terminal, un peu comme Ocra mais sans base Electron ?
Comme c’est la première fois que je vois un Coréen développer une application avec un objectif similaire, je vous ai bombardé de questions, mais vous n’êtes pas obligé de répondre à tout.. !
En lisant les commentaires, ça me rappelle ces moments où on a envie de se mettre des coups de pied sous la couette.
En réalité, pour la plupart des développements, on n’a pas besoin de super développeurs. J’y vois plutôt un processus où des gens ordinaires se réunissent pour construire quelque chose.
Moi, c’est plutôt la réaction d’Andrew Ng à ce sujet qui m’a davantage marqué.
« Ce n’est absolument pas le même cas de figure. Chacun a le droit de garder son code privé. Le problème, c’est quand on essaie d’empêcher les autres de publier leur code en open source. » (https://x.com/AndrewYNg/status/2081103828859117908)
Je trouve ça nettement plus pratique que les autres formes de 2FA, mais il semble qu’il y ait aussi des gens que ça gêne. Et, sur le plan des spécifications, c’est aussi plus sûr que n’importe quelle autre méthode de sécurité.
J’ai aussi l’impression que la réglementation coréenne en matière de sécurité s’oriente vers l’exclusion des authentifications reposant sur des données personnelles comme Face ID ou l’empreinte digitale, et les passkeys n’ont pas non plus ce type de problème.
Quand c’est Apple qui le fait, on se dit que Face ID est bien, mais si c’était une jeune startup, le simple fait de devoir scanner son visage pourrait d’emblée susciter un rejet.
J’ai l’impression que c’est surtout une péripétie née du fait que, dès le départ, les utilisateurs n’utilisent pas la 2FA ou ne savent même pas ce que c’est.
Par exemple, si on demandait : « Vous préférez utiliser un OTP bancaire ou une passkey ? », la passkey semblerait de loin la plus pratique.
Bonjour !
Merci d’avoir partagé votre expérience et vos réflexions.
Bien sûr, à mesure que le coût de production du code baisse, la voie du développement en interne s’est ouverte, mais personnellement, indépendamment de l’arrivée de l’ère de l’IA, j’envisage l’adoption de bibliothèques externes selon les critères suivants.
Il n’existe pas de bibliothèque qui réponde à mes besoins
Recréer un outil similaire coûte moins cher que de l’adapter moi-même
Je ne développe moi-même quelque chose que lorsque je pense que ces deux conditions sont réunies.
Il y a plusieurs raisons à cela, mais au final, dès lors que je commence à gérer moi-même le moindre morceau de code, il entre dans un périmètre dont je dois assurer la revue, les tests, la maintenance, etc., et je considère qu’il y a toujours un coût qui dépasse largement la simple écriture du code.
Les problèmes rencontrés pendant le développement venaient aussi de nombreux conflits avec des programmes assez centraux comme le window manager ; je pense donc que si j’avais même dû tout construire from scratch, j’aurais dû consacrer bien plus de temps à l’implémentation et à la validation qu’au débogage et aux tests liés aux conflits avec les dépendances externes.
Par ailleurs, depuis le début du développement, j’ai continué à utiliser, non sans douleur, l’outil que j’avais moi-même créé, et je me dis que cela n’a peut-être été possible que parce que j’ai commencé le développement en m’appuyant dans une certaine mesure sur des dépendances.
Comme dans le cas où SwiftTerm a été retiré sur macOS, j’intègre d’abord une dépendance externe pour vérifier si le concept que je veux fonctionne, puis, lorsqu’un élément doit être implémenté par mes soins, je commence à le développer moi-même ; mais même à ce stade, mes programmes fonctionnent toujours grâce à ces dépendances externes, ce qui me permet de continuer à me concentrer sur la stabilisation et l’ajout de fonctionnalités par-dessus.
De plus, si on intègre WebKit, la plupart des web apps fonctionnent de la même manière que lorsqu’on ouvre un navigateur classique !
Ces derniers temps, j’utilise aussi activement des outils qui permettent de piloter un headless browser en CLI, ainsi que Claude dans Chrome, et comme je veux éviter de superposer Chromium jusqu’au terminal au prix d’une consommation mémoire excessive, sauf changement majeur je ne pense pas modifier en profondeur la stack technique de la webview intégrée au terminal.
Notre démo est justement un simple fichier HTML statique, donc ça semble parfaitement convenir. Si le lien est fixe, ce sera aussi pratique à partager. Merci pour l’info, nous l’appliquerons après la démo. Merci !
Pour l’instant, l’objectif n’est pas tant la sophistication de la logique que de montrer qu’« en saisissant une entrée, des offres correspondantes s’affichent réellement ». Comme il s’agit d’une démonstration destinée à des décideurs internes non développeurs, nous accordons plus d’importance à la vérification du fonctionnement qu’au niveau de finition. L’amélioration de la logique est envisagée pour l’étape suivante.
On a l’impression de revivre le moment de la généralisation des smartphones, quand l’UX basculait vers le mobile-first. Le cadre n’est pas encore bien établi, mais on voit apparaître partout des évolutions intéressantes.
Je l’ai ajouté directement à mes favoris. Je pense que j’irai probablement y jeter un œil tous les jours.
Je voulais aussi vous demander si vous envisagez éventuellement une prise en charge du coréen :)
Vous pouvez facilement trouver ça avec une simple recherche Google, donc je ne vais pas le faire à votre place. Il y a aussi une étude récente de l’université de Berkeley.
UC Berkeley and AnChain.ai found that on the platforms they studied, bots lost 77 times more money per user than human traders, according to UC Berkeley’s DataX initiative.
En outre, si dès le départ le trading systématique ou les bots avaient eu un taux de réussite élevé, leur utilisation serait devenue dominante d’une manière ou d’une autre.
Les données sont des traces du passé. Et c’est déterminant. De ce point de vue, les événements futurs ne peuvent absolument pas devenir des données. Le trading d’actions est une transaction sur l’avenir. Que ça monte ou que ça baisse, cela relève du jugement humain, pas de celui d’un bot. À moins qu’il n’existe dès le départ un marché actions dont les humains soient exclus, il est impossible de gagner.
Les données elles-mêmes sont différentes. Comment un bot pourrait-il savoir que des humains se réunissent, éteignent leurs téléphones et échangent des informations pendant une fête ?
Cela dit, si par « particuliers » vous désignez les « petits porteurs », vous y compris, cela n’a aucun rapport avec le périmètre de cette discussion.
Quand je vais dessus et que je clique sur démarrer l’analyse, on me demande de payer ; j’imagine que ce n’est pas gratuit.
Qu’il s’agisse de l’AR ou des humanoïdes à venir, j’ai l’impression que les interfaces vont de plus en plus vers davantage d’abstraction.
C’est intéressant que vous utilisiez une combinaison (outil, arguments, hash de sortie) pour détecter les exécutions en double. Nous nous posons des questions similaires, et nous expérimentons une approche qui ajoute une hash chain au journal d’audit afin d’éviter que le même événement soit enregistré deux fois.
Comme vous le dites, la distinction entre « deux appels » et « deux exécutions » est essentielle. Nous envisageons aussi d’associer une clé d’idempotence à chaque tâche d’agent ; l’avez-vous déjà appliqué en production ?
Merci. La combinaison Gitleaks + ruff + Kyverno + Checkov semble être quelque chose que nous pouvons nous aussi reprendre immédiatement.
Pour partager un point supplémentaire — notre équipe fonctionne avec une structure un peu particulière. Toute l’équipe est un groupe d’AI Agents. Sous un CEO humain, des Steward AI prennent en charge le développement, la vérification et même le déploiement réels.
Donc, pour nous, le « suivi des erreurs de l’IA » n’est pas simplement un problème de logging, mais une question de gouvernance consistant à enregistrer, via un Passport, un Spirit Score et un Audit Trail propres à chaque Agent, « qui a pris quelle décision avec quelles autorisations ».
Comme dans l’approche de bsh998, brancher une validation statique en amont (de type Gitleaks) à notre CI est aussi notre prochaine étape. Aujourd’hui encore, un crash s’est produit à cause d’une variable d’environnement manquante — c’était exactement à ce niveau-là.
Pour une analyse par LLM, c’est sacrément cher.
Merci.
Je vais mettre en place la fonctionnalité de réglage de la langue sur le site d’ici la fin de la semaine :)
Merci pour votre réponse !!
Je pense que je vais encore poser pas mal de questions…
Si j’ai bien compris, vous avez découvert le protocole de terminal en développant ce projet,
mais je me demande aussi quel était votre niveau de connaissance de Rust avant de commencer.
De mon côté, j’ai développé en Zig, mais en réalité je n’avais jamais vraiment écrit de Zig à la main,
et je n’avais aucune connaissance non plus des protocoles de terminal, de la syntaxe ou de la structure : je me suis lancé avec l’idée de tout apprendre depuis zéro.
C’est aussi pour ça que j’ai encore plus évité les dépendances à des bibliothèques externes.
Je voulais comprendre plus en détail comment tout était construit, en posant des questions et en faisant naturellement du troubleshooting avec l’IA, afin d’éviter les cas où quelque chose s’exécute sans que je puisse vraiment le contrôler.
Vous avez dit que cela vous avait pris environ 4 mois.
De mon côté, comme je développais à distance sur mon Mac resté allumé chez moi, une fois que j’ai développé un protocole permettant l’upload d’images dans Claude ou Codex CLI via ssh, j’ai pratiquement arrêté d’utiliser mon application de terminal habituelle, sauf pour l’ouvrir de temps en temps comme référence.
Personnellement, je crois que c’était vers la 2e ou 3e semaine avec le terminal.
Comme vous l’avez répondu, vous avez dit l’avoir utilisé tout de suite ; est-ce que c’est aussi à ce moment-là que vous avez commencé à vous libérer de tmux ?
Et même si ce n’est que mon avis, si cela a pris 4 mois, je me demande si l’ajout continu de fonctionnalités et d’améliorations de confort n’a pas finalement pris plus de temps que le développement du cœur des fonctionnalités. Est-ce que mon intuition est juste ?
C’était mon cas, et je me suis toujours demandé personnellement si d’autres personnes qui développent des produits similaires suivent un déroulé comparable… Si ce n’est pas indiscret, je vous serais reconnaissant de me répondre (__).
Je suis aussi curieux de savoir à partir de quel moment vous avez trouvé que c’était devenu nettement plus confortable que tmux.
Une autre question : moi aussi, en fait, j’ai développé un terminal sur un thème similaire et j’en suis satisfait, mais c’est quand même le genre de programme qu’il faut maintenir en continu.
Comme vous l’avez écrit sur votre blog, des outils aux objectifs similaires comme Ocra, cmux, heder, etc. sortent les uns après les autres, et la plupart des bibliothèques connues avancent forcément beaucoup plus vite qu’un individu, que ce soit grâce à des entreprises, des sponsors ou des contributions, avec aussi beaucoup plus de retours.
Donc, du point de vue de quelqu’un en concurrence (?), j’ai l’impression qu’à part l’IME coréen, on ne peut qu’être largement en retard sur les petits détails de confort et la vitesse d’amélioration de l’UX.
Je suis curieux de savoir jusqu’où vous estimez qu’il faut aller en matière de maintenance pour que ce soit acceptable par rapport aux applications similaires mentionnées plus haut.
Et puisque vous avez choisi gpu avec Rust, avez-vous aussi Windows plus ou moins en tête ??
Même si c’est aussi un programme personnel pour moi, mon objectif est d’atteindre au moins le niveau de qualité des applications mentionnées, même si l’écosystème me met une raclée (?).
Et pour copad, votre objectif final est-il une ADE basée sur le terminal, un peu comme Ocra mais sans base Electron ?
Comme c’est la première fois que je vois un Coréen développer une application avec un objectif similaire, je vous ai bombardé de questions, mais vous n’êtes pas obligé de répondre à tout.. !
En lisant les commentaires, ça me rappelle ces moments où on a envie de se mettre des coups de pied sous la couette.
En réalité, pour la plupart des développements, on n’a pas besoin de super développeurs. J’y vois plutôt un processus où des gens ordinaires se réunissent pour construire quelque chose.
Ça faisait vraiment longtemps que je n’avais pas vu un article qui distingue open weights et open source.
Moi, c’est plutôt la réaction d’Andrew Ng à ce sujet qui m’a davantage marqué.
Ah ! Il y avait donc une catégorie où l’on pouvait publier ça séparément ! Merci de me l’avoir indiqué !
Ça me rappelle les jeux de GOM Player d’autrefois...
👍 J’adore ce genre de chose…
Je trouve ça nettement plus pratique que les autres formes de 2FA, mais il semble qu’il y ait aussi des gens que ça gêne. Et, sur le plan des spécifications, c’est aussi plus sûr que n’importe quelle autre méthode de sécurité.
J’ai aussi l’impression que la réglementation coréenne en matière de sécurité s’oriente vers l’exclusion des authentifications reposant sur des données personnelles comme Face ID ou l’empreinte digitale, et les passkeys n’ont pas non plus ce type de problème.
Quand c’est Apple qui le fait, on se dit que Face ID est bien, mais si c’était une jeune startup, le simple fait de devoir scanner son visage pourrait d’emblée susciter un rejet.
J’ai l’impression que c’est surtout une péripétie née du fait que, dès le départ, les utilisateurs n’utilisent pas la 2FA ou ne savent même pas ce que c’est.
Par exemple, si on demandait : « Vous préférez utiliser un OTP bancaire ou une passkey ? », la passkey semblerait de loin la plus pratique.
Bonjour !
Merci d’avoir partagé votre expérience et vos réflexions.
Bien sûr, à mesure que le coût de production du code baisse, la voie du développement en interne s’est ouverte, mais personnellement, indépendamment de l’arrivée de l’ère de l’IA, j’envisage l’adoption de bibliothèques externes selon les critères suivants.
Je ne développe moi-même quelque chose que lorsque je pense que ces deux conditions sont réunies.
Il y a plusieurs raisons à cela, mais au final, dès lors que je commence à gérer moi-même le moindre morceau de code, il entre dans un périmètre dont je dois assurer la revue, les tests, la maintenance, etc., et je considère qu’il y a toujours un coût qui dépasse largement la simple écriture du code.
Les problèmes rencontrés pendant le développement venaient aussi de nombreux conflits avec des programmes assez centraux comme le window manager ; je pense donc que si j’avais même dû tout construire from scratch, j’aurais dû consacrer bien plus de temps à l’implémentation et à la validation qu’au débogage et aux tests liés aux conflits avec les dépendances externes.
Par ailleurs, depuis le début du développement, j’ai continué à utiliser, non sans douleur, l’outil que j’avais moi-même créé, et je me dis que cela n’a peut-être été possible que parce que j’ai commencé le développement en m’appuyant dans une certaine mesure sur des dépendances.
Comme dans le cas où SwiftTerm a été retiré sur macOS, j’intègre d’abord une dépendance externe pour vérifier si le concept que je veux fonctionne, puis, lorsqu’un élément doit être implémenté par mes soins, je commence à le développer moi-même ; mais même à ce stade, mes programmes fonctionnent toujours grâce à ces dépendances externes, ce qui me permet de continuer à me concentrer sur la stabilisation et l’ajout de fonctionnalités par-dessus.
De plus, si on intègre WebKit, la plupart des web apps fonctionnent de la même manière que lorsqu’on ouvre un navigateur classique !
Ces derniers temps, j’utilise aussi activement des outils qui permettent de piloter un headless browser en CLI, ainsi que Claude dans Chrome, et comme je veux éviter de superposer Chromium jusqu’au terminal au prix d’une consommation mémoire excessive, sauf changement majeur je ne pense pas modifier en profondeur la stack technique de la webview intégrée au terminal.
Merci de m’avoir lu !
Notre démo est justement un simple fichier HTML statique, donc ça semble parfaitement convenir. Si le lien est fixe, ce sera aussi pratique à partager. Merci pour l’info, nous l’appliquerons après la démo. Merci !
Pour l’instant, l’objectif n’est pas tant la sophistication de la logique que de montrer qu’« en saisissant une entrée, des offres correspondantes s’affichent réellement ». Comme il s’agit d’une démonstration destinée à des décideurs internes non développeurs, nous accordons plus d’importance à la vérification du fonctionnement qu’au niveau de finition. L’amélioration de la logique est envisagée pour l’étape suivante.
On a l’impression de revivre le moment de la généralisation des smartphones, quand l’UX basculait vers le mobile-first. Le cadre n’est pas encore bien établi, mais on voit apparaître partout des évolutions intéressantes.
Je l’ai ajouté directement à mes favoris. Je pense que j’irai probablement y jeter un œil tous les jours.
Je voulais aussi vous demander si vous envisagez éventuellement une prise en charge du coréen :)