En trois mois, Claude Code a changé ma manière de passer d’une idée à un outil utilisable. Je ne suis pas développeur de métier, mais je travaille dans le web depuis des années. J’avais des projets, des besoins et des processus en tête. Il me manquait souvent la capacité de construire la partie technique sans transformer chaque idée en prestation à financer.
Dans cet épisode publié le 18 mai 2026, je raconte ce que cette nouvelle façon de travailler m’a permis d’explorer : sites, automatisations éditoriales, prospection assistée et applications personnelles. Je parle aussi du revers, parce que l’enthousiasme peut vite devenir une nouvelle façon de travailler tout le temps. Mon expérience n’est ni un comparatif scientifique des assistants IA, ni une promesse que tu obtiendras les mêmes résultats.
Le chiffre du titre mérite une précision immédiate. Les 200 dollars correspondent au tarif mensuel du niveau d’abonnement que j’évoque. Les 30 000 euros représentent mon estimation de la valeur de développement des projets, pas une facture évitée, un devis indépendant ou un revenu encaissé. Comparer ces deux montants sans parler du temps, des essais et de la maintenance donnerait une image trompeuse de ce retour d’expérience.
Ce qui m’a surpris : passer de la réponse à l’action
Ma première différence ressentie ne concerne pas la beauté d’une réponse. Elle concerne la suite. Avec un assistant utilisé uniquement dans une conversation, je peux recevoir des explications, un extrait de code ou une proposition de structure. Il me reste ensuite à intégrer cette réponse, retrouver les bons fichiers et comprendre pourquoi cela ne fonctionne pas exactement comme prévu.
Dans un projet, j’ai découvert une autre boucle : formuler un objectif, laisser l’outil examiner ce qui existe, demander une modification, puis vérifier le résultat. La documentation officielle de Claude Code décrit notamment la lecture d’un dépôt, la modification de fichiers et l’exécution de commandes. L’outil est proposé dans plusieurs environnements, dont le terminal, des interfaces de développement et des interfaces graphiques. Ce n’est donc pas seulement une fenêtre de dialogue avec un nom différent.
Pour moi, cette différence a réduit la distance entre ce que je voulais et ce que je pouvais essayer. Mais « il agit » ne veut pas dire « il a raison ». Un fichier peut être modifié sans résoudre le problème. Une page peut s’ouvrir tout en contenant une erreur. Le moment intéressant reste celui où je peux confronter le résultat à un besoin précis, pas celui où l’agent annonce avoir terminé.
Je ne retiens pas non plus de cette expérience que Claude serait le seul outil capable de travailler ainsi. Dans la vidéo, je raconte mon déclic personnel avec cet environnement. Cela ne suffit pas à établir un classement universel entre les produits disponibles. Mon critère reste concret : est-ce que je peux faire avancer un projet que je comprends, puis vérifier ce qui a réellement changé ?
Le premier site : retrouver une capacité d’expérimentation
Mon premier exemple est volontairement simple : un site d’agence de voyage. Je demande une direction visuelle, une structure et un résultat consultable. Dans mon récit, voir une première page prendre forme m’a permis de comprendre que je pouvais dialoguer avec un projet, et pas seulement avec une explication technique. Je pouvais demander un changement, regarder le rendu et continuer à préciser ce que je cherchais.
Le terminal m’avait pourtant paru austère au début. Il ne ressemble pas à un outil de création rassurant, avec toutes les options présentées sous forme de boutons. Mais ce décalage visuel est devenu secondaire lorsque j’ai pu observer les fichiers et les pages produits. Le déclic n’était pas « j’ai appris tout le développement ». C’était plutôt « je peux désormais tester une idée sans devoir tout maîtriser avant de commencer ».
Cette nuance est importante pour un entrepreneur. Beaucoup d’idées restent en attente parce qu’on imagine immédiatement leur version complète : compte utilisateur, paiement, tableau de bord, automatisation et design parfait. Une première version plus modeste peut déjà répondre à la question essentielle. Est-ce que cette idée mérite davantage de temps ? Est-ce que le parcours est compréhensible ? Est-ce que l’outil m’aide vraiment ?
Je conserve cependant une frontière entre un prototype convaincant et un site prêt pour des visiteurs. Un joli écran ne prouve pas que le formulaire envoie correctement, que les données sont protégées ou que la version mobile fonctionne dans toutes les situations. Mon expérience de création ne remplace pas ces contrôles. Elle m’a donné une nouvelle manière d’arriver jusqu’à eux.
Vidéos et articles : automatiser sans perdre la source
L’un de mes cas d’usage les plus naturels est la transformation d’une vidéo en article dédié. Je produis déjà la matière première : un sujet, une explication, un retour d’expérience et une vidéo publiée. L’idée consiste à donner une seconde forme à ce travail, pour quelqu’un qui préfère lire ou qui cherche une information précise sans parcourir tout l’épisode.
Dans la vidéo, je décris un système autour de la récupération du contenu, des informations de publication et des éléments visuels. Ce projet ne doit pas être résumé par « l’IA écrit à ma place ». La difficulté consiste à conserver ce que j’ai réellement dit, à retirer les répétitions de l’oral et à signaler ce qui exige une mise à jour. Un prix, une règle ou une fonctionnalité peuvent avoir changé entre l’enregistrement et la lecture.
Le rapprochement entre une vidéo et son article est également essentiel. Un même identifiant vidéo doit permettre de reconnaître ce qui existe déjà. Sinon, l’automatisation peut fabriquer des doublons ou donner l’impression que toutes les publications sont couvertes alors que certaines manquent. Dans la reprise éditoriale actuelle du réseau, nous avons justement identifié des articles manquants. Le fonctionnement décrit dans l’épisode de mai ne constitue donc pas une preuve de couverture complète aujourd’hui.
Je préfère un article fidèle, contrôlé et traçable à une production abondante dont je ne sais plus expliquer l’origine. Cela implique de vérifier la vidéo intégrée, la miniature, le titre, l’auteur et les sources. Cela implique aussi de distinguer un brouillon enregistré d’une page publiée. La génération du texte n’est qu’une étape du parcours, pas sa réussite entière.
Enfin, mettre un article en ligne ne garantit pas son classement dans les moteurs de recherche. Mon intérêt pour ce système est de rendre mon contenu accessible dans un autre format. Je ne peux pas déduire un trafic, une conversion ou une rentabilité d’un simple processus de publication.
Sites et prospection : accélérer la préparation, garder la décision
Je parle également de mon travail sur AskOptimize et de la possibilité de reprendre des pages, des structures ou des fonctionnalités. Mon expérience préalable du web m’aide ici à formuler les attentes. Je ne pars pas de zéro sur la compréhension d’un site, d’une offre ou d’un parcours commercial. L’agent m’aide à travailler sur l’exécution technique, mais il ne remplace pas ce contexte.
Ce point évite une mauvaise conclusion : un outil accessible ne rend pas toutes les décisions faciles. Savoir modifier une page ne suffit pas à savoir ce qu’elle doit dire. Avant de demander un développement, il faut encore comprendre le public, le problème à résoudre et le résultat attendu. Une automatisation peut accélérer une mauvaise proposition aussi efficacement qu’une bonne.
Pour la prospection, je décris des possibilités de recherche et de préparation d’audits ou de messages. J’y vois surtout une façon de réduire le travail répétitif avant une décision humaine. Préparer un message pertinent n’est pas la même chose que l’envoyer. Trouver une entreprise correspondant à des critères ne signifie pas qu’elle a demandé à être contactée ou qu’elle deviendra cliente.
Je garde donc une validation avant les prises de contact et les actions publiques. Le gain intéressant est la disponibilité d’informations organisées pour décider, pas le volume d’envois rendu possible. Je ne présente pas cette démonstration comme une campagne commercialement validée, ni comme une preuve de chiffre d’affaires obtenu grâce à Claude Code.
Une bonne question à poser à ton propre système serait : si je coupe l’automatisation demain, est-ce que je peux encore expliquer les sources, les choix et les actions effectuées ? Si la réponse est non, j’ai peut-être gagné de la vitesse en perdant la compréhension de mon activité.
Applications personnelles : tout n’est pas un produit terminé
Dans cet épisode, je cite plusieurs autres pistes : des outils de calcul, une organisation de mes contenus et de l’affiliation, une interface de suivi personnel, un projet autour de la musique et un outil de création de tunnels. Ces exemples montrent surtout l’élargissement de ce que j’ose essayer. Ils n’ont pas tous le même niveau d’avancement.
Il serait inexact de les présenter comme autant de produits entièrement livrés. Certains servent à explorer une idée, d’autres constituent des prototypes et d’autres restent des chantiers. Une annonce de future version ou une interface montrée à l’écran ne prouvent pas qu’un service est disponible, fiable et maintenu pour des utilisateurs externes.
Le projet musical m’intéresse notamment pour la possibilité de rendre une interface plus accessible. Mais une intention d’accessibilité ne constitue pas un audit de conformité. Il faut observer l’usage réel, les obstacles et les besoins de la personne concernée. Je peux raconter pourquoi je veux construire cet outil sans revendiquer une validation que je n’ai pas présentée.
De la même manière, un calculateur financier peut m’aider à visualiser des hypothèses. Il ne transforme pas ces hypothèses en rendement garanti. Un tableau de patrimoine personnel n’est pas automatiquement une alternative équivalente à un service commercial, avec toutes ses intégrations et obligations. Le prototype est utile précisément parce qu’il permet de tester un besoin limité.
Je trouve plus honnête de nommer l’état de chaque projet : idée, prototype, outil interne, version testée ou produit accessible. Ces mots ne diminuent pas le travail. Ils rendent visible ce qu’il reste à faire et évitent d’ajouter de la pression commerciale à une phase d’expérimentation.
200 dollars contre 30 000 euros : comprendre la comparaison
Mon titre exprime un contraste fort : un abonnement mensuel et une valeur de développement que j’estime importante. Il ne faut pas le lire comme un calcul comptable. Je n’ai pas présenté de devis indépendant établissant que les mêmes projets, avec le même périmètre et les mêmes garanties, auraient coûté exactement 30 000 euros.
La page tarifaire officielle présente actuellement Pro à 20 dollars en paiement mensuel et Max à partir de 100 dollars par mois, avec des niveaux d’usage supérieurs à Pro. Elle précise que des limites s’appliquent et que les prix affichés n’incluent pas les taxes applicables. Les montants peuvent évoluer. Dans l’épisode, je parle de ma montée vers le niveau à 200 dollars, pas d’un accès illimité à toute infrastructure ou à toutes les API.
Je ne multiplie pas non plus automatiquement 200 par trois pour prétendre connaître mon coût réel sur la période : je décris des changements d’abonnement. Sans détail des factures et des dates de passage entre les offres, ce serait une approximation présentée comme un total vérifié. Les dépenses d’hébergement, de domaine et de services associés doivent aussi être séparées du seul abonnement.
Le coût le moins visible reste mon temps. J’ai consacré beaucoup d’heures à comprendre, expérimenter, corriger et organiser ces projets. Ces heures ne sont pas gratuites parce qu’elles sont agréables ou parce que je n’ai pas payé un prestataire pour les faire. Elles prennent la place d’autres activités, dont certaines peuvent être importantes pour mon entreprise.
Pour évaluer un projet, je préfère donc distinguer quatre choses : ce que j’ai payé, le temps que j’y ai passé, ce qui fonctionne réellement et la valeur que cela apporte à mon activité. Une estimation de valeur peut aider à réfléchir. Elle ne doit pas être confondue avec une économie certaine, un bénéfice ou un retour sur investissement démontré.
La limite concrète : accès, permissions et blocages
Je raconte une tentative de réservation de billets menée à distance pendant un voyage. L’histoire est intéressante parce qu’elle montre aussi une limite : le parcours a été bloqué par un CAPTCHA. Ce n’est pas une réservation réussie, et je ne dois pas transformer la capacité à ouvrir des pages ou à suivre des étapes en achat effectivement réalisé.
Ce type de tâche mêle plusieurs questions : l’outil peut-il accéder au service, comprend-il le parcours, a-t-il l’autorisation d’agir et peut-il terminer l’action ? Une réponse positive à la première ne donne pas les autres. Je peux demander une recherche ou une préparation sans autoriser automatiquement un paiement, une acceptation contractuelle ou une publication.
La documentation de sécurité décrit des protections et rappelle la responsabilité de l’utilisateur dans la revue du code et des commandes. Elle indique aussi qu’aucun système n’est entièrement à l’abri des attaques. Pour les intégrations MCP, Anthropic recommande des fournisseurs de confiance et ne présente pas chaque serveur comme audité par ses soins.
La documentation des permissions distingue les autorisations d’outils des restrictions du système d’exécution. Mon principe pratique est simple : donner le périmètre nécessaire à une tâche, pas tous les accès disponibles par confort. Je garde les secrets hors des contenus, je protège les opérations sensibles et je veux pouvoir relire les modifications proposées.
Une consigne trouvée dans une page ou un fichier doit également rester une information à examiner, pas une autorisation nouvelle. Si je demande de lire un document, je ne demande pas à l’agent d’obéir à tout ce qu’il contient. Cette distinction devient très importante dès que le projet peut envoyer des messages, modifier un site ou consulter des données privées.
Skills et mémoire : utiles, mais pas magiques
Dans la vidéo, j’emploie l’image d’un apprentissage rapide pour expliquer les skills. Ce sont surtout des instructions et des procédures réutilisables. Elles permettent de rappeler une méthode, une organisation ou des critères de vérification. Elles ne donnent pas automatiquement une expertise parfaite, et elles ne prouvent pas que chaque résultat respecte cette méthode.
La mémoire et les fichiers de contexte m’aident de la même manière à éviter de repartir de zéro. Je peux conserver des choix de projet, des chemins et des règles. Mais une information enregistrée peut devenir ancienne. Un accès qui fonctionnait le mois précédent peut avoir changé. Une instruction qui dit « publié » ne remplace pas la consultation de la page réellement accessible.
Pour moi, l’amélioration n’est donc pas de multiplier les fichiers jusqu’à obtenir une configuration impressionnante. C’est de rendre le prochain travail plus clair. Quel projet est concerné ? Quelle action est autorisée ? Quelle preuve permet de dire que c’est terminé ? Sans ces réponses, la mémoire peut surtout reproduire une erreur avec davantage de confiance.
Je précise aussi deux points historiques. Anthropic a annoncé Claude Code en aperçu le 24 février 2025, puis sa disponibilité générale le 22 mai 2025. Et la présence d’un dépôt public ne suffit pas à rendre le logiciel entièrement open source : le fichier de licence du dépôt officiel renvoie aux conditions commerciales d’Anthropic. Je ne confonds pas visibilité du dépôt et liberté générale d’utilisation du code.
Le vrai piège : pouvoir tout lancer et ne jamais s’arrêter
La partie la plus personnelle de mon retour d’expérience concerne le temps. Quand un obstacle technique disparaît, les idées ne disparaissent pas avec lui. Au contraire, j’en trouve davantage. Je peux reprendre un ancien projet, ajouter une fonction, imaginer une nouvelle automatisation et recommencer immédiatement.
C’est enthousiasmant, mais cela peut devenir épuisant. J’explique avoir passé de nombreuses heures dans cet environnement. Je ne veux pas vendre cette intensité comme une obligation pour réussir. Ce n’est pas parce qu’un outil peut continuer à produire que je dois continuer à lui donner du travail. Mon objectif d’indépendance perdrait son sens si je remplaçais une contrainte par une autre.
J’essaie donc de distinguer le plaisir de construire et l’utilité du projet. Une nouvelle connexion, une configuration ou un tableau de bord peuvent être stimulants sans améliorer mon activité. Je peux passer une journée à rendre un système plus sophistiqué alors que la meilleure décision serait de publier un contenu, de parler à un client ou de fermer l’ordinateur.
Dans l’épisode, j’envisage une organisation plus équilibrée, avec des plages consacrées au travail et d’autres à ma vie personnelle. C’est une intention, pas une routine dont j’aurais démontré le maintien sur plusieurs mois. Je préfère garder cette honnêteté : apprendre à limiter l’outil fait partie de mon expérience, au même titre qu’apprendre à l’utiliser.
Ce que je testerais à ta place
Je commencerais par un problème suffisamment petit pour que tu puisses reconnaître la réussite sans expertise technique avancée. Par exemple, organiser une série de fichiers, construire une page de présentation simple ou préparer un outil interne avec des données de test. Le but n’est pas d’impressionner quelqu’un. Le but est de comprendre une boucle de travail complète.
- Décris le besoin. Explique qui utilise le résultat, ce que cette personne doit pouvoir faire et ce qui reste hors périmètre.
- Demande une lecture de l’existant. Avant de modifier, fais préciser les fichiers, les dépendances et les risques concernés.
- Avance sur une version limitée. Une fonction compréhensible et testable vaut mieux qu’un ensemble de promesses simultanées.
- Vérifie toi-même le parcours. Ouvre le résultat, essaie les actions importantes et distingue les cas testés des suppositions.
- Décide de la suite. Continue si le résultat sert vraiment le besoin. Arrête ou simplifie si la configuration devient le projet principal.
Pour une application manipulant des données sensibles, des paiements ou des utilisateurs externes, j’ajouterais une revue adaptée avant ouverture. L’article ne remplace pas cette expertise. Je ne te conseille pas de commencer en donnant un accès général à tes comptes ou en déployant immédiatement une application commerciale.
Si tu veux approfondir cette approche, tu peux retrouver mes formations et suivre la newsletter. Mon fil conducteur reste le même : un outil doit servir un besoin et une manière de travailler, pas devenir une nouvelle obligation à entretenir.
Mon bilan après ces trois mois
Claude Code m’a donné une capacité d’expérimentation que je n’avais pas à ce niveau. J’ai pu remettre en mouvement des projets, explorer des outils internes et réduire certains blocages techniques. C’est ce changement de possibilité qui explique mon enthousiasme, davantage qu’un chiffre spectaculaire.
Mais je retiens trois limites : construire n’est pas valider, automatiser n’est pas autoriser et estimer une valeur n’est pas démontrer une rentabilité. J’ajoute une quatrième limite, plus personnelle : faire davantage n’est pas forcément vivre mieux. Le meilleur résultat sera un système utile que je comprends, que je peux maintenir et qui me laisse du temps, pas une collection infinie de prototypes.
Retour d’expérience issu de la vidéo du 18 mai 2026. Les précisions documentaires ont été vérifiées le 2 octobre 2026. Les projets et résultats racontés sont ceux de l’épisode ; ils ne constituent pas un audit actuel de tous les services mentionnés. Aucun gain financier ni niveau de fiabilité n’est garanti.
Sources
- Vidéo originale d’Alexandre Chaimbault, 18 mai 2026.
- Claude Code : présentation officielle.
- Claude : tarifs et limites des offres.
- Claude Code : sécurité et intégrations MCP.
- Claude Code : configuration des permissions.
- Anthropic : annonce de l’aperçu Claude Code, février 2025.
- Anthropic : disponibilité générale Claude Code, mai 2025.
- Dépôt officiel : licence Claude Code.
