Personne Ne Te Prévient : Le Vrai Travail Commence Après Que l'IA Dit 'Terminé'

Q: Qu'est-ce que Claude Code a Réellement Construit en Une Soirée?

Voici à quoi ressemble mon historique git : | Phase | Ce qui s'est passé | Commits | |-------|--------------|---------| | Document de conception + plan d'implémentation | Décisions d'architecture, 12 tâches | 2 | | Claude construit « l'app entière » | Scaffold → auth → bibliothèque → détail → studio → StoreKit → accessibilité | 6 | | L'humain ouvre le Simulateur | Corriger, tester, reconcevoir, corriger, tester, reconcevoir | 12+ (et en comptant) | La première phase — Claude Code échafaudant l'app entière — était vraiment impressionnante. En une soirée, je suis passé d'un projet Xcode vide à une app qui compile avec : Apple Sign-In, Google OAuth, auth email/mot de passe, et MFA Un assistant de création de podcast en 5 étapes Une bibliothèque de podcasts avec recherche et pull-to-refresh Lecture audio avec Achats in-app StoreKit 2 avec vérification côté serveur Studio (gestion des émissions récurrentes) Localisation en 7 langues Webview de blog et libellés d'accessibilité 69 fichiers Swift. 7 568 lignes de code. J'en ai écrit approximativement zéro. C'est là que chaque article de blog sur l'IA se termine. La capture d'écran triomphale. Le moment « regardez ce que j'ai construit ». Le nombre de commits et le nombre de lignes et le calendrier qui ne devrait pas être possible. Mais je n'avais pas une app. J'avais une base de code qui compilait. ---

Je n'ai jamais ouvert Xcode de ma vie.

Je ne connais pas Swift. Je ne connais pas SwiftUI. Je ne sais pas ce que fait un macro @Observable ni pourquoi AVAudioSession a besoin d'une catégorie. Il y a deux jours, si tu m'avais demandé ce qu'était StoreKit, j'aurais deviné que c'est une app de meubles.

Et pourtant je construis une app iOS native — et je découvre que le code généré par l'IA t'amène environ à 60 % du chemin. Les 40 % restants, la partie où une base de code devient un produit, c'est entièrement du travail humain. C'est ce qu'aucun des posts « J'ai construit X avec l'IA » ne mentionne jamais.

L'app est pour DIALØGUE — mon générateur de podcasts IA. Pas un wrapper web. Pas React Native. Une vraie app SwiftUI avec Apple Sign-In, des achats in-app, un lecteur audio avec des contrôles sur l'écran de verrouillage, et une localisation en 7 langues.

Pourquoi maintenant ?

Le 3 février, Apple a annoncé que Xcode 26.3 supporterait le codage agentique — avec le Claude Agent SDK d'Anthropic intégré. Pas juste de l'autocomplétion. Pas juste des suggestions au tour par tour. Des agents autonomes complets qui peuvent explorer ta structure de projet, rechercher la documentation d'Apple, capturer des Xcode Previews pour voir ce qu'ils construisent, et itérer à travers les builds et corrections par eux-mêmes.

Claude Code peut maintenant parler à Xcode via MCP. Il peut voir le Simulateur. Il peut lire les avertissements de build et les messages d'erreur. Il peut regarder à quoi ressemble réellement l'UI et décider si elle doit changer.

Ça a changé le calcul pour moi. Je pensais à une app iOS native depuis des mois mais je continuais à reporter parce que je ne connais pas Swift. Avec Claude Agent dans Xcode, la question est passée de « puis-je apprendre Swift assez vite ? » à « puis-je décrire ce que je veux assez clairement ? »

Ce n'est pas terminé. Je suis encore dans la phase de finition, trouvant encore des choses qui ne fonctionnent pas correctement, apprenant encore Swift en lisant le code que Claude a écrit pour moi. Mais l'histoire jusqu'à présent — tout comme ma reconstruction de DIALØGUE en 14 jours — a renforcé la même leçon inconfortable.

Qu'est-ce que Claude Code a Réellement Construit en Une Soirée ?

Voici à quoi ressemble mon historique git :

Phase	Ce qui s'est passé	Commits
Document de conception + plan d'implémentation	Décisions d'architecture, 12 tâches	2
Claude construit « l'app entière »	Scaffold → auth → bibliothèque → détail → studio → StoreKit → accessibilité	6
L'humain ouvre le Simulateur	Corriger, tester, reconcevoir, corriger, tester, reconcevoir	12+ (et en comptant)

La première phase — Claude Code échafaudant l'app entière — était vraiment impressionnante. En une soirée, je suis passé d'un projet Xcode vide à une app qui compile avec :

Apple Sign-In, Google OAuth, auth email/mot de passe, et MFA
Un assistant de création de podcast en 5 étapes
Une bibliothèque de podcasts avec recherche et pull-to-refresh
Lecture audio avec AVPlayer
Achats in-app StoreKit 2 avec vérification côté serveur
Studio (gestion des émissions récurrentes)
Localisation en 7 langues
Webview de blog et libellés d'accessibilité

69 fichiers Swift. 7 568 lignes de code. J'en ai écrit approximativement zéro.

C'est là que chaque article de blog sur l'IA se termine. La capture d'écran triomphale. Le moment « regardez ce que j'ai construit ». Le nombre de commits et le nombre de lignes et le calendrier qui ne devrait pas être possible.

Mais je n'avais pas une app. J'avais une base de code qui compilait.

Qu'est-ce qui s'est Cassé Quand j'ai Vraiment Utilisé l'App ?

J'ai tapé à l'écran. Les choses se chargeaient. Certains écrans semblaient corrects. J'ai pensé, « Peut-être que ça va vraiment marcher. »

Puis j'ai essayé de créer un podcast.

Le Bouton "Terminé" Jetait Ton Travail

L'éditeur de script te permet de modifier des lignes de dialogue individuelles avant de générer l'audio. Il y a un bouton « Terminé ». J'ai modifié une ligne, appuyé sur Terminé, et... mes modifications avaient disparu.

Le bouton quittait le mode édition avant de sauvegarder. Ça semblait correct dans le code — editMode = false — mais la séquence était fausse. Sauvegarder, puis quitter.

C'est le genre de bug qui fait que les utilisateurs jettent leur téléphone. Et l'IA l'a écrit parce que la logique est techniquement valide — juste à l'envers.

Les Vraies Données Crashaient l'App

J'ai navigué vers un podcast qui avait été généré par le backend de production. Crash. Le champ research_facts retournait un tableau d'objets ({fact, source, reference, confidence}), mais le modèle Swift attendait un tableau de chaînes de caractères. Le même schéma partout — les enums de statut étaient sensibles à la casse (completed vs COMPLETE), donc chaque badge de statut affichait « Unknown ».

Claude a construit ce que le document de conception disait. La base de données de production n'était pas d'accord. C'est le genre de chose que tu ne découvres qu'avec de vraies données, pas des données de test.

Le WebSocket Realtime Ne Se Connectait Tout Simplement Pas

Sur le web, Supabase Realtime fonctionne très bien. Sur iOS, la connexion WebSocket échouait silencieusement. Pas d'erreur, pas de crash. Juste... pas de mises à jour.

La correction était une approche ceinture-et-bretelles : garder l'abonnement Realtime mais ajouter un fallback de polling de 5 secondes qui s'exécute indépendamment. Pas élégant, mais fiable. Les réseaux mobiles sont imprévisibles, et tes utilisateurs ne se soucieront pas de comment les mises à jour de statut arrivent — seulement qu'elles arrivent.

L'App Entière Utilisait les Couleurs Système

Chaque écran était en bleu et gris iOS par défaut. Mode clair. L'app web a une esthétique dark-mode soigneusement conçue — ambre et or sur charbon, ce que j'appelle « Studio Warmth ». Claude avait diligemment construit chaque écran, mais en couleurs système.

J'ai dû toucher les 24 fichiers de vue. Remplacer chaque Color.accentColor par Theme.brandPrimary. Forcer .preferredColorScheme(.dark) à la racine.

Ce n'est pas un bug. L'IA a fait exactement ce qui était raisonnable. Mais « raisonnable » et « bon » sont deux choses différentes.

DIALØGUE iOS app podcast detail page with Studio Warmth dark theme showing amber radial glow header and integrated audio controls — La page de détail du podcast après le passage Studio Warmth — lueur ambrée, thème sombre, lecture intégrée. Rien de tout ça n'existait dans l'échafaudage original de Claude.

La Revue du Plan était un Bouton qui Disait « Approuver »

Le flux de génération de podcast a une étape interactive : l'IA génère un plan, et tu le revues avant de continuer. Sur le web, c'est une interface de cartes dépliables montrant la description de chaque segment, les points de discussion et les sources de recherche.

Sur iOS, Claude a construit un bouton qui disait « Approuver ». C'est tout. Pas de contenu du plan. Aucun moyen de voir ce qu'on approuve. Pareil pour la revue du script — un bouton, pas un éditeur.

L'Audio Ne Jouait Pas

Le lecteur audio semblait correct. Bouton lecture, barre de progression, contrôles sur l'écran de verrouillage. Mais appuyer sur lecture ne faisait rien. La chaîne de résolution d'URL était cassée — les URL de téléchargement signées échouaient dans l'environnement de développement, et les URL de fallback utilisaient des noms d'hôte Docker internes que le Simulateur ne pouvait pas résoudre.

Après avoir corrigé l'audio et reconçu la page de détail du podcast avec des contrôles de lecture intégrés, la barre mini-player persistante en bas de chaque onglet était redondante. Je l'ai supprimée. Supprimer du code qui fonctionne mais ne devrait pas exister — c'est un jugement purement humain.

À Quoi Ressemblent le Code Généré par l'IA vs un Vrai Produit ?

Le code généré par l'IA est architecturalement solide mais expérientiellement creux. Je ne me plains pas — ce que Claude Code a fait est remarquable. Passer de « je ne connais pas Swift » à une app compilant avec auth, IAP, lecture audio et localisation en 7 langues en une soirée ? Ça m'aurait pris des mois.

Mais il y a un narratif là-dehors — dans les articles de blog, les tweets, les vidéos de démo — que l'IA écrit l'app et tu la révises juste. La publier. Terminé.

Ce n'est pas ce qui s'est passé. Voici ce qui s'est réellement passé :

Claude a construit un échafaudage architecturalement solide. La décision de passer en Supabase-direct (sans couche API personnalisée) signifiait que l'app iOS parle au même backend que l'app web. Auth, base de données, realtime, stockage — tout réutilisé. Je n'avais besoin que d'un seul nouveau composant côté serveur (une Edge Function verify-ios-purchase). Ce choix architectural était brillant et a économisé un temps énorme.
Claude a réussi les parties difficiles. Apple Sign-In avec un nonce cryptographique via CryptoKit. Flux d'achat StoreKit 2 avec vérification côté serveur. Configuration AVAudioSession pour la lecture en arrière-plan. Cela m'aurait pris des jours à comprendre à partir de la documentation seule.
Claude a raté les parties produit. Pas incorrect au sens bogué — incorrect au sens de « voici à quoi ressemble une base de code, pas ce que ressent une app. »

Ce que Claude a construit	Ce qui était réellement nécessaire
Un bouton qui dit « Approuver »	Un réviseur de plan dépliable avec les sources de recherche
Couleurs système sur chaque écran	24 fichiers de tokens de marque, mode sombre forcé
Décodeur JSON pour le schéma documenté	Décodeur personnalisé pour ce que la base de données retourne réellement
Abonnements Realtime (pattern web)	Realtime + fallback polling (pattern mobile)
Un assistant de création qui fonctionne	Un assistant de création qui tient sur un écran de téléphone

DIALØGUE iOS creation wizard showing voice customization with speed and pitch sliders in dark theme — L'assistant de création après intervention humaine — personnalisation de la voix avec curseurs de vitesse/hauteur, sections repliables, le tout tenant sur un écran de téléphone.

La colonne de gauche est du code correct. La colonne de droite est un produit.

Que Devrait-on Dire à la Prochaine Génération sur l'IA ?

J'ai écrit il y a quelques semaines sur le fait d'avoir une fille adolescente et de ne pas savoir quoi lui dire sur son avenir. Sur la façon dont les compétences d'exécution sont automatisées et le plancher pour « je peux penser de manière critique » ne cesse de monter.

Construire cette app iOS a rendu les choses plus claires — mais pas dans la direction à laquelle je m'attendais.

Les compétences d'implémentation — la syntaxe Swift, la mise en page SwiftUI, l'API StoreKit — je n'en avais pas besoin. Claude a géré tout ça. Si « apprendre à coder » signifie « apprendre la syntaxe et les APIs d'un langage de programmation », ce conseil a une date d'expiration mesurée en mois, pas en années.

Mais voici ce dont j'avais besoin : le goût du produit, le jugement de conception et la discipline d'ouvrir le Simulateur et d'utiliser réellement la chose au lieu de faire confiance à la revue de code.

Ce ne sont pas juste du « goût ». Ils nécessitent une réflexion critique — une vraie réflexion critique, pas la version buzzword. Le genre où tu regardes quelque chose qui compile, qui passe les tests, qu'une IA te dit avec confiance que c'est terminé, et tu dis : « Non. Ce n'est pas correct. Laisse-moi te montrer pourquoi. »

C'est la partie qu'on ne peut pas externaliser. Pas encore, peut-être jamais. L'IA est extraordinaire pour générer des solutions. Elle est terrible pour savoir quand une solution est incorrecte de façons qui n'apparaissent pas dans les logs. Elle n'utilise pas le produit. Elle ne tient pas le téléphone. Elle ne ressent pas la frustration d'un bouton Terminé qui mange ton travail. Quelqu'un doit piloter. Quelqu'un doit rester dans la boucle. Quelqu'un doit fournir le contrôle instinctif qui dit « ça marche mais ce n'est pas bien. »

Peut-être que c'est ce que je devrais dire à ma fille. Pas « apprends à coder » — cette fenêtre se ferme. Mais pas non plus « apprends juste à penser de manière critique », parce que c'est trop vague. Quelque chose de plus précis :

Apprends à être la personne qui ouvre le Simulateur.

Sois celle qui teste la vraie chose avec de vraies données et remarque ce qui ne va pas avant tes utilisateurs. Développe du goût en utilisant d'excellents produits et d'affreux produits et en comprenant la différence. Développe la confiance pour refuser quelque chose qui est techniquement correct mais expérientiellement cassé — même quand la chose qui s'y oppose est une IA qui semble très sûre d'elle-même.

L'humain dans la boucle n'est pas une formalité. C'est tout le produit.

Je ne suis toujours pas sûr que ce soit suffisant. Mais c'est la chose la plus précise que j'ai pu dire jusqu'à présent.

Quel est l'État Actuel de l'App iOS ?

L'app est toujours en développement. Je suis dans la phase de finition — la phase que les articles de blog sur l'IA prétendent ne pas exister. Tester de vraies données de production contre chaque vue. Trouver les cas limites qui n'apparaissent que quand tu utilises réellement la chose.

Mon log git des deux derniers jours a plus de commits fix: que de commits feat:. Ça semble juste. Les fonctionnalités étaient la partie facile. Les corrections sont le produit.

Voici l'état actuel :

Ce qui fonctionne	Ce qui reste
Auth (Apple, Google, email, MFA)	Upload PDF (sélecteur de document + Supabase Storage)
Assistant de création en 5 étapes avec personnalisation complète	Téléchargement MP3 hors ligne
Détail du podcast avec revue plan/script	Notifications push (reportées à v1.1)
Lecture audio avec contrôles sur écran de verrouillage	Distribution bêta TestFlight
Achats in-app StoreKit 2	Soumission App Store
Studio (émissions récurrentes)
Localisation en 7 langues
Système de design Studio Warmth

J'écrirai un suivi quand l'app atteindra l'App Store. Ou quand elle sera rejetée. Connaissant Apple, l'histoire du rejet sera peut-être plus intéressante.

À Quelle Vitesse le Développement IA s'Accélère-t-il Vraiment ?

Laisse-moi mettre à jour le tableau qui continue de me hanter :

Projet	Complexité	Temps de construction
DIALØGUE v1	MVP générateur de podcasts	~6 mois
STRAŦUM	10 agents IA, 11 frameworks, multi-tenant	75 jours
Refonte du site	Refonte frontend WordPress	3 jours
DIALØGUE v2	Reconstruction complète app web	14 jours
Migration blog	WordPress → Next.js, 490 posts, Sydney RAG	4 jours
DIALØGUE iOS	App iOS native, première utilisation de Swift	Toujours en cours — mais l'échafaudage a pris une soirée

J'ai ajouté une nouvelle colonne dans ma tête : « Temps pour Claude » vs « Temps pour moi ». Le ratio ne cesse de changer. La partie de Claude devient plus courte. La mienne reste à peu près la même. (J'ai remarqué le même schéma quand j'ai reconstruit le backend de mon blog en 4 jours — la migration était rapide, mais les 8 jours de raffinement cumulé qui ont suivi sont là où le site s'est vraiment mis en place.)

Et les outils continuent de s'améliorer. Quand Apple et Anthropic ont annoncé l'intégration Xcode + Claude Agent SDK le 3 février, ce n'était pas juste un communiqué de presse. Ça a fondamentalement changé ce qui est possible. Claude peut maintenant voir le Simulateur, lire les erreurs de build, capturer des Previews et itérer visuellement — la boucle exacte qui rend le développement iOS difficile pour les humains devient native à l'IA.

Deux semaines après cette annonce, j'ai commencé à construire une app iOS sans connaître Swift. Ce n'est pas une coïncidence.

La prochaine personne qui fera ça n'aura pas besoin d'écrire un article de blog à ce sujet. Ça sera juste... normal. C'est à ça que ressemble l'accélération de l'intérieur — chaque étape semble moins remarquable que la précédente, même si la distance objective parcourue ne cesse de croître.

C'est la chose que personne ne te dit. L'IA s'accélère. Le travail humain ne le fait pas. Pas encore, en tout cas.

Foire Aux Questions

Peut-on vraiment construire une app iOS avec l'IA sans connaître Swift ?

Oui — Claude Code a échafaudé 69 fichiers Swift et 7 568 lignes de code en une soirée, incluant Apple Sign-In, les achats in-app StoreKit 2, la lecture audio et la localisation en 7 langues. Mais « construire » fait beaucoup de travail dans cette phrase. L'IA produit une base de code qui compile ; la transformer en produit qu'on publierait vraiment nécessite des tests humains extensifs, du jugement de conception et du débogage avec de vraies données.

Que change Xcode 26.3 avec Claude Agent SDK ?

Annoncé le 3 février 2026, l'intégration Xcode + Claude Agent SDK permet aux agents IA d'explorer ta structure de projet, de rechercher la documentation d'Apple, de capturer des Xcode Previews, de voir le Simulateur, de lire les erreurs de build et d'itérer de manière autonome. Cela change fondamentalement ce qui est possible pour les développeurs qui ne connaissent pas Swift — la question passe de « puis-je apprendre le langage ? » à « puis-je décrire ce que je veux ? »

Quel pourcentage d'une app construite par IA nécessite vraiment du travail humain ?

D'après mon expérience, l'IA t'emmène environ 60 % du chemin — l'architecture, le boilerplate, les intégrations API difficiles. Les 40 % restants sont du travail produit : corriger les bugs qui n'apparaissent qu'avec de vraies données, reconcevoir des UI qui fonctionnent mais ne se sentent pas bien, et faire des jugements sur ce qu'il faut garder et ce qu'il faut supprimer. Ces 40 %, c'est là que le produit vit réellement.

Quelles compétences importent le plus pour construire avec des agents de codage IA ?

Le goût du produit, le jugement de conception et la réflexion critique. Les compétences d'implémentation (syntaxe, APIs, frameworks) sont de plus en plus gérées par l'IA. Ce qui ne peut pas être externalisé, c'est la capacité de tester la vraie chose avec de vraies données, de remarquer ce qui ne va pas et de refuser quelque chose qui est techniquement correct mais expérientiellement cassé.

L'app iOS DIALØGUE est-elle disponible sur l'App Store ?

Pas encore — elle est toujours en développement, dans la phase de finition finale. Les fonctionnalités marchent, mais je teste encore contre des données de production et je trouve les cas limites qui n'apparaissent que quand tu utilises vraiment l'app. J'écrirai un suivi quand elle atteindra l'App Store (ou quand elle sera rejetée).

Toujours en construction. Toujours pas terminé. Toujours en train de chercher quoi dire à ma fille.