Sept défis techniques révèlent la puissance du développement assisté par IA, mais aussi la valeur irremplaçable du cadrage humain.
Un fil d’actualité apparaît, deux profils se suivent, les messages circulent presque en direct, puis une publication rédigée en mode avion rejoint le serveur au retour du réseau. En moins de vingt minutes de démonstration, Claude Code donne l’impression d’avoir avalé plusieurs semaines de développement. L’image est spectaculaire, mais elle raconte surtout autre chose : l’IA peut accélérer la construction, pas décider seule de ce qui mérite d’être construit.
Dans l’expérience menée par Développeur Libre, l’assistant doit bâtir un réseau social iOS à travers sept défis, avec trois tentatives par étape et sans correction manuelle du code par le créateur. Cette démonstration complète utilement notre sélection de chaînes YouTube francophones sur la technologie et l’intelligence artificielle.
La vraie accélération commence avant le code
CLAUDE.md, un contrat de travail pour l’assistant
Le geste le plus instructif arrive avant la première ligne de code. Le créateur prépare un fichier CLAUDE.md qui décrit le contexte, la vision finale, les règles, le modèle de données et les contraintes du projet. Il demande également à Claude Code d’expliquer ses choix et de signaler les actions qui resteront à effectuer côté humain.
Pour chaque défi, l’assistant commence en mode plan : il propose les fichiers, les changements et les tests. L’humain valide ensuite le plan avant l’exécution. Cette discipline concentre probablement la plus grande valeur. Elle ressemble aux bonnes pratiques de management et de croissance : clarifier le résultat attendu, fixer les limites et contrôler les étapes décisives.
Le socle repose sur Supabase, un service de backend, c’est-à-dire la partie invisible qui stocke les données et gère ici l’authentification. L’inscription, la connexion et le profil fonctionnent. Mais l’automatisation ne supprime pas toutes les manipulations : plusieurs scripts SQL générés par l’IA doivent encore être exécutés dans la base de données.
Des fonctions complexes livrées à une vitesse étonnante
La progression est convaincante. Claude Code ajoute les publications avec texte et image, les abonnements entre profils, le fil chronologique, les mentions « J’aime » et les commentaires. L’interface demande quelques allers-retours, notamment pour mieux cadrer les photos, mais les fonctions prennent forme et sont vérifiées sur deux appareils.
Le temps réel oblige déjà à faire des choix
Les premiers accrocs sont révélateurs. Une erreur apparaît parce qu’une étape manuelle n’a pas été lue, puis une relation entre publications et profils doit être corrigée. Lorsque les interactions ne se mettent pas à jour sur le second appareil, l’assistant propose un rafraîchissement automatique toutes les quatre secondes plutôt qu’une synchronisation permanente.
La messagerie, testée à partir de 7 min 40 dans la vidéo, va plus loin. Les messages arrivent presque instantanément, l’indicateur de saisie apparaît et l’accusé de lecture change lorsque le destinataire ouvre la conversation. Les notifications suivent pour les messages, les mentions « J’aime » et les commentaires, une fois le script SQL nécessaire exécuté. En revanche, toucher une notification n’ouvre pas directement la conversation : ce comportement n’avait pas été demandé.
Ce détail est précieux pour une entreprise. Une fonctionnalité peut être techniquement présente tout en restant incomplète du point de vue de l’usage. On retrouve la même tension dans l’automatisation du support client par l’IA : une réponse rapide compte, mais le parcours complet et le contrôle humain comptent davantage.
Modération et mode hors ligne : les vrais tests de structure
Le sixième défi introduit un compte administrateur capable de supprimer les publications et commentaires d’autrui. L’autorisation est gérée dans la base de données, pas seulement masquée dans l’interface. Le test fonctionne malgré une animation de suppression maladroite. Cette imperfection montre pourquoi un contrôle ne peut pas se limiter à constater qu’un bouton répond.
Le mode hors ligne est encore plus parlant. En mode avion, une publication avec texte et image reste visible localement et attend le retour de la connexion. Dès que le réseau revient, elle est envoyée à la base puis apparaît sur l’autre appareil. Cette séquence, vers 14 min 50, démontre l’orchestration entre stockage local, détection du réseau et nouvelle tentative d’envoi.
Un prototype impressionnant n’est pas encore un produit
Après les sept défis, un dernier prompt demande de moderniser toute l’interface. C’est là que l’enthousiasme retombe. Après quinze minutes de travail, les couleurs sont plus cohérentes et certains écrans plus propres, mais l’ensemble manque d’imagination. L’assistant exécute mieux une fonction vérifiable qu’une ambition vague comme « rendre le design moderne ».
Les requêtes adressées à l’outil ont coûté 35 euros dans cette expérience. Le montant paraît faible au regard des fonctions générées, mais il faut le lire correctement : le coût des requêtes mesure la génération de code, pas le coût réel du produit. Il n’inclut ni la définition du besoin, ni les vérifications humaines, ni le travail restant avant une mise en ligne solide.
Le créateur choisit d’ailleurs de ne pas publier l’application, car un réseau social supplémentaire ne répond pas, à lui seul, à un besoin utile. Voilà la distinction entre prototype et MVP, le « produit minimum viable » conçu pour vérifier une hypothèse auprès de vrais utilisateurs. Ces chaînes YouTube francophones sur les startups et l’entrepreneuriat permettent de prolonger cette réflexion sur l’utilité et le marché.
Ce qu’un entrepreneur peut en retenir
L’expérience n’annonce pas la disparition du développeur. Elle déplace son travail vers la formulation, l’architecture, le test et l’arbitrage. Quatre réflexes ressortent clairement :
- Écrire le contexte avant le prompt. Une vision, des règles et un modèle de données réduisent les ambiguïtés.
- Découper le risque. Des étapes courtes et testables rendent les erreurs visibles avant qu’elles ne se propagent.
- Vérifier sur le terrain. Deux appareils, une coupure réseau et plusieurs comptes révèlent ce qu’une simple démonstration ne montre pas.
- Séparer faisabilité et désirabilité. Ce n’est pas parce qu’une application peut être produite rapidement qu’elle mérite d’exister.
Le plus grand gain n’est donc pas de demander à l’IA de tout faire. Il vient de la capacité à lui donner un cadre précis, à lire ses consignes, à tester ses choix et à refuser un résultat qui fonctionne sans créer assez de valeur. C’est moins magique qu’un prompt unique, mais beaucoup plus proche du vrai métier d’entrepreneur.
L’image est spectaculaire, mais elle raconte surtout autre chose : l’IA peut accélérer la construction, pas décider seule de ce qui mérite d’être construit.
Le coût des requêtes mesure la génération de code, pas le coût réel du produit.

Sources
- J’ai codé un réseau social avec l’IA (elle a fini par craquer) — Vidéo de Développeur Libre publiée le 31 juillet 2026 ; article fondé sur le contenu et la transcription française de l’épisode.
Innohub TV
Regardez aussi ce contenu sur Innohub TV
Nous avons sélectionné pour vous, sur Innohub TV, des extraits qui prolongent le sujet.
