Trois semaines, une application : Ce que l'IA peut construire pour vous et ce qu'elle ne peut absolument pas faire

Il y a trois semaines, j'avais un backend .NET avec peut-être 40 % des services connectés, un frontend Vue à moitié terminé et un plan vague. Aujourd'hui, Rasepi dispose d'un moteur de traduction au niveau du bloc avec gestion de glossaire et règles de style, d'un système de notation de la fraîcheur avec modèles d'expiration et flux de travail de révision, d'une recherche sémantique alimentée par l'IA avec RAG, d'un SDK de plugin complet avec action guards et event pipelines, d'une édition collaborative en temps réel, d'un site web marketing complet avec pages de tarification, d'un portail de documentation pour les développeurs, d'un blog avec 14 articles, de traductions automatisées en 7 langues et d'un formulaire de liste d'attente qui envoie réellement des courriels.

Je n'ai pas fait cela tout seul. J'ai fait tourner Claude dans VS Code tous les soirs pendant des heures et parfois même toute la journée, et cela a été une véritable transformation pour les parties qu'il pouvait aider. Mais il y a un gouffre entre "construire une application" et "avoir quelque chose que vous pourriez réellement vendre à un autre être humain", et ce gouffre est rempli de tonnes de pages d'installation, de configuration manuelle, de paramètres de délivrabilité des courriels et d'enregistrements DNS. Claude ne peut pas encore communiquer avec tous ces services.

Les gens parlent rarement de cette partie.

Est-ce que j'aurais pu faire ça sans l'IA ?

J'ai plus de 30 ans d'expérience dans la création de logiciels. Aurais-je pu construire tout cela sans Claude ? Probablement. Mais pas en trois semaines. Loin s'en faut. L'IA a accéléré tout ce qui implique de taper du code dans des fichiers, et c'est une partie importante de tout projet.

Mais il y a une chose que les gens oublient lorsqu'ils parlent de "vibrocodage" et de construction d'applications entières avec l'IA : il faut toujours savoir ce que l'on fait : **Claude peut vous indiquer toutes les étapes nécessaires pour déployer un Cloudflare Worker avec une base de données D1. Il peut vous guider dans la configuration d'OpenIddict. Il peut expliquer les enregistrements DNS et la configuration de SPF. Le problème est que ses connaissances sont souvent obsolètes. Les plateformes mettent à jour leurs tableaux de bord, déplacent les paramètres, suppriment des fonctionnalités, renomment des choses. Et Claude ne le sait pas.

Je n'ai même pas utilisé qu'une seule IA. ChatGPT en savait parfois plus sur des services spécifiques, en particulier lorsque les données de formation de Claude avaient quelques mois de retard sur la documentation d'une plateforme particulière. Certains jours, j'avais les deux IA ouvertes côte à côte, croisant leurs suggestions avec ce que je voyais réellement dans le tableau de bord.

Et puis il y a Codex. J'ai souvent utilisé le Codex d'OpenAI pour analyser la base de code de l'extérieur. Non pas pour écrire du code, mais pour le réviser. Le fait qu'un autre agent examine le code que Claude a écrit permet de déceler des choses auxquelles Claude lui-même n'a pas accès. C'est comme avoir une deuxième paire d'yeux sur une demande de retrait, sauf que les deux réviseurs sont des IA et qu'aucun d'entre eux ne s'offusque. J'ai pointé Codex sur une couche de service et j'ai demandé " qu'est-ce qui ne va pas avec ça ? " et il a trouvé des problèmes que Claude avait introduits avec confiance il y a trois sessions. Les différents modèles ont des angles morts différents, et les confronter les uns aux autres permet d'obtenir de meilleurs résultats que de faire confiance à un seul d'entre eux.

Mais le point le plus important est le suivant : pour avoir une application vendable, vous devez absolument savoir comment fonctionne l'hébergement. Comment fonctionnent les domaines. Comment fonctionnent les certificats de signature de code. Comment fonctionnent les bases de données. Comment fonctionne la délivrabilité des courriels. Comment les flux OAuth2 fonctionnent réellement, et pas seulement le code qui les met en œuvre. Pouvez-vous créer une application sans ces connaissances ? Bien sûr, mais cela vous mènera-t-il quelque part ? Probablement pas. Vous aurez quelque chose qui tourne sur localhost et qui n'impressionne personne en dehors de votre propre machine.

Les 80 % qui ressemblent à de la magie

Laissez-moi être clair sur ce qui a fonctionné, parce que cela a vraiment bien fonctionné. Pour créer des interfaces de service, implémenter des contrôleurs CRUD, écrire des configurations EF Core et construire des composants Vue, Claude est absurdement rapide.

Voici un exemple. Lorsque j'ai eu besoin d'ajouter un système de gestion de glossaire, j'ai décrit les besoins : glossaires adaptés aux locataires, importation/exportation CSV, CRUD pour les termes individuels, et un mécanisme de synchronisation avec l'API de glossaire de DeepL. Claude a produit les modèles d'entité, les interfaces de service et les interfaces de service pour le système de gestion de glossaire. Claude a produit les modèles d'entités, l'interface et l'implémentation du service, le contrôleur avec les attributs d'autorisation appropriés et le magasin Pinia. Le tout en 20 minutes environ. Il m'aurait fallu plus d'une journée pour écrire tout cela à la main.

Le moteur de traduction était similaire. L'architecture au niveau du bloc avec le hachage du contenu SHA256, la détection de la staleness, l'orchestrateur qui coordonne entre les services. Claude a compris le modèle après l'avoir expliqué une fois et l'avoir reproduit de manière cohérente sur des dizaines de fichiers. Le système de notation de la fraîcheur, les flux de travail de révision, le pipeline de notification d'expiration. Service après service, connecté et fonctionnel.

Pour le site de marketing, Claude a construit des pages HTML entières à partir de descriptions. "Une page de prix avec un niveau gratuit, un niveau équipe et un niveau entreprise. Fond sombre. Utiliser l'accent vert." Et il a juste... produit une page. Y compris les points de rupture réactifs et les états de survol.

C'est la partie magique. C'est réel.

Apprivoiser la machine

Mais ce n'est pas comme si j'avais simplement tapé "construisez-moi une application" et que j'étais parti. Travailler avec Claude est une compétence à part entière, et j'ai passé les premiers jours à mal le faire.

Le résultat initial est toujours... bon. Techniquement correct, raisonnablement structuré, mais générique. Claude écrit du code comme il écrit de la prose : compétent, prévisible et profondément moyen. Laissé à lui-même, il produira la même structure de contrôleur que tous les tutoriels de frameworks. Le même modèle de service. La même disposition des composants. Cela fonctionne, mais ce n'est pas le vôtre.

Vous commencez donc à l'entraîner. Pas de manière formelle, pas avec des réglages fins, mais par la répétition et la correction. "Non, je veux que l'interface de service soit séparée de l'implémentation. "Utilisez toujours ce modèle d'attribut d'autorisation." "Le contexte du locataire provient de l'intergiciel, pas du corps de la requête." Tour après tour après tour. Certains jours, j'avais l'impression d'être en train de programmer en binôme avec un junior très enthousiaste qui n'arrêtait pas d'oublier ce que nous avions décidé hier.

Et puis, il y a eu un déclic. Après suffisamment de corrections, après suffisamment d'exemples dans la base de code pour qu'il puisse les lire, Claude commence à faire les choses correctement du premier coup. Il comprend vos conventions de nommage. Il sait où vous placez vos DTO. Il suit votre modèle de gestion des erreurs sans qu'on le lui demande. Cette transition de "gênant" à "productif" a pris environ quatre ou cinq jours de travail régulier.

Il en a été de même pour les articles de blog. La voix d'écriture par défaut de Claude est immédiatement reconnaissable. Ce style poli, légèrement distant, parfaitement structuré, qui se lit comme tous les billets de blog générés par l'IA que vous avez déjà vus. J'ai construit un guide de style à plusieurs reprises, en lui donnant des exemples de ma façon d'écrire, en lui faisant remarquer chaque " il est bon de le noter " et chaque tiret em (sérieusement, l'addiction au tiret em est réelle). Finalement, j'ai créé tout un fichier de compétences, un ensemble d'instructions que Claude charge avant d'écrire quoi que ce soit pour le blog Rasepi.

Ce billet, pour mémoire, c'est Claude. Avec mes commentaires, mes corrections, ma direction. J'ai décrit ce que je voulais dire, je l'ai dirigé vers le guide de style, puis j'ai passé du temps à faire des allers-retours jusqu'à ce que la voix me semble correcte. C'est le véritable flux de travail. Ce n'est pas "l'IA l'écrit" ni "je l'écris". C'est une conversation qui produit quelque chose qu'aucun de nous n'aurait écrit seul.

J'ai également élaboré des instructions personnalisées pour la base de code elle-même. Un fichier d'instructions pour le copilote qui explique l'architecture, le système de traduction, les règles d'isolation des locataires, les conventions de codage. Claude le lit au début de chaque session, et la différence se fait jour et nuit. Sans ce fichier, Claude devine. Avec, Claude sait.

Le fait est que les gains de productivité sont réels, mais ils ne sont pas gratuits. Vous investissez du temps au départ pour apprendre à l'IA comment vous travaillez, et cet investissement est rentabilisé au fil des semaines. Si vous sautez cette étape, vous passerez plus de temps à corriger les résultats de Claude que vous n'en auriez passé à écrire le code vous-même.

Quand la machine vous combat

Je ne veux pas brosser un tableau trop rose de la situation. Pour chaque session où Claude a réussi à implémenter un service complexe en 20 minutes, il y a eu une autre session où il m'a mis au pied du mur.

La pire habitude est de réintroduire des bogues qui ont été corrigés il y a plusieurs jours. Vous passez une soirée à traquer une condition de course dans le hub SignalR, vous la corrigez et vous passez à autre chose. Trois jours plus tard, Claude modifie un fichier voisin et réintroduit discrètement l'ancien modèle brisé. Ce n'est pas malintentionné, évidemment. Il ne s'en souvient tout simplement pas. Chaque session recommence, et si la correction n'était pas évidente à partir du code seul, Claude reviendra volontiers au modèle que ses données d'apprentissage préfèrent. J'ai appris à écrire des commentaires très explicites au-dessus des corrections délicates. Pas pour les futurs développeurs. Pour les futurs Claude.

Ensuite, il y a le cercle. Vous demandez à Claude de corriger un test défaillant. Il modifie quelque chose. Le test échoue toujours. Il change autre chose. Le test échoue encore. Il annule la première modification et essaie une troisième chose. Il combine ensuite la première et la troisième modification. Puis il revient à la deuxième approche, mais avec une légère variation. Trente minutes plus tard, vous l'avez vu essayer neuf permutations de la même idée erronée et pas une seule fois il ne s'est arrêté pour reconsidérer si l'ensemble de l'approche était erronée. J'ai eu des sessions où j'ai finalement dit "arrêtez, laissez-moi regarder ça" et j'ai trouvé le vrai problème en deux minutes environ. Il s'agissait d'une correction d'une seule ligne. Claude avait passé une demi-heure à réarranger les chaises longues.

Et la confiance. Claude ne dit jamais "Je ne suis pas sûr de ça". Il présente chaque suggestion avec la même autorité calme, qu'il s'agisse d'une solution parfaite ou d'une absurdité totale. Après un certain temps, vous développez un instinct pour savoir quand il devine, mais au début, j'ai perdu beaucoup de temps à mettre en œuvre des suggestions qui semblaient raisonnables et qui se sont avérées être des méthodes d'API hallucinées ou des modèles de configuration obsolètes.

C'est exactement la raison pour laquelle j'ai commencé à utiliser le Codex pour examiner les résultats de Claude. Et c'est pourquoi l'argument de l'expérience est si important. Un développeur débutant ne verrait pas ces régressions. Il ne reconnaîtrait pas les cercles. Il se fierait à l'hallucination confiante. Trente ans de connaissance de ce à quoi ressemble un code correct, c'est la différence entre l'IA en tant que multiplicateur de productivité et l'IA en tant que moyen très rapide de créer de la dette technique.

Ensuite, il faut réellement déployer la chose

C'est ici que l'histoire change.

Vous avez une application qui fonctionne sur localhost. Magnifique. Maintenant, mettez-la sur Internet. Faites en sorte qu'elle envoie des courriels. Laissez les gens s'inscrire. Accepter des paiements éventuellement. Protégez-le des robots. Donnez-lui un nom de domaine qui se résout correctement.

Claude ne peut pas vous aider pour tout cela. Pas vraiment.

Je ne veux pas dire qu'il produit de mauvaises suggestions. Je veux dire qu'il ne peut fondamentalement pas interagir avec les systèmes que vous devez configurer. Et c'est à la configuration que vous consacrez votre temps, pas à l'écriture de code.

Cloudflare : Une étude de cas pour "se débrouiller tout seul"

Le site de marketing de Rasepi fonctionne sur des pages Cloudflare. L'API de la liste d'attente est un Cloudflare Worker avec une base de données D1. Cela semble simple jusqu'à ce que vous ayez à le mettre en place.

Claude n'a jamais vu votre tableau de bord Cloudflare. Il peut vous dire "ajouter un enregistrement CNAME" mais il ne peut pas vous dire lequel des 14 onglets contient les paramètres DNS pour votre domaine particulier. Les liaisons de base de données D1 nécessitent un identifiant de base de données spécifique dans votre wrangler.toml. Les secrets d'environnement passent par wrangler secret put. CORS doit correspondre à vos origines réelles déployées, et non à localhost. Turnstile a besoin de clés provenant d'une autre section du tableau de bord.

J'ai passé presque une journée entière à faire en sorte que le Worker vérifie correctement les tokens Turnstile, accepte les soumissions de formulaire, les stocke dans D1, et envoie des emails de confirmation. Claude m'a aidé à écrire le code du Worker lui-même. Mais le déploiement, la configuration du wrangler, la gestion des secrets, le débogage de la propagation DNS ? Tout cela, c'est moi qui l'ai fait.

OAuth2 : Le labyrinthe de la configuration

L'authentification est le meilleur exemple du fossé qui sépare le "code" du "produit".

Claude peut tout à fait vous écrire une intégration OAuth2. Il connaît la spécification OIDC, il peut produire un middleware, il comprend les revendications JWT. Pour notre environnement de développement, j'ai un DevAuthHandler qui frappe des jetons avec des revendications tenant_id et sub à partir d'un simple modèle de chaîne de caractères. Claude a écrit cela en quelques minutes.

Mais l'authentification de production signifie OpenIddict, et OpenIddict signifie comprendre les revendications sub, les revendications tenant_id, les URL de rappel, les origines JavaScript, les URI de déconnexion, et toutes les autres manigances qui viennent avec une vraie configuration d'identité. Et ce, avant même d'aborder les fournisseurs externes.

Parce que vos utilisateurs veulent se connecter à Google, Microsoft ou GitHub. Et Claude ne peut se connecter à aucune de ces consoles de développement pour vous. Il ne peut pas :

Créer une application OAuth dans la Google Cloud Console et générer un identifiant et un secret client.
Enregistrer une application dans le portail Microsoft Entra et configurer les URI de redirection.
Configurer une application OAuth GitHub et récupérer les informations d'identification.
Configurez les URL de rappel de chaque fournisseur pour chaque environnement que vous exécutez.
Configurer les champs d'application, les écrans de consentement et les points de terminaison des jetons corrects.

Chaque fournisseur a son propre portail de développement, sa propre terminologie et son propre processus de génération d'informations d'identification. Google parle d'"écran de consentement". Microsoft parle d'"enregistrement d'applications". GitHub parle d'"OAuth Apps" (à ne pas confondre avec les "GitHub Apps", qui sont tout à fait différents). Et chacun d'entre eux vous oblige à copier manuellement un identifiant client et un secret dans votre configuration.

Claude peut écrire la configuration du serveur OpenIddict, le middleware du fournisseur externe, la logique de transformation des demandes. Mais la génération des identifiants, la navigation sur le portail, la configuration des URL spécifiques à l'environnement ? Tout cela, c'est vous qui le faites, dans un navigateur, en cliquant sur des tableaux de bord.

Email : Il ne s'agit jamais simplement d'"envoyer un courriel"

Le code pour envoyer un email via l'API Resend est d'environ 15 lignes. Claude l'a écrit sans problème. Mais faire en sorte que les courriels arrivent réellement dans la boîte de réception de quelqu'un ? Cela nécessite un domaine d'envoi vérifié, des enregistrements DNS pour SPF, DKIM et DMARC, d'attendre la propagation, puis de tester la délivrabilité parce que Gmail et Outlook ont leurs propres opinions sur la fiabilité de votre domaine.

Et concevoir un modèle d'e-mail qui ne soit pas horrible dans tous les clients de messagerie. Outlook sur Windows utilise toujours le moteur de rendu Word en 2026. Laissez-vous convaincre.

La liste complète des choses que j'ai faites sans l'IA

En repensant à mes trois semaines de travail, j'ai commencé à faire un décompte mental approximatif de ce que Claude a construit et de ce que j'ai configuré à la main. La liste "à la main" est plus longue que je ne le pensais :

Infrastructure Cloud:

Installation du projet Cloudflare Pages et configuration du domaine personnalisé
Déploiement de Cloudflare Worker et provisionnement de la base de données D1
Enregistrements DNS pour le site marketing, l'API et l'envoi d'emails
Configuration des certificats SSL/TLS (la plupart du temps automatique, mais le débogage quand ce n'est pas le cas est pénible)
Configuration du pipeline de construction pour le blog (Eleventy + traduction + génération d'images OG)

Authentication & Sécurité:

Enregistrement des applications OAuth de Google, Microsoft et GitHub et génération des informations d'identification
Configuration d'OpenIddict avec des revendications correctes, des URL de rappel, des origines JS et des URI de déconnexion.
Configuration de la protection des robots Turnstile (clés de site, clés secrètes, configuration du tableau de bord)
Configuration de la politique CORS entre le frontend, l'API et les origines Worker

Email:

Configuration du compte de renvoi et de la clé API
Enregistrements DNS SPF, DKIM, DMARC
Tests de délivrabilité des courriels et dépannage
Tests de modèles sur les clients de messagerie

Intégrations tierces:

DeepL Gestion des comptes et des clés API
Configuration de Google Analytics avec intégration du consentement aux cookies

Hébergement Azure:

Installation et configuration d'Azure App Service pour le backend .NET
Provisionnement de la base de données Azure SQL, règles de pare-feu et chaînes de connexion
Configuration d'Azure Cache for Redis et configuration des connexions
Provisionnement des ressources Azure OpenAI pour les embeddings et RAG

**Déploiement

Configuration Docker pour le backend .NET
Gestion des variables d'environnement pour trois cibles de déploiement différentes
Chaînes de connexion à la base de données pour différents environnements

Et honnêtement, j'oublie probablement quelques éléments. Chaque service tiers a son propre tableau de bord, son propre modèle d'authentification, sa propre qualité de documentation (qui varie énormément) et ses propres particularités.

Pourquoi cela est plus important qu'on ne le pense

Voici la dimension qui se perd dans toutes les conversations sur le développement assisté par l'IA : Les outils d'IA n'ont aucun contexte sur votre infrastructure.

Votre base de code se trouve dans des fichiers qu'une IA peut lire. Votre configuration Cloudflare ne l'est pas. Les paramètres de votre application Google OAuth ne le sont pas. Vos enregistrements DNS ne le sont pas. Le statut de vérification de votre domaine Resend ne l'est pas. Toute la surface opérationnelle d'un produit réel est invisible pour les outils d'IA, et cette surface est énorme.

L'écriture du code est la partie la plus facile du génie logiciel, et elle devient de plus en plus facile. Ce qui est difficile, c'est ce que l'on fait avec ce code. L'exploiter, le comprendre lorsque quelque chose se casse à deux heures du matin, l'étendre lorsque les besoins changent et le gérer tout au long de son cycle de vie. L'IA permet d'accélérer la partie facile. Elle ne fait rien pour la partie difficile.

Le site marketing mérite sa propre section

J'ai construit l'ensemble du site marketing de Rasepi en quatre jours environ. Page d'accueil, page de prix, formulaires d'inscription et de contact avec protection contre les robots, politique de confidentialité, quatre pages d'approfondissement des fonctionnalités. Claude a fait probablement 70% du HTML/CSS.

Mais ensuite, j'ai eu besoin que le site existe réellement sur l'internet. Le blog fonctionne sur Eleventy avec un pipeline de construction en 8 étapes : traduction des posts via DeepL, construction du site, traduction des pages HTML statiques, copie des actifs partagés, génération des images OG à partir des SVG, génération des versions audio, gestion des manifestes audio, production d'un plan du site multilingue. Claude a participé à l'écriture de certains éléments de ce pipeline, mais il a fallu une journée entière d'essais et d'erreurs pour que tout fonctionne ensemble avec les bons chemins d'accès aux fichiers et les bons paramètres de déploiement des pages Cloudflare.

Et le site de documentation pour les développeurs ? Il s'agit d'un projet Cloudflare Pages distinct avec son propre domaine, sa propre configuration de construction et ses propres déclencheurs de déploiement. Un autre tableau de bord, un autre ensemble de variables d'environnement, une autre série de DNS.

Le modèle que je continue à voir

Pour une fonctionnalité donnée, Claude s'occupe d'environ 80% du travail en volume. Lignes de code, fichiers créés, problèmes résolus. Mais les 20% restants sont du travail de configuration entièrement manuel : cliquer sur des tableaux de bord web, copier des clés entre les services, déboguer des problèmes d'intégration qui n'apparaissent que dans des environnements déployés.

Et ces 20 % prennent au moins autant de temps que les 80 % restants. Parfois plus.

Mais voici ce qui a changé par rapport à la façon dont le développement en solo fonctionnait auparavant : dans le passé, vous écriviez du code ou vous faisiez de la configuration. Jamais les deux. Si vous passiez une journée à configurer les webhooks Stripe et à tester les flux de paiement dans leur tableau de bord, c'était une journée où vous n'écriviez aucun code d'application. Votre projet n'avançait pas sur un front pendant que vous travailliez sur l'autre.

Avec Claude, ce n'est plus vrai. Tandis que j'étais plongé dans le tableau de bord de Stripe à comprendre les points de terminaison des webhooks et les types d'événements, Claude construisait la prochaine interface de service. Pendant que je cliquais pour la troisième fois sur la configuration de l'écran de consentement OAuth de Google parce que je m'étais trompé dans les champs d'application, Claude écrivait des composants Vue. J'avais la tête dans la configuration, mais la base de code ne cessait de croître. C'est vraiment nouveau. Un développeur solo peut désormais agir sur deux fronts à la fois, et c'est peut-être la plus grande différence pratique que l'IA apporte aux petites équipes.

Cela dit, lorsque vous écrivez du code avec l'aide de l'IA, vous êtes dans une boucle de rétroaction étroite. Vous écrivez, vous testez, vous corrigez, vous itérez. Lorsque vous essayez de comprendre pourquoi votre Cloudflare Worker ne renvoie des erreurs CORS qu'en production, vous regardez les captures d'écran du tableau de bord, lisez les messages des forums de la communauté et essayez des changements de configuration aléatoires en espérant que l'un d'entre eux fonctionne.

Ce qu'il faut changer

Je ne pense pas qu'il s'agisse d'une limitation permanente. La pièce manquante est évidente : les outils d'IA doivent pouvoir interagir avec les API et les tableaux de bord de services tiers. Il ne s'agit pas seulement d'écrire du code qui les appelle, mais de les configurer.

Cela commence à se faire. Des serveurs MCP (Model Context Protocol) pour différents services apparaissent. Anthropic considère clairement l'utilisation des outils comme un concept de premier ordre. Mais nous sommes encore loin du point où je pourrais dire "configurer mon Cloudflare Worker avec une base de données D1, configurer le domaine personnalisé, et ajouter la protection Turnstile" et que cela se produise réellement.

En attendant, l'histoire honnête de la construction d'un produit avec l'IA est la suivante : **L'IA est un accélérateur incroyable pour l'écriture du code de l'application. L'autre moitié est constituée de l'infrastructure, des intégrations tierces, des pipelines de déploiement, de la délivrabilité des courriels, de la configuration des domaines et de la mise en place de la sécurité. Et pour tout cela, vous êtes seul.

(C'est d'ailleurs l'une des raisons pour lesquelles nous concevons Rasepi comme une plateforme hébergée et non comme un simple code open-source). Faire fonctionner un logiciel de documentation n'est pas si difficile. Le faire fonctionner de manière fiable, avec l'authentification, le courrier électronique et l'hébergement adéquats ? C'est ça le produit).

Si vous êtes sur le point d'essayer ceci

Quelques conseils pratiques que j'ai appris et qui pourraient vous faire gagner du temps :

Commencez par l'infrastructure, pas le code.** Configurez d'abord votre hébergement, votre fournisseur d'authentification, votre service de messagerie et vos domaines personnalisés. Faites en sorte qu'un "hello world" soit déployé en production avant d'écrire une seule ligne de code d'application réelle. Le nombre de problèmes qui ne font surface que dans des environnements déployés est déprimant.
Vous aurez des clés d'API, des identifiants de clients, des URL de rappel, des identifiants de base de données et des clés secrètes dispersés dans 8 tableaux de bord différents. J'utilise un fichier local crypté. Vous pouvez utiliser 1Password ou autre. Il suffit d'avoir un seul endroit.
Si Claude vous aide à créer la fonctionnalité en 2 heures, prévoyez 2 heures supplémentaires au minimum pour la déployer, configurer les intégrations et la tester en production.
Il y a eu des journées entières où je n'ai pratiquement pas écrit de code mais où j'ai fait des progrès décisifs : enregistrement d'applications OAuth chez trois fournisseurs, configuration du courrier électronique, débogage du DNS. Ces journées semblent moins productives, mais elles ne le sont pas.
Utilisez plusieurs agents les uns contre les autres.** N'utilisez pas qu'une seule IA. Demandez à Claude d'écrire le code, puis pointez Codex ou ChatGPT dessus et demandez-lui ce qui ne va pas. Différents modèles détectent différentes choses. Cela semble redondant, mais c'est ce qui se rapproche le plus d'une revue de code que vous obtiendrez en tant que développeur solo.

Trois semaines, c'est toujours très rapide pour ce que j'ai construit. Je ne me plains pas de Claude. Il a permis à un seul développeur de construire quelque chose qui aurait normalement pris à une petite équipe la majeure partie d'une année. Mais l'histoire racontée dans le cycle de l'engouement pour l'IA (demander, coder, livrer, terminé) ne comprend pas toute la partie centrale où l'on rend les choses réelles.

L'application est la partie facile. La rendre réelle, c'est le travail.