C’est seulement dans ce genre de moments qu’ils se retrouvent sur la même longueur d’onde.
Entre OpenAI, qui affiche « Open » jusque dans son nom tout en agissant avec un culot incroyable,
et Anthropic, qui a claqué la porte en disant qu’OpenAI avait changé,
on se demande si c’est juste une affaire d’argent, ou si l’IA est vue comme une lutte pour l’hégémonie au point que le gouvernement intervient pour manipuler la direction à sa guise.
Vendre de l’éducation est ce qui offre le meilleur rapport coût-efficacité. Il n’y a aucune responsabilité, seulement de la facturation. L’IA va prendre une grosse part de ce business.
Le point 3 (séparation des responsabilités entre agents) me semble être le plus difficile. J’ai déjà regardé d’un peu près des traces de benchmarks publics, et je partage un motif que j’y ai vu.
Le cas le plus fréquent n’était pas une « mauvaise décision », mais l’exécution deux fois de la même tâche. Par exemple, l’envoi d’un e-mail répété avec les mêmes arguments, ou le même fichier réécrit. Cela arrivait surtout dans les phases de retry après timeout : le premier appel était simplement lent, mais il était considéré comme un échec et relancé.
Ce qui rend ce problème difficile à tracer, c’est qu’il n’y a pas d’erreur. Les deux appels renvoient 200, les logs sont propres, donc en regardant seulement les logs a posteriori, on ne voit rien.
La méthode que nous utilisons consiste à regrouper par (outil, arguments normalisés, hash de sortie) et à compter mécaniquement si la même combinaison se répète. Comme cela ne repose sur aucun jugement du LLM, seulement sur du calcul, c’est reproductible. Mais la limite est claire : on sait seulement que « l’appel a eu lieu deux fois », pas si « l’exécution a réellement eu lieu deux fois » à partir de la trace seule. Pour les outils qui renvoient un ID d’entité dans la réponse (comme une API de création de document), on peut le vérifier en comparant les ID ; mais pour des outils qui renvoient seulement « envoi réussi », comme l’e-mail, il n’y a pas vraiment de méthode.
Je comprends aussi ce que vous dites au point 2, sur le fait de « laisser passer pour aller vite ». Nous aussi, nous avons envisagé de bloquer en temps réel, mais avant l’exécution, on ne peut pas voir le résultat, donc il faut juger uniquement à partir des arguments, et la précision était faible. Cela finissait par bloquer même des retries légitimes, donc nous avons abandonné.
Le coût de correction des bugs a lui aussi beaucoup baissé, et celui des mises à jour logicielles tend vers zéro ; en plus, sauf dans la finance ou des secteurs du même niveau d’exigence, dans bien des cas il suffit simplement de corriger le bug...
Mais si cette façon de penser s’accumule, cela finira sans doute par provoquer un incident majeur.
Si, en l’essayant, vous tombez sur des conversations où le retour arrière tourne dans le vide, ou sur des points où vous vous dites « là, c’est un peu peu pratique », n’hésitez pas à laisser un commentaire. La structure des conversations varie selon les sites, donc les cas d’usage réels sont ce qui m’aide le plus. Pour la suite, je regarde la prise en charge de Perplexity ainsi que l’export vers Notion/Obsidian, mais s’il y a quelque chose de plus urgent, je commencerai par ça haha
Merci. N’hésitez pas à me le signaler après l’avoir essayé s’il y a des conversations pour lesquelles Jumpback n’est pas détecté~
Je l’utilise moi aussi, mais je pense que ce serait bien de pouvoir entendre aussi les retours concrets et les points gênants rencontrés par d’autres utilisateurs haha
À chaque fois que l’agent fait une modification, en observant le log des diff, s’il provoque une chirurgie au fusil à pompe ou un grand volume de changements, on pourrait peut-être considérer ça comme une mauvaise odeur de génie logiciel et faire de l’apprentissage par renforcement...
[Pour vous éviter une lecture inconfortable, j’ai ajouté une traduction française du README !]
Clew
Un détecteur déterministe qui repère le travail gaspillé dans les traces d’agents.
Clew lit les traces d’exécutions terminées d’agents IA et repère les étapes qui répètent un travail déjà effectué : rappeler le même outil avec les mêmes arguments, réessayer un appel échoué avec les mêmes arguments, ou rechercher à nouveau des informations déjà présentes dans le contexte. Comme il fonctionne sans jugement par LLM, la même trace donne toujours le même résultat.
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
Pourquoi c’est important
Dans les sessions d’agents IA de code, le gaspillage n’apparaît que sur la facture. Tous les appels d’outils renvoient 200 et rien ne produit d’erreur, donc le gaspillage n’est pas visible. Mais dans la trace, l’agent lit deux fois le même fichier, réessaie un appel échoué avec les mêmes arguments, et rappelle le même outil avec le même payload.
Comme les opérations de lecture représentent 65 à 90 % des tokens dans les sessions d’agents de code, ce gaspillage s’accumule sans se faire remarquer. Les outils d’observabilité montrent les traces, mais n’indiquent pas quelle étape était redondante.
Ce qui est détecté
Clew recherche trois schémas de duplication :
repeat — le même outil/nœud est appelé à plusieurs reprises
requery — le même outil est rappelé avec la même entrée (sortie identique)
pingpong — deux agents s’échangent en substance le même contenu (multi-agent)
Chaque découverte est classée en quatre catégories :
error_repeat — la sortie est une erreur, mais le même appel est répété
side_effect — réexécution d’un outil qui modifie l’état (envoi/écriture/création, etc.)
idempotent — répétition d’un outil en lecture seule/déclaratif (pas d’effet de bord, mais consomme des tokens)
unclassified — outil absent du mapping. L’effet dépend du payload, donc il n’est pas déduit du seul nom de l’outil (Bash/PowerShell, etc.)
[Comment ça fonctionne]
C’est une cascade en 2 étapes :
Porte structurelle — regroupe les appels du même outil avec les mêmes arguments (normalisés)
Porte d’identité — vérifie que le sha256 de la sortie correspond exactement. Si ce n’est pas le cas, l’état a changé, donc ce n’est pas signalé
Un contrôle structurel peu coûteux réduit d’abord les candidats, et le contrôle sémantique coûteux (embeddings + cosinus) n’est exécuté que lorsque c’est nécessaire. Comme il n’y a pas de jugement par LLM, le résultat est déterministe — un point important si vous voulez l’intégrer à la CI.
[Formats d’entrée]
Claude Code — analyse directe du JSONL de session
LangGraph — détection des duplications de chaînes dans les traces
LangChain·CrewAI·AutoGen·LlamaIndex, etc. — parsing des traces instrumentées aux formats standards OpenTelemetry/OpenInference (support du format ; la validation empirique par framework est en cours)
Traces de benchmarks publics (Toolathlon, RedundancyBench)
Les sessions Cursor et Codex ne sont pas encore prises en charge — les formats locaux sont à l’étude.
[Résultats de validation]
Benchmark public (Toolathlon, 6 780 traces, 176 270 tool spans) :
8 042 appels redondants détectés. Parmi eux, 47 % relèvent d’une zone grise (opérations idempotentes, déclarations d’achèvement) ; en les excluant, il reste 4 251 cas (2,41 % des tool spans). C’est environ 3× plus que dans les sessions Claude Code (0,80 %).
1 343 réexécutions d’outils modifiant l’état, dont 459 envois d’e-mails répétés avec les mêmes arguments. Il s’agit toutefois d’une détection d’appels redondants au même outil avec les mêmes arguments ; il n’a pas été vérifié si un effet de bord s’est réellement produit.
Benchmark labellisé (RedundancyBench) :
precision 0.826 (estimation basse pour les doublons au sein d’un fichier). Une grande partie des labels RB concerne des doublons entre fichiers (cross-file), hors du périmètre d’une analyse conçue au niveau session. Le recall est faible, à 0.157.
[Limites honnêtes]
Il n’y a pas encore de cas mesuré d’économies. L’outil peut détecter et estimer, mais il existe 0 donnée before/after montrant qu’un utilisateur réel a corrigé quelque chose et que sa facture a effectivement baissé.
47 % des éléments signalés dans le benchmark relèvent d’une zone grise (réexécutions idempotentes). Ils ne sont pas filtrés, seulement classés — car déterminer si une réexécution en lecture seule était du gaspillage dépend d’un contexte qui n’est pas visible.
Une correspondance sha256 exacte est requise, donc la moindre différence dans la sortie empêche le signalement. C’est la raison du faible recall ; la conception privilégie la précision.
Claude Code est exceptionnellement bien optimisé. Sur six schémas candidats de gaspillage mesurés dans de vraies sessions CC, cinq n’y existaient pas. Le gaspillage intéressant est apparu non pas dans CC lui-même, mais dans des environnements MCP multi-outils.
L’estimation de coût (amplification) n’est pas une mesure mais une estimation, et elle n’est possible qu’avec le format Claude Code.
Ce qui n’est pas validé est abandonné
J’avais créé un détecteur de relecture de fichiers, puis je l’ai abandonné après qu’une annotation humaine sur un échantillon de 30 cas a montré une précision très inférieure au seuil préenregistré (70 %) : 3,3 % dans une lecture généreuse, 0 % dans une lecture stricte. Les prédictions et les résultats ont été conservés ensemble dans le document de préenregistrement.
Mise à jour de l’auteur. J’ai publié un article qui détaille séparément la partie serveur MCP, seulement mentionnée en une ligne dans le texte principal — l’idée est de résoudre le problème des agents qui choisissent les noms de colonnes à leur guise lors de l’écriture de migrations, en remplaçant le nom physique « saisi » par un nom « calculé » à partir d’un dictionnaire de mots : https://sqemo.com/blog/erd-mcp-server
(Pour l’instant, c’est uniquement en local via stdio, donc le MCP distant n’est pas pris en charge ; l’application elle-même est fermée, seul le serveur MCP est open source.)
Vous pouvez l’essayer tout de suite sans inscription (app.sqemo.com), donc si quelque chose vous gêne, laissez un commentaire — c’est encore le début, les retours sont intégrés rapidement.
Depuis le premier billet, j’ai continué à faire évoluer Repolis au-delà d’un simple navigateur 3D de repo, vers une petite ville qui donne envie d’y revenir.
Le trafic GitHub et les informations des repos publics se reflètent chaque jour dans les bâtiments et l’éclairage nocturne.
J’ai ajouté Starlight Row, avec 8 habitants et leurs maisons respectives, ainsi que des routines de vie jour/nuit et de courtes promenades et interactions entre les habitants.
Avec Explorer Passport, Village Chronicle et Town Gazette, vous pouvez suivre l’historique des visites ainsi que les nouveaux repo, release, push et les évolutions des métriques.
J’ai intégré dans la ville réelle de Repolis le World Tree procédural créé avec le plugin Copilot threejs-sculpt-dna.
La base reste une static app zero-build ne nécessitant ni backend ni clés, et seules les fonctionnalités de taxi/scholar IA grounded sont optionnelles.
Plutôt que de créer un nouveau billet, je continuerai à consigner les changements ultérieurs à la suite de ce commentaire du billet d’origine.
Sur le clavier coréen du Mac, on ne peut pas le saisir T_T Avec Claude, il semble aussi utiliser beaucoup plus de Markdown dans ses réponses, mais pour les utilisateurs coréens ce n’est pas très familier...
Je suis l’auteur. Pour compléter avec quelques éléments qui n’ont pas pu être inclus dans l’article —
· La vidéo de démo (flux d’approbation sur téléphone, centre de commande desktop en 3 volets) est disponible en capture réelle sur la landing page : adhf.dev
· Le self-hosting se fait avec une seule ligne, npm i -g adhdev, et le tableau de bord apparaît sur localhost:3847 (aucun compte nécessaire)
· Les questions de conception sont les bienvenues, par exemple sur le merge en ff-only ou sur ce que la validation croisée MAGI détecte réellement
Si vous me faites des retours, je les intégrerai rapidement.
De nos jours, on parle non pas de dette technique, mais de dette cognitive.
Quand je discute parfois avec des collègues, il m’arrive souvent de voir qu’ils ne comprennent pas vraiment le fonctionnement de ce qu’ils ont pourtant eux-mêmes créé, et ça me donne un peu des frissons.
Avec le temps, on finira donc dans une situation où plus personne ne comprendra comment ça fonctionne, mais on peut aussi se dire que ce n’est peut-être pas un problème puisqu’il suffira de demander à l’IA de l’analyser et de lui poser la question.
C’est seulement dans ce genre de moments qu’ils se retrouvent sur la même longueur d’onde.
Entre OpenAI, qui affiche « Open » jusque dans son nom tout en agissant avec un culot incroyable,
et Anthropic, qui a claqué la porte en disant qu’OpenAI avait changé,
on se demande si c’est juste une affaire d’argent, ou si l’IA est vue comme une lutte pour l’hégémonie au point que le gouvernement intervient pour manipuler la direction à sa guise.
beurk…
Vendre de l’éducation est ce qui offre le meilleur rapport coût-efficacité. Il n’y a aucune responsabilité, seulement de la facturation. L’IA va prendre une grosse part de ce business.
Il me semble avoir vu ça il y a quelques années.
En allant sur le site d’origine, les explications sont illustrées par des images, ce qui les rend faciles à comprendre intuitivement.
Ça aide d’augmenter les activités hors ligne, comme les promenades ou la lecture. :)
Le point 3 (séparation des responsabilités entre agents) me semble être le plus difficile. J’ai déjà regardé d’un peu près des traces de benchmarks publics, et je partage un motif que j’y ai vu.
Le cas le plus fréquent n’était pas une « mauvaise décision », mais l’exécution deux fois de la même tâche. Par exemple, l’envoi d’un e-mail répété avec les mêmes arguments, ou le même fichier réécrit. Cela arrivait surtout dans les phases de retry après timeout : le premier appel était simplement lent, mais il était considéré comme un échec et relancé.
Ce qui rend ce problème difficile à tracer, c’est qu’il n’y a pas d’erreur. Les deux appels renvoient 200, les logs sont propres, donc en regardant seulement les logs a posteriori, on ne voit rien.
La méthode que nous utilisons consiste à regrouper par (outil, arguments normalisés, hash de sortie) et à compter mécaniquement si la même combinaison se répète. Comme cela ne repose sur aucun jugement du LLM, seulement sur du calcul, c’est reproductible. Mais la limite est claire : on sait seulement que « l’appel a eu lieu deux fois », pas si « l’exécution a réellement eu lieu deux fois » à partir de la trace seule. Pour les outils qui renvoient un ID d’entité dans la réponse (comme une API de création de document), on peut le vérifier en comparant les ID ; mais pour des outils qui renvoient seulement « envoi réussi », comme l’e-mail, il n’y a pas vraiment de méthode.
Je comprends aussi ce que vous dites au point 2, sur le fait de « laisser passer pour aller vite ». Nous aussi, nous avons envisagé de bloquer en temps réel, mais avant l’exécution, on ne peut pas voir le résultat, donc il faut juger uniquement à partir des arguments, et la précision était faible. Cela finissait par bloquer même des retries légitimes, donc nous avons abandonné.
Le coût de correction des bugs a lui aussi beaucoup baissé, et celui des mises à jour logicielles tend vers zéro ; en plus, sauf dans la finance ou des secteurs du même niveau d’exigence, dans bien des cas il suffit simplement de corriger le bug...
Mais si cette façon de penser s’accumule, cela finira sans doute par provoquer un incident majeur.
Si, en l’essayant, vous tombez sur des conversations où le retour arrière tourne dans le vide, ou sur des points où vous vous dites « là, c’est un peu peu pratique », n’hésitez pas à laisser un commentaire. La structure des conversations varie selon les sites, donc les cas d’usage réels sont ce qui m’aide le plus. Pour la suite, je regarde la prise en charge de Perplexity ainsi que l’export vers Notion/Obsidian, mais s’il y a quelque chose de plus urgent, je commencerai par ça haha
Merci. N’hésitez pas à me le signaler après l’avoir essayé s’il y a des conversations pour lesquelles Jumpback n’est pas détecté~
Je l’utilise moi aussi, mais je pense que ce serait bien de pouvoir entendre aussi les retours concrets et les points gênants rencontrés par d’autres utilisateurs haha
À chaque fois que l’agent fait une modification, en observant le log des diff, s’il provoque une chirurgie au fusil à pompe ou un grand volume de changements, on pourrait peut-être considérer ça comme une mauvaise odeur de génie logiciel et faire de l’apprentissage par renforcement...
[Pour vous éviter une lecture inconfortable, j’ai ajouté une traduction française du README !]
Clew
Un détecteur déterministe qui repère le travail gaspillé dans les traces d’agents.
Clew lit les traces d’exécutions terminées d’agents IA et repère les étapes qui répètent un travail déjà effectué : rappeler le même outil avec les mêmes arguments, réessayer un appel échoué avec les mêmes arguments, ou rechercher à nouveau des informations déjà présentes dans le contexte. Comme il fonctionne sans jugement par LLM, la même trace donne toujours le même résultat.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Exemple de sortie réelle obtenue sur une session Claude Code publique :
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsPourquoi c’est important
Dans les sessions d’agents IA de code, le gaspillage n’apparaît que sur la facture. Tous les appels d’outils renvoient 200 et rien ne produit d’erreur, donc le gaspillage n’est pas visible. Mais dans la trace, l’agent lit deux fois le même fichier, réessaie un appel échoué avec les mêmes arguments, et rappelle le même outil avec le même payload.
Comme les opérations de lecture représentent 65 à 90 % des tokens dans les sessions d’agents de code, ce gaspillage s’accumule sans se faire remarquer. Les outils d’observabilité montrent les traces, mais n’indiquent pas quelle étape était redondante.
Ce qui est détecté
Clew recherche trois schémas de duplication :
repeat — le même outil/nœud est appelé à plusieurs reprises
requery — le même outil est rappelé avec la même entrée (sortie identique)
pingpong — deux agents s’échangent en substance le même contenu (multi-agent)
Chaque découverte est classée en quatre catégories :
error_repeat — la sortie est une erreur, mais le même appel est répété
side_effect — réexécution d’un outil qui modifie l’état (envoi/écriture/création, etc.)
idempotent — répétition d’un outil en lecture seule/déclaratif (pas d’effet de bord, mais consomme des tokens)
unclassified — outil absent du mapping. L’effet dépend du payload, donc il n’est pas déduit du seul nom de l’outil (Bash/PowerShell, etc.)
[Comment ça fonctionne]
C’est une cascade en 2 étapes :
Porte structurelle — regroupe les appels du même outil avec les mêmes arguments (normalisés)
Porte d’identité — vérifie que le sha256 de la sortie correspond exactement. Si ce n’est pas le cas, l’état a changé, donc ce n’est pas signalé
Un contrôle structurel peu coûteux réduit d’abord les candidats, et le contrôle sémantique coûteux (embeddings + cosinus) n’est exécuté que lorsque c’est nécessaire. Comme il n’y a pas de jugement par LLM, le résultat est déterministe — un point important si vous voulez l’intégrer à la CI.
[Formats d’entrée]
Claude Code — analyse directe du JSONL de session
LangGraph — détection des duplications de chaînes dans les traces
LangChain·CrewAI·AutoGen·LlamaIndex, etc. — parsing des traces instrumentées aux formats standards OpenTelemetry/OpenInference (support du format ; la validation empirique par framework est en cours)
Traces de benchmarks publics (Toolathlon, RedundancyBench)
Les sessions Cursor et Codex ne sont pas encore prises en charge — les formats locaux sont à l’étude.
[Résultats de validation]
Benchmark public (Toolathlon, 6 780 traces, 176 270 tool spans) :
8 042 appels redondants détectés. Parmi eux, 47 % relèvent d’une zone grise (opérations idempotentes, déclarations d’achèvement) ; en les excluant, il reste 4 251 cas (2,41 % des tool spans). C’est environ 3× plus que dans les sessions Claude Code (0,80 %).
1 343 réexécutions d’outils modifiant l’état, dont 459 envois d’e-mails répétés avec les mêmes arguments. Il s’agit toutefois d’une détection d’appels redondants au même outil avec les mêmes arguments ; il n’a pas été vérifié si un effet de bord s’est réellement produit.
Benchmark labellisé (RedundancyBench) :
precision 0.826 (estimation basse pour les doublons au sein d’un fichier). Une grande partie des labels RB concerne des doublons entre fichiers (cross-file), hors du périmètre d’une analyse conçue au niveau session. Le recall est faible, à 0.157.
[Limites honnêtes]
Il n’y a pas encore de cas mesuré d’économies. L’outil peut détecter et estimer, mais il existe 0 donnée before/after montrant qu’un utilisateur réel a corrigé quelque chose et que sa facture a effectivement baissé.
47 % des éléments signalés dans le benchmark relèvent d’une zone grise (réexécutions idempotentes). Ils ne sont pas filtrés, seulement classés — car déterminer si une réexécution en lecture seule était du gaspillage dépend d’un contexte qui n’est pas visible.
Une correspondance sha256 exacte est requise, donc la moindre différence dans la sortie empêche le signalement. C’est la raison du faible recall ; la conception privilégie la précision.
Claude Code est exceptionnellement bien optimisé. Sur six schémas candidats de gaspillage mesurés dans de vraies sessions CC, cinq n’y existaient pas. Le gaspillage intéressant est apparu non pas dans CC lui-même, mais dans des environnements MCP multi-outils.
L’estimation de coût (amplification) n’est pas une mesure mais une estimation, et elle n’est possible qu’avec le format Claude Code.
Ce qui n’est pas validé est abandonné
J’avais créé un détecteur de relecture de fichiers, puis je l’ai abandonné après qu’une annotation humaine sur un échantillon de 30 cas a montré une précision très inférieure au seuil préenregistré (70 %) : 3,3 % dans une lecture généreuse, 0 % dans une lecture stricte. Les prédictions et les résultats ont été conservés ensemble dans le document de préenregistrement.
Mise à jour de l’auteur. J’ai publié un article qui détaille séparément la partie serveur MCP, seulement mentionnée en une ligne dans le texte principal — l’idée est de résoudre le problème des agents qui choisissent les noms de colonnes à leur guise lors de l’écriture de migrations, en remplaçant le nom physique « saisi » par un nom « calculé » à partir d’un dictionnaire de mots :
https://sqemo.com/blog/erd-mcp-server
(Pour l’instant, c’est uniquement en local via stdio, donc le MCP distant n’est pas pris en charge ; l’application elle-même est fermée, seul le serveur MCP est open source.)
Vous pouvez l’essayer tout de suite sans inscription (app.sqemo.com), donc si quelque chose vous gêne, laissez un commentaire — c’est encore le début, les retours sont intégrés rapidement.
Journal des mises à jour (2026-07-25)
Depuis le premier billet, j’ai continué à faire évoluer Repolis au-delà d’un simple navigateur 3D de repo, vers une petite ville qui donne envie d’y revenir.
Plutôt que de créer un nouveau billet, je continuerai à consigner les changements ultérieurs à la suite de ce commentaire du billet d’origine.
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
Sur le clavier coréen du Mac, on ne peut pas le saisir T_T Avec Claude, il semble aussi utiliser beaucoup plus de Markdown dans ses réponses, mais pour les utilisateurs coréens ce n’est pas très familier...
Je l’ai aussi reçu, alors je l’ai essayé… mais bon, le coréen n’est pas encore au point 😢
Je suis l’auteur. Pour compléter avec quelques éléments qui n’ont pas pu être inclus dans l’article —
· La vidéo de démo (flux d’approbation sur téléphone, centre de commande desktop en 3 volets) est disponible en capture réelle sur la landing page : adhf.dev
· Le self-hosting se fait avec une seule ligne,
npm i -g adhdev, et le tableau de bord apparaît surlocalhost:3847(aucun compte nécessaire)· Les questions de conception sont les bienvenues, par exemple sur le merge en ff-only ou sur ce que la validation croisée MAGI détecte réellement
Si vous me faites des retours, je les intégrerai rapidement.
J’attendais plutôt GPT-6... Maintenant qu’Opus 5 est sorti, il ne faudrait pas qu’un nouveau modèle arrive ?
De nos jours, on parle non pas de dette technique, mais de dette cognitive.
Quand je discute parfois avec des collègues, il m’arrive souvent de voir qu’ils ne comprennent pas vraiment le fonctionnement de ce qu’ils ont pourtant eux-mêmes créé, et ça me donne un peu des frissons.
Avec le temps, on finira donc dans une situation où plus personne ne comprendra comment ça fonctionne, mais on peut aussi se dire que ce n’est peut-être pas un problème puisqu’il suffira de demander à l’IA de l’analyser et de lui poser la question.
J’adore ce genre d’articles.