CONSTRUIRE DES LOGICIELS AVEC CLAUDE

Construire des logiciels en 2026 avec Claude comme collaborateur en ingénierie principale change la courbe des coûts et la structure de l'équipe, pas le métier sous-jacent. Les parties critiques du logiciel (quoi construire, pourquoi, comment se comporter en cas d'échec) requièrent toujours l'attention humaine. Les parties d'exécution (écrire le code, refactoriser, générer du boilerplate, exécuter les migrations) se compriment dramatiquement. Savoir distinguer l'une de l'autre, c'est toute la compétence en 2026.

Ce guide est le workflow que j'utilise réellement pour déployer des produits sur mesure chez Seahawk Media et sur des projets personnels comme HostList.io, gautamkhorana.com, et Deluxe Astrology. Pas un tutoriel Claude, pas un manuel d'ingénierie de prompts. La discipline de processus qui produit des logiciels déployables avec Claude comme ingénieur porteur.

Étape 1 : brainstorm structuré

Avant d'écrire du code, je fais un brainstorm structuré avec Claude. L'approche : décrire le problème en langage courant, demander à Claude de soulever cinq questions dont les réponses changeraient la conception, y répondre, puis demander à Claude de résumer la spécification produit en 200 mots. Cette étape prend 30 à 60 minutes et produit une spécification écrite qui guide tout le reste du travail.

Étape 2 : décisions techniques

Avec la spécification en main, je demande à Claude d'identifier les choix architecturaux qui ont le plus grand impact en aval. La forme de la base de données, la surface de l'API, la stratégie de rendu, le modèle de déploiement. Pour chacun, Claude propose deux ou trois options et les compromis. Je choisis. Les décisions sont documentées dans le même document pour que la phase de construction ait une source de vérité unique.

Étape 3 : implémentation guidée par la spécification

La génération de code est la dernière étape, et elle est la plus rapide parce que la spécification est déjà complète. Claude écrit le schéma, les requêtes, les composants, les routes, les tests, à peu près dans cet ordre. Je revois chaque commit. La plupart des revues mettent en lumière une petite refactorisation ou un cas limites manquant ; les réécriture complètes sont rares quand la spécification était claire.

Bien fait

Code sur greenfield dans des patterns bien connus : APIs REST, panneaux d'administration CRUD, flux d'authentification, moteurs de blog, sites marketing. Refactorisation de code existant où la forme cible est clairement énoncée. Génération de tests pour du code qui a des entrées et des sorties claires. Écriture de scripts de migration quand la différence de schéma est sans ambiguïté. Rédaction de documentation. Débogage de code où le symptôme est reproductible et la trace est en contexte.

Moins bien fait

Décisions architecturales dans des domaines peu familiers. Code d'intégration où l'API tierce est mal documentée ou a changé récemment. Optimisation de performance où le goulot d'étranglement n'est pas évident. Génération de code dans des langages ou frameworks obscurs où les données d'entraînement sont minces. Tout cas où les exigences sont ambiguës et l'LLM remplira les vides avec des défauts plausibles mais erronés pour votre situation spécifique.

L'écart de jugement

Claude est systématiquement meilleur que l'ingénieur médian pour écrire la ligne de code suivante. Claude est systématiquement moins bon qu'un ingénieur senior pour décider si la ligne de code suivante devrait exister. La couche de jugement senior, c'est ce que vous apportez. La vitesse d'exécution, c'est ce que Claude apporte. La combinaison surpasse l'un ou l'autre seul.

Claude Code comme interface principale

Claude Code est l'IDE pour le développement assisté par l'IA. Contexte du projet chargé une fois, accès au terminal, accès au système de fichiers, intégration des outils MCP. L'outil à plus fort effet de levier que j'ai ajouté à ma pile en 2025. La plupart du travail d'ingénierie se fait maintenant dans Claude Code plutôt que directement dans VS Code ou Cursor.

Cursor pour les modifications directes dans l'éditeur

Cursor reste la meilleure expérience d'éditeur pour travailler aux côtés de l'IA sur un seul fichier. Complétion par onglet, modifications en ligne, diff côte à côte. J'utilise Cursor quand le travail est concentré sur un ou deux fichiers; je bascule vers Claude Code quand le travail s'étend sur tout le projet.

Claude Sonnet via API pour le travail par lot

Quand j'ai besoin de générer ou réécrire des centaines de pages par programmation (le pipeline d'auto-blog, l'humanisation du contenu, la génération de schéma), j'appelle l'API Claude directement via Sonnet. Latence plus faible que la surface de chat, coût prévisible, scriptable. L'outil approprié pour les pipelines de contenu spécifiquement.

OpenAI GPT-4o pour l'ingénierie des invites

Ma découverte fin 2025 a été que les prompts pour Kimi, Minimax, ou tout autre agent se rédigent mieux avec Claude ou GPT, pas à la main. Je décris l'objectif, demande à GPT-4o de rédiger le prompt, puis exécute ce prompt contre l'exécuteur. La qualité de sortie est matériellement supérieure aux équivalents rédigés à la main.

Kimi Researcher et Minimax Agent

Recherche approfondie et maquettes de conception d'applications complètes respectivement. Le post /blog/kimi-minimax-deep-research-design-mockups/ couvre le workflow complet. Deux outils critiques chez Seahawk pour la recherche client et le prototypage rapide.

Petits commits, messages descriptifs

Le développement assisté par IA tend à produire de grands diffs parce qu'il est facile de déployer 800 lignes de code généré en un seul commit. Forcez-vous à committer plus petit. Un message de commit qui dit ce qui a changé et pourquoi est le seul artefact que vous-futur aurez pour déboguer une régression. Rendez-le lisible.

Les tests comme contrat

Claude peut écrire du code qui compile et s'exécute mais viole silencieusement une contrainte qui était implicite dans la spécification. Les tests qui encodent ces contraintes comme contrats exécutables détectent les violations. La discipline du test-first compte plus à l'ère assistée par IA qu'elle ne le faisait quand les humains écrivaient chaque ligne.

La révision de code est réservée aux humains pour l'instant

Je ne laisse pas Claude approuver ses propres pull requests. La porte de révision est le contrôle de qualité le plus important qu'il reste aux humains, et l'externaliser au même modèle qui a écrit le code défait l'objectif. Le SDK Anthropic et les workflows Claude Code rendent la révision assistée par IA facile, mais l'approbation finale m'appartient.

Dépendances versionnées et fichiers de verrouillage

Épinglez chaque dépendance. Utilisez des fichiers de verrouillage. Exécutez npm audit à chaque build. La surface d'attaque de la chaîne d'approvisionnement est réelle et le développement assisté par IA tend à ajouter plus de dépendances que les équivalents écrits par l'homme parce qu'ajouter un paquet est rapide. La discipline des fichiers de verrouillage maintient la surface auditable.

Cinq catégories de décisions où Claude est le mauvais outil :

Quoi construire du tout. La décision produit est chargée de jugement, dépend du contexte utilisateur que Claude n'a pas, et c'est la décision la plus importante dans n'importe quel produit. Les fondateurs et les PM en sont propriétaires ; l'IA assiste au mieux.

Quoi lancer et quoi abandonner. Les décisions de périmètre lors d'une construction dépendent toujours de contraintes que le modèle ne voit pas. Pression temporelle, moral de l'équipe, relations partenaires, positionnement marketing. Décidez en tant qu'humain, documentez le raisonnement, puis demandez à Claude d'exécuter le périmètre décidé.

Conception des modes de défaillance. Le comportement du système en cas de problème n'est rarement spécifié à l'avance et c'est là que provient la plupart des incidents en production. Investissez disproportionnément de temps dans les modes de défaillance ; ils n'émergeront pas naturellement de la génération de code sur le chemin heureux.

La couche éthique. Ce que vous construisez a des implications. Confidentialité, résidence des données, accessibilité, coût environnemental. Ce sont des décisions humaines, pas des résultats d'optimisation. Posez la question explicitement au moment de la conception.

Maintenabilité à long terme. Futur-vous lisant futur-Claude lisant le code présent-Claude est la version la plus profonde de la dette technique. Optimisez le code présent pour être lisible par les humains d'abord, l'IA ensuite.

Des exemples concrets des douze derniers mois chez Seahawk et personnellement :

HostList.io (28 000 pages programmatiques sur Next.js + Supabase) : architecturé avec Claude Code en cinq jours, pipeline de contenu écrit par Claude avec intégration de recherche Tavily, génération de héros via FAL, markup schéma généré automatiquement. Le temps d'ingénierie total était à peu près un tiers de ce que j'aurais estimé il y a trois ans.

gautamkhorana.com (ce site, sur Astro + Supabase) : reconstruit en 24 heures un week-end avec Claude Code comme collaborateur principal. Surface d'éditeur de site, système de blog, couche de schéma, i18n, tout généré, revu, refactorisé. Le coût de construction d'un site personnel de cette qualité est tombé à un week-end de travail concentré.

Pipeline auto-blog et traduction Deluxe Astrology : la boucle Tavily-recherche-à-brouillon-Claude-à-vérification-Winston-à-héros-FAL-à-publication-Supabase s'exécute quotidiennement sur 30 langues sur plus de 91 000 pages. Le pipeline lui-même fait environ 800 lignes de code que Claude a écrit en environ 12 heures de travail concentré, dont une grande partie aurait pris une semaine avec une équipe exclusivement humaine.

Tableaux de bord admin internes chez Seahawk : Minimax Agent génère le premier prototype à partir d'une description sur six lignes, Claude l'affine, le résultat est livrable en une heure. Le délai entre « nous avons besoin d'un outil interne » et « nous utilisons l'outil interne » est passé de jours à moins d'une journée de travail.

Construire des logiciels sur mesure en 2026 est un métier qui s'est compressé d'un ordre de magnitude sur la vitesse d'exécution et est resté à peu près constant sur la complexité du jugement. Les équipes qui s'adaptent sont celles qui apportent plus de jugement (meilleures spécifications, meilleurs choix architecturaux, meilleure conception des modes de défaillance) et sous-traitent davantage l'exécution à l'IA. Les équipes qui ne s'adaptent pas produisent des logiciels à une vitesse compétitive mais perdent en qualité, ou vice versa.

Vous n'avez pas besoin d'utiliser chaque outil dans ce guide. Vous avez besoin de savoir quelles décisions sont les vôtres et lesquelles peuvent être déléguées. Le savoir-faire est la frontière, pas la pile d'outils.

Si vous voulez de l'aide pour expédier un projet de logiciel sur mesure à cette courbe de coûts, nous exécutons des builds de produits chez Seahawk Media. La conversation est gratuite ; la tarification du projet reflète la réalité du coût assisté par l'IA, pas la réalité du coût horaire de 2018.