Claude et Codex deviennent-ils de plus en plus stupides à mesure que vous les utilisez ? Parce que votre contexte est trop encombrant.
TechFlow SélectionTechFlow Sélection
Claude et Codex deviennent-ils de plus en plus stupides à mesure que vous les utilisez ? Parce que votre contexte est trop encombrant.
De la gestion du contexte et de la prise en charge de la tendance des IA à chercher à plaire, jusqu’à la définition des conditions de terminaison des tâches, il s’agit du document le plus clair que l’on ait vu à ce jour sur les bonnes pratiques d’ingénierie relatives à Claude/Codex.
Dédié à des analyses Web3 approfondiesAuteur : sysls
Traduction : TechFlow
Introduction de TechFlow : Un développeur blogueur comptant 2,6 millions d’abonnés, sysls, a rédigé un article pratique long et viral — partagé 827 fois et liké 7 000 fois — dont le message central tient en une seule phrase : vos plugins, vos systèmes de mémoire et vos divers « harness » vous nuisent très probablement plus qu’ils ne vous aident. Cet article ne traite pas de grands principes théoriques, mais expose exclusivement des principes opérationnels tirés de projets réels en production — allant du contrôle du contexte et de la gestion de la tendance des IA à vouloir plaire, jusqu’à la définition rigoureuse des conditions de terminaison d’une tâche. Il s’agit, à ce jour, du texte le plus clair et le plus concret jamais publié sur les bonnes pratiques d’ingénierie pour Claude et Codex.
Texte intégral ci-dessous :
Introduction
Vous êtes développeur. Vous utilisez quotidiennement Claude et l’interface en ligne de commande (CLI) de Codex, et vous vous demandez sans cesse si vous exploitez pleinement leurs capacités. Parfois, vous observez des comportements aberrants de leur part, sans comprendre pourquoi certaines personnes semblent construire des fusées avec l’IA, tandis que vous peinez même à empiler deux pierres stables.
Vous pensez que le problème vient de votre « harness », de vos plugins ou de votre terminal. Vous avez testé beads, opencode, zep ; votre fichier CLAUDE.md compte 26 000 lignes. Pourtant, malgré tous vos efforts, vous ne comprenez pas pourquoi vous vous éloignez de plus en plus du « paradis », alors que d’autres jouent joyeusement avec les anges.
C’est cet article que vous attendiez.
Par ailleurs, je n’ai aucun conflit d’intérêt. Lorsque je parle de CLAUDE.md, cela inclut aussi AGENT.md ; lorsque je mentionne Claude, cela englobe également Codex — j’utilise massivement les deux.
Ces derniers mois, j’ai remarqué un phénomène intéressant : presque personne ne sait vraiment comment maximiser les capacités des agents.
Cela ressemble à une petite poignée de personnes capables de faire construire des mondes entiers par des agents, tandis que le reste d’entre nous tourne en rond dans une mer infinie d’outils, victime du « syndrome du choix » — convaincu qu’en trouvant le bon paquet, la bonne compétence ou la bonne combinaison de « harness », on déverrouillera l’AGI.
Aujourd’hui, je veux briser tout cela et vous livrer une phrase simple et honnête, puis partir de là. Vous n’avez pas besoin du dernier « harness » pour agents, ni d’installer un million de paquets, ni même de lire un million d’articles pour rester compétitif. En réalité, votre enthousiasme risque davantage de nuire que d’aider.
Je ne suis pas venu faire du tourisme — j’utilise les agents depuis l’époque où ils parvenaient à peine à écrire du code. J’ai testé tous les paquets, tous les « harness », tous les paradigmes. J’ai utilisé des usines d’agents pour développer des signaux, des infrastructures et des pipelines de données — pas des « projets-jouets », mais des cas d’usage réels, déployés en production. Après avoir accompli tout cela…
Aujourd’hui, j’utilise une configuration d’une simplicité quasi extrême : uniquement la CLI de base (Claude Code et Codex), combinée à une compréhension profonde de quelques principes fondamentaux de l’ingénierie des agents — et j’ai réalisé, grâce à cela, mon travail le plus novateur à ce jour.
Comprendre que le monde avance à toute vitesse
Pour commencer, je dois souligner que les entreprises développant des modèles de base sont lancées dans une course historique, qui ne ralentira manifestement pas de sitôt. Chaque nouvelle amélioration de l’« intelligence des agents » modifie la façon dont vous collaborez avec eux, car ces agents sont conçus pour obéir de plus en plus fidèlement aux instructions.
Il y a seulement quelques générations, si vous écriviez dans votre CLAUDE.md : « Lis d’abord READTHISBEFOREDOINGANYTHING.md avant de faire quoi que ce soit », l’agent avait 50 % de chances de vous répondre « Va te faire voir » et d’agir selon son propre gré. Aujourd’hui, il suit la plupart des instructions, y compris des instructions complexes et imbriquées — par exemple, vous pouvez lui dire : « Lis d’abord A, puis B, et si C est vrai, lis D », et, dans la plupart des cas, il suivra docilement cette séquence.
Que signifie cela ? Le principe le plus important est de reconnaître que chaque nouvelle génération d’agents vous oblige à repenser ce qu’est la « solution optimale ». C’est précisément pourquoi « moins, c’est plus ».
Lorsque vous utilisez de nombreuses bibliothèques et « harness » différents, vous vous enfermez dans une « solution » donnée, alors que le problème qu’elle résout pourrait tout simplement disparaître avec la prochaine génération d’agents. Savez-vous qui sont les utilisateurs les plus passionnés et les plus intensifs des agents ? Exactement — les employés des entreprises de pointe, qui disposent d’un budget illimité en tokens et utilisent les modèles les plus récents. Comprenez-vous ce que cela implique ?
Cela signifie que, si un problème réel existe et qu’il possède une bonne solution, les entreprises de pointe seront les premières à adopter massivement cette solution. Que feront-elles ensuite ? Elles intégreront cette solution dans leurs propres produits. Réfléchissez-y : pourquoi une entreprise permettrait-elle à un produit tiers de résoudre un problème réel et de créer ainsi une dépendance externe ? Comment puis-je affirmer cela avec certitude ? Observez les « compétences », les systèmes de mémoire, les sous-agents… Tous ont commencé comme des « solutions » destinées à résoudre des problèmes concrets, puis se sont avérés utiles après validation en conditions réelles.
Ainsi, si quelque chose est véritablement révolutionnaire et étend significativement les cas d’usage des agents, elle sera inévitablement intégrée tôt ou tard dans les produits centraux des entreprises de base. Croyez-moi : ces entreprises progressent à une vitesse fulgurante. Alors détendez-vous — vous n’avez besoin d’installer aucune dépendance ni d’en recourir à aucune externe pour accomplir un travail exceptionnel.
Je prédis que les commentaires vont rapidement abonder de phrases du genre : « SysLS, j’utilise tel “harness”, c’est génial ! J’ai reconstruit Google en une journée ! » — à quoi je réponds : félicitations ! Mais vous n’êtes pas mon public cible. Vous représentez une minorité extrêmement réduite de la communauté, celle des rares personnes ayant réellement maîtrisé l’ingénierie des agents.
Le contexte, c’est tout
Vraiment. Le contexte, c’est tout. Un autre problème lié à l’utilisation de milliers de plugins et de dépendances externes est ce que j’appelle le « gonflement du contexte » — c’est-à-dire que votre agent est noyé sous une masse d’informations trop importante.
Je vous demande de coder un jeu de devinettes en Python ? Simple. Attendez… Quelle est cette note « gérer la mémoire », datant de 26 échanges plus tôt ? Ah, l’utilisateur avait un écran bloqué, il y a 71 échanges, parce que nous avions généré trop de sous-processus. Il faut toujours rédiger des notes ? Très bien… Mais quel rapport cela a-t-il avec le jeu de devinettes ?
Vous voyez le problème. Vous ne voulez fournir à l’agent que l’information exacte nécessaire à l’exécution de la tâche — ni plus, ni moins ! Plus vous maîtrisez précisément ce point, meilleure sera la performance de l’agent. Dès lors que vous commencez à introduire des systèmes de mémoire bizarres, des plugins variés ou trop de compétences nommées et invoquées de façon chaotique, vous donnez à l’agent à la fois la notice de fabrication d’une bombe et la recette d’un gâteau, alors que vous ne souhaitez qu’un poème sur une forêt de séquoias.
Alors, je le répète encore une fois — supprimez toutes les dépendances, puis…
Faites des choses réellement utiles
Décrire avec précision les détails d’implémentation
Vous vous souvenez que le contexte, c’est tout ?
Vous vous souvenez que vous souhaitez injecter dans l’agent uniquement l’information exacte requise pour accomplir la tâche — ni plus, ni moins ?
La première méthode pour y parvenir consiste à séparer clairement la recherche de l’implémentation. Vous devez être extrêmement précis sur ce que vous demandez à l’agent de faire.
Quelles sont les conséquences d’une formulation imprécise ? « Crée un système d’authentification. » L’agent doit alors chercher : qu’est-ce qu’un système d’authentification ? Quelles sont les options disponibles ? Quels sont leurs avantages et inconvénients ? Il va donc fouiller sur le Web une quantité d’informations qu’il n’utilisera finalement pas, remplissant son contexte de détails d’implémentation relatifs à des possibilités multiples. Lorsqu’il viendra enfin implémenter, il sera plus facilement désorienté, ou générera des « hallucinations » inutiles ou hors sujet autour de la solution retenue.
À l’inverse, si vous dites : « Implémente une authentification JWT avec hachage bcrypt-12, rotation des jetons de rafraîchissement, expiration au bout de 7 jours… », l’agent n’a pas besoin d’étudier d’autres alternatives : il sait exactement ce que vous attendez, et peut donc remplir son contexte avec des détails d’implémentation pertinents.
Bien entendu, vous ne connaissez pas toujours les détails d’implémentation. Souvent, vous ignorez quelle solution est la bonne, voire vous souhaitez déléguer à l’agent lui-même le choix de l’implémentation. Que faire dans ce cas ? C’est simple : créez une tâche de recherche visant à explorer les différentes possibilités d’implémentation, décidez vous-même de la solution ou laissez l’agent choisir, puis confiez l’implémentation à un autre agent doté d’un contexte entièrement nouveau.
Dès que vous adoptez cette approche, vous identifierez facilement les endroits de votre flux de travail où le contexte de l’agent est inutilement contaminé, et vous pourrez alors établir des « cloisons » dans ce flux afin d’abstraire les informations superflues et de ne conserver que le contexte spécifique nécessaire à la réussite de la tâche. Rappelez-vous : vous disposez d’un membre d’équipe exceptionnellement talentueux et intelligent, qui connaît toutes les sortes de sphères existant dans l’univers — mais à moins que vous ne lui expliquiez clairement que vous souhaitez concevoir un espace où les gens dansent et s’amusent, il continuera indéfiniment à vous parler des avantages des objets sphériques.
Les limites de conception liées à la tendance à vouloir plaire
Nul ne veut utiliser un produit qui le critique constamment, lui dit qu’il a tort ou ignore totalement ses instructions. Ces agents font donc tout leur possible pour vous approuver et réaliser ce que vous leur demandez.
Si vous leur demandez d’ajouter systématiquement le mot « joie » après chaque troisième mot, ils s’y efforceront — la plupart des gens comprennent cela. Leur obéissance est précisément ce qui fait d’eux un outil si efficace. Or, cela comporte une caractéristique fascinante : cela signifie que, si vous leur dites « aide-moi à trouver un bug dans le code », ils en trouveront un — même s’ils doivent en « fabriquer » un. Pourquoi ? Parce qu’ils veulent *absolument* suivre vos instructions !
La plupart des gens se plaignent rapidement des hallucinations des LLM et de leur tendance à inventer des éléments inexistants, sans réaliser que le problème vient d’eux-mêmes. Ce que vous leur demandez, ils le livrent — même s’ils doivent légèrement déformer la réalité !
Que faire alors ? J’ai constaté que les « prompts neutres » fonctionnent très bien, c’est-à-dire des formulations qui ne poussent pas l’agent vers un résultat particulier. Par exemple, plutôt que de dire « aide-moi à trouver un bug dans la base de données », je dis : « Analyse l’intégralité de la base de données, suis logiquement le comportement de chaque composant, et rapporte-moi tous les éléments observés. »
Un tel prompt neutre peut parfois révéler un bug, parfois se contenter de décrire objectivement le fonctionnement du code. Mais il n’incite pas l’agent à partir du présupposé qu’un bug *doit* exister.
Une autre façon de traiter cette tendance à vouloir plaire consiste à la transformer en avantage. Je sais que l’agent cherche activement à me satisfaire et à suivre mes instructions — je peux donc orienter cette tendance dans un sens ou dans un autre.
Ainsi, je demande à un agent spécialisé dans la détection de bugs d’identifier *tous* les bugs potentiels dans la base de données, en lui indiquant que chaque bug à faible impact rapporte +1 point, chaque bug à impact modéré +5 points, et chaque bug à fort impact +10 points. Je sais que cet agent identifiera avec une grande ardeur tous les types de bugs — y compris ceux qui n’en sont pas vraiment — et me rapportera un score de 104 points, par exemple. Je considère ce résultat comme un « sur-ensemble » de tous les bugs possibles.
Ensuite, je fais intervenir un agent « adversaire » chargé de réfuter chacun de ces bugs. Je lui précise que chaque réfutation réussie lui rapporte le nombre de points associé au bug concerné, mais qu’une réfutation erronée lui coûte le double de ce nombre de points. Cet agent s’efforcera donc de réfuter le plus grand nombre possible de bugs, mais la pénalité le rendra prudent. Il continuera néanmoins à « réfuter » activement les bugs — y compris les vrais. Je considère ce résultat comme un « sous-ensemble » des bugs réels.
Enfin, je sollicite un agent « arbitre » chargé de synthétiser les entrées des deux agents précédents et de noter chaque « bug ». Je précise à l’arbitre que je connais la réponse exacte : il obtient +1 point pour chaque réponse correcte, -1 point pour chaque erreur. Il attribue donc une note à chaque « bug », tant pour l’agent détecteur que pour l’agent adversaire. Ce que l’arbitre déclare vrai, je le vérifie moi-même. Dans la majorité des cas, cette méthode atteint une fidélité remarquable ; elle peut occasionnellement se tromper, mais elle constitue déjà une opération quasi infaillible.
Vous pourriez juger qu’un seul agent détecteur suffit, mais cette méthode fonctionne très bien pour moi, car elle exploite une caractéristique intrinsèque de chaque agent : son désir inné de plaire.
Comment déterminer ce qui est utile et ce qui mérite d’être utilisé ?
Cette question semble complexe, comme si elle exigeait une formation approfondie et un suivi constant des avancées de l’IA — or, elle est en réalité très simple… Si OpenAI et Claude l’ont implémenté ou acquis l’entreprise qui l’a mis en œuvre, alors cela a de fortes chances d’être utile.
Avez-vous remarqué que les « compétences » (skills) sont désormais omniprésentes, et font partie intégrante de la documentation officielle de Claude et de Codex ? Avez-vous remarqué qu’OpenAI a acquis OpenClaw ? Avez-vous remarqué que Claude a immédiatement ajouté des fonctions de mémoire, de reconnaissance vocale et de travail à distance ?
Et la « planification » (planning) ? Vous souvenez-vous de la vague de constats selon laquelle planifier d’abord, puis implémenter, s’avère extrêmement efficace — avant que cette pratique ne devienne une fonctionnalité centrale ?
Oui, ces éléments sont utiles !
Vous souvenez-vous de ces « hooks de stop » interminables, si utiles parce que les agents répugnent fortement aux tâches longues… puis, du jour au lendemain, de la disparition de ce besoin dès la sortie de Codex 5.2 ?
C’est tout ce que vous devez savoir… Si quelque chose est réellement importante et utile, Claude et Codex l’implémenteront eux-mêmes ! Vous n’avez donc pas besoin de vous soucier excessivement de l’adoption de « nouveautés », ni de les maîtriser, ni même de « rester à jour ».
Faites-moi une faveur : mettez à jour occasionnellement votre CLI choisie, et lisez les nouvelles fonctionnalités ajoutées. Cela suffit largement.
Compression, contexte et hypothèses
Certains utilisateurs tombent dans un piège majeur lorsqu’ils travaillent avec des agents : parfois, ils semblent les êtres les plus intelligents de la planète, parfois vous ne pouvez croire qu’on vous ait berné par leur intermédiaire.
« Intelligent, ce truc ? C’est un crétin ! »
La différence la plus marquée réside dans le fait que l’agent soit contraint ou non de formuler des hypothèses ou de « combler des lacunes ». Aujourd’hui, ils restent extrêmement mauvais dans l’exercice de « relier les points », de « combler les lacunes » ou de formuler des hypothèses. Dès qu’ils le font, cela saute aux yeux immédiatement — et la qualité chute nettement.
L’une des règles les plus importantes de CLAUDE.md concerne précisément la façon d’acquérir le contexte, et ordonne à l’agent de lire cette règle en premier lieu à chaque lecture de CLAUDE.md (c’est-à-dire après chaque compression). Dans le cadre de cette règle d’acquisition du contexte, quelques instructions simples peuvent produire un effet considérable : relire le plan de la tâche, et relire les fichiers pertinents (liés à la tâche) avant de poursuivre.
Indiquer à l’agent comment mettre fin à une tâche
Pour nous, humains, la notion de « tâche terminée » est assez claire. Pour les agents, le principal défaut actuel de leur intelligence réside dans leur capacité à démarrer une tâche, mais non à la terminer.
Cela conduit souvent à des résultats très frustrants : l’agent termine en implémentant une série de « stubs » (fonctions vides ou partielles) et s’arrête là.
Les tests constituent un excellent jalon pour les agents, car ils sont déterministes et permettent de définir des attentes très claires. Votre tâche n’est pas terminée tant que ces X tests ne sont pas passés — et vous n’êtes pas autorisé à modifier les tests.
Il vous suffit ensuite d’inspecter les tests, et vous pouvez être assuré de leur bon déroulement dès qu’ils sont tous validés. Vous pouvez même automatiser cette étape, mais l’essentiel est de garder à l’esprit que la « fin d’une tâche » est une notion naturelle pour l’humain, mais non pour l’agent.
Saviez-vous qu’un autre point de terminaison viable pour les tâches est apparu récemment ? La capture d’écran + vérification. Vous pouvez demander à l’agent d’implémenter une fonctionnalité jusqu’à ce que tous les tests soient validés, puis lui demander de capturer un écran et de vérifier que le « design ou le comportement » affiché correspond bien à vos attentes.
Cela vous permet d’inciter l’agent à itérer et à progresser vers le design souhaité, sans craindre qu’il s’arrête après sa première tentative !
Une extension naturelle de cette approche consiste à établir avec l’agent un « contrat », intégré directement dans les règles. Par exemple, ce fichier `{TASK}CONTRACT.md` précise ce qui doit être accompli avant que vous ne puissiez mettre fin à la session. Dans `{TASK}CONTRACT.md`, vous spécifiez les tests à exécuter, les captures d’écran à effectuer, ainsi que toute autre vérification nécessaire pour valider que la tâche peut être considérée comme achevée !
Des agents en marche continue
On me demande souvent comment faire fonctionner un agent pendant 24 heures tout en garantissant qu’il ne s’égare pas.
Voici une méthode très simple : créez un « hook de stop » qui empêche l’agent de mettre fin à la session tant que toutes les parties du fichier `{TASK}_CONTRACT.md` ne sont pas remplies.
Si vous disposez de 100 tels contrats, parfaitement spécifiés et contenant l’intégralité du contenu que vous souhaitez construire, ce « hook de stop » empêchera l’agent de clore la session jusqu’à ce que les 100 contrats soient entièrement exécutés — y compris tous les tests requis et toutes les vérifications nécessaires !
Conseil professionnel : j’ai constaté que les sessions continues de 24 heures ne sont pas optimales pour « accomplir des tâches ». Une partie de la raison en est que cette approche introduit structurellement un « gonflement du contexte », puisque le contexte de contrats non pertinents s’accumule dans une même session !
Je ne recommande donc pas cette pratique.
Voici une meilleure approche d’automatisation des agents : ouvrir une nouvelle session pour chaque contrat. Créez un contrat chaque fois que vous devez accomplir une tâche donnée.
Mettez en place une couche d’orchestration qui crée automatiquement un nouveau contrat dès qu’une tâche doit être réalisée, puis lance une nouvelle session pour traiter ce contrat.
Cela transformera radicalement votre expérience avec les agents.
Itérer, itérer, itérer
Vous embauchez un assistant administratif : attendez-vous qu’il connaisse votre emploi du temps dès le premier jour ? Ou la façon dont vous buvez votre café ? Ou que vous dîniez à 18 h plutôt qu’à 20 h ? Évidemment non. Vous construisez progressivement vos préférences avec le temps.
Il en va de même pour les agents. Commencez avec la configuration la plus simple, oubliez les structures complexes ou les « harness », et laissez une chance à la CLI de base.
Ensuite, ajoutez progressivement vos préférences. Comment procéder ?
Règles
Si vous ne voulez pas que l’agent accomplisse une certaine action, formalisez-la sous forme de règle, puis indiquez-lui cette règle dans CLAUDE.md. Par exemple : « Avant d’écrire du code, lis `coding-rules.md`. » Les règles peuvent être imbriquées et conditionnelles ! Si vous écrivez du code, lisez `coding-rules.md` ; si vous écrivez des tests, lisez `coding-test-rules.md` ; si vos tests échouent, lisez `coding-test-failing-rules.md`. Vous pouvez créer autant de branches logiques que nécessaire pour guider l’agent — Claude (et Codex) les suivront volontiers, à condition qu’elles soient clairement décrites dans CLAUDE.md.
En effet, voici mon premier conseil pratique : considérez votre CLAUDE.md comme un répertoire logique et hiérarchique indiquant, pour chaque scénario spécifique et chaque résultat attendu, où aller chercher le contexte. Il doit être aussi concis que possible, ne contenant que de la logique conditionnelle « SI-ALORS » : « Dans telle situation, allez chercher le contexte ici. »
Si vous constatez que l’agent accomplit une action que vous désapprouvez, ajoutez-en une règle explicite : « Avant d’accomplir cette action, lis cette règle. » Il ne la répétera plus.
Compétences (Skills)
Les « compétences » (skills) ressemblent aux règles, mais plutôt que d’exprimer des préférences de codage, elles sont mieux adaptées à décrire des « procédures opérationnelles ». Si vous souhaitez qu’une tâche soit accomplie d’une manière particulière, incorporez cette méthode dans une compétence.
En effet, les gens se plaignent souvent de ne pas savoir comment l’agent va résoudre un problème, ce qui les met mal à l’aise. Si vous souhaitez rendre ce processus déterministe, demandez d’abord à l’agent d’étudier comment il envisage de résoudre le problème, puis formalisez sa méthode dans un fichier de compétence. Vous pourrez ainsi visualiser à l’avance la façon dont l’agent traitera le problème, et apporter des corrections ou des améliorations avant qu’il ne soit confronté à celui-ci dans la réalité.
Comment informer l’agent de l’existence de cette compétence ? Exactement ! Vous l’indiquez dans CLAUDE.md : « Lorsque tu rencontres ce scénario et dois traiter cette tâche, lis ce fichier `SKILL.md`. »
Gérer les règles et les compétences
Vous aurez naturellement envie d’ajouter continuellement de nouvelles règles et compétences à votre agent. C’est ainsi que vous lui donnez une personnalité et que vous lui faites mémoriser vos préférences. Presque tout le reste est superflu.
Dès que vous adoptez cette démarche, votre agent vous semblera magique. Il agira « exactement comme vous le souhaitez ». Et vous sentirez enfin que vous avez « percé le mystère » de l’ingénierie des agents.
Puis…
Vous verrez les performances commencer à décliner à nouveau.
Pourquoi ? !
C’est très simple. À mesure que vous ajoutez de plus en plus de règles et de compétences, celles-ci entrent en conflit les unes avec les autres, ou provoquent un « gonflement du contexte » sévère chez l’agent. Si vous demandez à l’agent de lire 14 fichiers Markdown avant de commencer à programmer, il se retrouvera confronté au même problème : une accumulation d’informations inutiles.
Que faire ?
Nettoyez. Demandez à votre agent de « faire un spa » : fusionnez les règles et les compétences, et éliminez les contradictions en reformulant vos préférences actualisées.
Et il redeviendra magique.
C’est tout. Voilà véritablement le secret. Restez simple, utilisez des règles et des compétences, considérez CLAUDE.md comme un répertoire, et portez une attention scrupuleuse à la gestion de leur contexte et à leurs limites de conception.
Assumer la responsabilité des résultats
Aujourd’hui, aucun agent n’est parfait. Vous pouvez déléguer de nombreux aspects de la conception et de l’implémentation à l’agent, mais vous devez assumer la responsabilité finale des résultats.
Soignez donc votre vigilance… et profitez-en pleinement !
Jouer avec des jouets du futur — tout en les utilisant évidemment pour des tâches sérieuses — est un véritable plaisir !
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@systematicls
